☰

iptables - INPUT DROPはFORWARDルールを無視しますか？

tag-icon • tag-icon networking iptables routing
iptables - INPUT DROPはFORWARDルールを無視しますか？

最近、ホームネットワークのDebianサーバーにクライアントVPNをインストールしました。ネットワークの一部のデバイスの別のゲートウェイとして使用したいと思います。これは私が成功したので、すべて良いです。ちょうどあなたに背景の物語を提供したいと思いました。

これで、iptables -P INPUT DROPを使用しない限り、VPN経由でWAN経由で接続できるRDPサーバー（WS 2019）があります。しかし、ポートフォワーディングを使用していますが、なぜこれらのポートが機能しないのかを混乱させます。私は昨日iptablesを使い始めたので、これはおそらく非常に明白なことですが、Googleで検索する方法がわかりません。

私の設定：

$ iptables -L -n  
Chain INPUT (policy DROP)  
target    prot opt source               destination         
ACCEPT     tcp  --  192.168.0.0/24      0.0.0.0/0            tcp dpt:22  
Chain FORWARD (policy ACCEPT)  
target     prot opt source               destination  
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination      


$ iptables -L -n -t nat  
Chain PREROUTING (policy ACCEPT)  
target     prot opt source               destination  
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111 to:192.168.0.50:3389 <-(RDP server)  
Chain INPUT (policy ACCEPT)  
target     prot opt source               destination  
Chain POSTROUTING (policy ACCEPT)  
target     prot opt source               destination  
SNAT       all  --  192.168.0.0/24      0.0.0.0/0            to:[my public VPN IP]  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination

明らかに、すべてが再び機能するようにする必要がある唯一のことは、「入力」ポリシーを「受け入れ」に設定することでしたが、WAN用のルーターだったので、そうしたくありませんでした。

それでは、INPUTのポリシーは順方向チェーントラフィックも定義しますか？ DROPポリシーを使用し、まだ11111トラフィックをローカルRDPサーバーの3389に転送できるようにこの問題を解決するにはどうすればよいですか？

答え1

トラフィックが実際に Windows Server に到達するかどうかを確認するには、パケットがドロップされる前に書き込まれるように、ファイアウォール スクリプトの末尾に「-J LOG」を追加することをお勧めします。パッケージが削除されることが表示されない場合は、Windowsファイアウォールがそのパッケージを削除している可能性があります。また、この設定が進行中の作業かもしれませんが、ファイアウォールでFORWARDチェーンのデフォルトターゲットとしてACCEPTを使用することはまったくお勧めできません。これは非常に危険な可能性があるためです。また、ターミナルサービスログ（場所は不明）を確認して、Windowsが何らかの理由で接続が切断されずに受信されていることを確認することもできます。

お役に立てば幸いです。

答え2

SSHポートをINPUTルールに転送してからインポートするだけで、着信iptables -P INPUT DROPICMPがブロックされます。

すべての最新のオペレーティングシステム（少なくともWindows 95以降）は、TCP接続でPMTUD（Path MTU Discovery）を使用します。 MTU = 最大転送単位、デフォルトでは 2 つ以上の小さなパケット（断片）に分割せずに送信できる最大パケットのサイズ。

デフォルトでは、最新のオペレーティングシステムは、そのホップの最大パケットサイズが通常の最大パケットより小さいため、特定のネットワークホップを通過しないことをルータのどこかで検出した場合、常に「フラグメント化しない」フラグが設定されたパケットを送信します。サイズが異なる場合、ルータはICMP「フラグメンテーションが必要」パケットを再送信すると予想します。このパケットには、断片化されていない状態で転送できる最大パケットサイズに関する情報も含まれています。 ICMP メッセージを受信すると、指定されたサイズの使用を開始します。パケットサイズが制限されたホップでこのプロセスが繰り返されると、TCP接続は断片化せずに送信元から宛先に転送できる最大パケットサイズを自動的に検出します。その間のすべてのルータは最適な効率で動作します。

すべてのICMPをブロックすることで、すでに作業に傷を付けました。おそらく、あなたのサーバーは最大サイズのパケットを送信しようとしていますが、他の何かが「これは適切ではありません。MTUを少し下げてください」と言おうとします。ただし、着信ICMPがブロックされているため、サーバーは接続がタイムアウトするまで、意図した受信者に到達しない最大サイズのパケットを送信し続けます。

VPNも使用します。 VPNトンネルに入るすべてのパケットには、2番目のアドレスヘッダーセット（暗号化および/またはVPN自体のニーズにいくつかのオーバーヘッドを追加する）が前に追加される必要があるため、ほとんどのVPN接続はMTUを特定の値に制限します。この値は、以下より少し小さいです。イーサネットのデフォルト値です。したがって、動作するには必ずPMTUDが必要です。

さまざまなクラウドベースのサービスのMTU値もやや低いかもしれませんが、すべてのサービスのMTU値がまったく同じではありません。したがって、小さいMTU値を手動で設定することは理想的ではありません。

ICMPを読み取って処理するのに十分安全であると考えられるICMPパケットと、ファイアウォールにドロップするICMPパケットを自分で決定する必要があります。

また、最新のオペレーティングシステムには、基本的にICMPベースの攻撃に対するいくつかの保護機能がすでに含まれていることに注意する必要があります。たとえば、ICMP エラーメッセージの送信は、動作する接続を処理するよりも優先順位が低いと見なされることがよくあります。そして、発信するICMPメッセージの数は、すでにオペレーティングシステムのカーネル自体によって制限されている可能性があります。ネットワークプロトコルコード開発者は通常完全な愚か者ではありません。

関連情報