2 つの物理インターフェイス eth1 と eth2 があるとします。
eth1には192.168.0.1が割り当てられています。
eth2には192.168.0.2が割り当てられています。
1つのローカルプロセスは192.168.0.2でリッスンし、もう1つのローカルプロセスは192.168.0.1で接続されます。
ipパケットはiptableのOUTPUTおよびINPUTチェーンを通過しますか、それとも一種の段落がありますか? FORWARDチェーンを通過しますか?
答え1
交通は決まったルートに従います。
では、どのようなものになるのか、どうすればわかりますか?パスを確認してください。ここでは、ホストに属するアドレスからホストに属するアドレスに移動します。lo
この場合、NICハードウェアを含める必要はないため、常に選択(ループバック)インターフェイスが発生します。
クライアントが最初に192.168.0.1にバインドする場合(ほとんど発生しません):
$ ip route get from 192.168.0.1 to 192.168.0.2
local 192.168.0.2 from 192.168.0.1 dev lo uid 1000
cache <local>
これは通常発生します(ただし全体の結果は同じです)。
$ ip route get to 192.168.0.2
local 192.168.0.2 dev lo src 192.168.0.2 uid 1000
cache <local>
この結果の結論を強調すると、次のようになります。いいえeth0
またはを使用しますeth1
が、使用しますlo
。
Netfilter(したがってiptables)ネットワークスタックに沿って作業します(ルーティングスタック部分は次のとおりです)。
渡すジェーンエンジェルハート- 自分の作品、由来静的変数ジェネレータ パプアニューギニア、CC-SA 3.0、協会
ローカルアプリケーションはパケットを送信します。これがフィルタ/出力チェーンです。また、他のチェーン(他のOUTPUTおよびPOSTROUTINGチェーン)を巡回しますが、フィルタテーブルにのみ興味があります。パケットはループバックされます。これはインターフェースの特殊属性ですlo
。これはルーティングスタックに新しいパケットのように到着するため、ルーティング決定を行うためにPREROUTING処理(ただしPREROUTINGチェーンはフィルタテーブルに接続されていません)に従います。ローカル宛先パケットなので、INPUT分岐も従います。パケットが宛先アプリケーションに到達します。
標準Linuxステートフルファイアウォールiptables少なくとも、次のルールを使用してください(-I
私は通常、ルールの順序を強制するために+数字を使用します-A
)。
iptables -I INPUT 1 -m conntrack --ctstate established,related -j ACCEPT
iptables -I INPUT 2 -i lo -j ACCEPT
その後、通常、そのポリシーはDROPに設定されます。
iptables -P INPUT DROP
2番目のルールは特定の環境ではセキュリティの弱点と見なすことができますが、ループバックインターフェイスを介して通信できるようにしたい多くのアプリケーションがこのルールなしで失敗する可能性があるため、しばしば存在し、必要です。
したがって、これらの使用を防ぐ必要があるルールは、2番目のルールの前に挿入する必要があります。さらに、そのインターフェイスのアドレスではないインターフェイスに基づくルールは、ローカルの状況を解決しません。
したがって、2番目のルールを削除すると、次のようになります。
iptables -D INPUT -i lo -j ACCEPT
次に、たとえば、OPの例で使用されるHTTPサービス例外を受け入れます。
エラー(OPの状況と一致しません):
iptables -I INPUT 2 -i eth2 -p tcp --dport 80 -j ACCEPT
許可:
iptables -I INPUT 2 -d 192.168.0.2 -p tcp --dport 80 -j ACCEPT
また、受け入れられ、通常行われます。
iptables -I INPUT 2 -i lo -j ACCEPT iptables -I INPUT 3 -i eth2 -p tcp --dport 80 -j ACCEPT
まったく同じではありません。たとえば、側面のクライアントはeth1
ケース3を使用してHTTPサービスにアクセスできませんが、ケース2を使用するとHTTPサービスにアクセスできます。同様に、リスンサービスが192.168.0.2の代わりにINADDR_ANY(0.0.0.0)を受信した場合、127.0.0.1にアクセスすることはケース2では機能しませんが、ケース3では機能します。