私は非常に複雑で長いiptablesスクリプトを持っています。手動で挿入/置換または削除を行って、既存のiptables構成を操作することはできません。すべてのルールとカスタムチェーンをフラッシュし、すべてを最初からリロードするスクリプトがあります。このアプローチは、ある程度うまく機能します。
IPパケットにカプセル化されたE1回線など、機密性の高いトラフィックがたくさんあります。これは単に遅すぎるので、すべてのルールを削除して再挿入するだけの余裕はありません。 50msを超えるルールがない場合、多くのものが壊れます。それとは別に、一部の高スループットトラフィックは、部分的に復元されたファイアウォールにぶつかり、最終的に非常に悪いconntrackエントリになり、機能を復元するために手動の介入が必要になります。
解決策は、現在のルールの最後に新しいルールを追加してから、古いルールを削除することです。これにより、理論的には継続的なルールセットが配置される可能性があります。問題は、カスタムチェーンやipsetなどを使用したスクリプトが非常に複雑になり、エラーが発生しやすくなることです。
質問は-私がここで述べた問題を処理する既存のソリューション(iptablesの上に追加のレイヤー)を知っていますか?
前もって感謝します。
iptables-restore
コマンドを使用して新しいルールをロードしてみましたか?これは理論的にはアトミック操作であり、ほとんどの問題を処理する可能性があります。これには、iptables-save
で使用される形式でルールを記述する必要があります。
チェーンを使用する場合、これは非常に簡単です。
チェーンを1つか2つ作成し、それにすべてのルールを追加します。ルールを再適用する必要がある場合は、チェーンをフラッシュ、削除、および再作成するだけです。
したがって、更新中に、確立された接続を許可するルールを上部に挿入し(おそらく、これを常に有効にし、決して触れないルールにしたい場合)、チェーンをフラッシュしてから、新しいルールをチェーンに追加します。これは、可能な限りステートフルルールを使用していることを前提としています。
あなたのような極端なケースの解決策はないと思います。ただし、良いニュースは、古いルールの上に必要なルールを挿入してから古いルールを削除するPythonスクリプトを作成するのは非常に簡単です。
orchidea 10.0.0.1 /etc/exim % iptables -L -n --line-numbers
Chain RH-Firewall-1-INPUT (2 references)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
上記の出力をチェーンとルール番号、たとえば4について解析するだけで、iptables -I chain 4 newruleを実行してから、iptables -D chain5を実行します。
スクリプトの呼び出し方法に応じて、同じチェーンに2つの名前のいずれかを使用するようにスクリプトを調整することをお勧めします(プレフィックスを使用するのが理にかなっています)。したがって、チェーンdropthisの代わりに、set0_dropthisまたはset1_dropthisがあります。
そうすれば、トラフィックを妨げることなく、新しいルールのセットを作成できます。その後、デフォルトのチェーンがフラッシュされ、新しいセットをターゲットとして再作成されます。最適なのは、各デフォルトチェーンに、トラフィックを古いセットまたは新しいセットに転送するルールを1つだけ含めることです。この単一のルールの置き換えは高速です(さらにiptables -A; iptables -D ... 1
で安全です)。その後、古いセットのチェーンがフラッシュされて削除されます。
ラッパースクリプトは、現在アクティブなセットを検出し、それぞれのパラメーターを使用して実際のスクリプトを呼び出します。
これを実現する唯一の方法は、既存のスクリプトを作り直してiptables-restore形式を使用するか、既存のスクリプトを変更してコマンドを実行する代わりにstdoutにダンプし、2番目のスクリプトを作成してiptables-restoreに変換することです。フォーマット。
iptables-restoreはアトミックであることが保証されているため、シームレスなルール置換を行うための唯一の信頼できる方法です。
iptables-restore形式を取得するという点での私の提案は、スクリプトをVMに対して、またはライブマシン上の別のネットワーク名前空間で実行し、iptables-saveを使用して取得することです。 。