2 つのブリッジを介して複数の VM を実行しているサーバーがあり、iptables を介してホストを保護したいと考えています。
したがって、IN/OUTPUT: drop と FORWARD: accept のデフォルトと、ssh アクセスを許可するためのいくつかの IN/OUTPUT ルールがあります。
現在、この設定で問題となっているのは、コマンドが出力のいくつかの行を生成するときに ssh セッションがフリーズしているように見えることです。たとえば、dateは動作しますが、iptables -Lまたは はtop出力の途中でハングします。 でセッションを強制終了し~.、再度ログインして、iptables をデフォルトに戻すと、すべてが再び動作します。
また、iptables ルールを設定した後、問題が発生するまでにしばらく時間がかかります。正確な時間枠は特定できませんでしたが、5 ～ 20 分の間だったと思います。
このような問題の原因は何なのか、またそれをどのように診断すればよいのか、何かご存知ですか?
答え1
実行してみてくださいiptables -L -n(-n オプションを追加してください)。名前解決により、iptables -L がハングする可能性があります。
答え2
ICMPを完全にブロックしていますか？もしそうなら、PMTU ブラックホール。
答え3
確立されたトラフィックの通過を許可する iptable ルールはありますか?
iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
私もネットワークのスプリットホライズンが原因でこの問題が発生したのを見たことがありますが、iptableルールを削除すると問題は解消されるため、これはあなたの問題ではないようです。
答え4
これは MTU ブラックホールの問題である可能性があります。
MTU は最大伝送単位、つまり各側が処理できるパケットの大きさです。イーサネットのデフォルトは 1500 バイトですが、これが唯一の可能性ではありません。
短いコマンドは、両方の MTU サイズを下回っているため機能します。長いコマンドは、MTU サイズを下回っているため機能しません。
接続の両端が同じ MTU を使用していない場合、または中間のネットワークの MTU が小さい場合、システムは何らかの方法でこれを検出する必要があります。このプロセスはパス MTU 検出と呼ばれます。
これは ICMP メッセージで発生します。すべての ICMP をブロックすると、有用なものもブロックすることになります。
詳細はこちら:ICMP をブロックしないのはなぜですか?
また、中間の小さな MTU ネットワークがレイヤー 2 (たとえば、設定したブリッジ) である場合、パス MTU 検出は機能せず、パケットはドロップされ、スイッチ/ブリッジおよび/またはイーサネット インターフェイスでエラーとして表示されます。