Iptables iptables -t nat -o -jMASQUERADEを使用して単純なNAT変換を実行するルーターがあります
これは、一部のTCP RSTおよびFINパケットがルーターをNAT化しないままにしている特定のケースを除いて、ほとんど常に正常に機能します。
このシナリオでは、Flashビデオをストリーミングする1台または2台のクライアントコンピューターをセットアップします(例:www.nasa.gov/ntv)ルーターで、パブリックインターフェイス(モデム)を破棄して再確立します。予想どおり、Flashストリームが停止します。 。接続が再確立され、Flashページを更新しようとすると、いくつかのTCP RSTおよび[FIN、ACK]パケットがパブリックインターフェイスを離れるのがわかります(Flashがその回復を試みると想定しています)ストリーム)。
これらのパケットがルーターを非NATのままにする方法がわかりません
ヒントをありがとう。私は自分を正しい軌道に乗せるために必要なものでした。
根本的な原因は、LANとパブリックインターフェイス間のフィルタリングされていない転送でした。パブリックインターフェイスが破棄されると、conntrackエントリがクリアされました。その後、クライアントは接続を復活させようとし、最終的にRSTパケットとFINパケットを送信しました。 NATは新しい接続でのみセットアップされるため、これらのパケットはルーターを変更せずに残します。
NEW、ESTABLISHED、RELATEDパケットのみがプライベートLANから転送されるように、転送ルールを変更する必要がありました。
[RST、ACK]および[FIN、ACK]を削除しても機能しません。 ftpアップロードのように、FTP転送の完了を確認できないアプリケーションはたくさんあります。 gscottによるコメントは正しい方法ですが、もう1つの要件が必要です。ポリシーを適用して、それらを厳密にする必要があります
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -P INPUT DROP
これで、すべてのルールを指定する必要があります。そうしないと、パケットがドロップされます。
これは、iptablesのMASQUERADEターゲットのバグである可能性があります。あなたのシナリオでは、次の同時発生イベントがあるようです。
そのため、偽装するアドレスが無効であるためにパケットを偽装しようとして失敗する可能性があります。そのため、パケットは変更されずにルーティングされます。
MASQUERADEターゲットから予想される動作は、インターフェイスがダウンしたとき、またはアドレスが変更されたときに、対応する状態エントリがクリアされることであるため、この状況は発生しないはずです。しかし、 iptablesについて報告された古代のバグ がありました。これは、同様の種類の動作を引き起こす可能性があるようです。
さらにトラブルシューティングを行うには、ルーターのパブリックIPアドレスをメモし、問題を再現し、egrep 12.34.56.78 /proc/net/ip_conntrack
(12.34.56.78は以前にメモしたIPアドレス)を使用して状態テーブルを確認します。パブリックインターフェイスアドレスが変更されているにもかかわらず、古いIPアドレスでconntrack行を取得する場合は、おそらくiptablesのバグが発生しています。カーネル/ iptablesを更新し、問題をnetfilterチームに報告することを検討してください。
ご参考までに
FIN、ACKおよびRST、ACKパッケージがパブリックネットワークに入るのを防ぐ別の方法は、発信チェーンでそれらをブロックすることです。
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST,ACK -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN,ACK -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST -j DROP
これは、なりすましパッケージを防ぐのに役立ちました。