☰

iptables -j REDIRECTは*実際に*パケットヘッダーにどのようなことをしますか？

tag-icon • tag-icon iptables routing tor packet iptables-redirect
iptables -j REDIRECTは*実際に*パケットヘッダーにどのようなことをしますか？

好奇心から透明なTORプロキシに関するいくつかのチュートリアルを読んでいます。これは、ネットワークの観点から見ると非常に興味深いトピックだからです。tun/インターフェイスのみを使用する VPN ゲートウェイとは異なり、tapTOR プロキシは単一ポートを使用します。すべてのチュートリアルでは、次の魔法の行を繰り返します。

iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -j REDIRECT --to-ports 9040

その中には、TORポートであるeth0入力（LAN）インターフェースがあります。9040問題は、なぜそのようなことがネットワークの観点から意味があるのか​​わからないということです。

redirect/チェーンの私の理解dst-natとそれが物理ルーターでどのように機能するかによると、チェーンは次のようにdst-natなります。dst-portdst-addr 今後ルーティング決定を下し、別のものに変更します。たとえば、

  • フォワードdst-nat:192.168.1.2:46364 -> 88.88.88.88:80
  • 後ろにdst-nat:192.168.1.2:46364 -> 99.99.99.99:8080

これは99.99.99.99:8080、IPパケットフローチャネルの追加チェーン（filterテーブルなど）で見られる内容であり、これからパケットがデバイスを離れる時の様子です。

現在、インターネット（このstackexchangeを含む）の多くは、これが基本的redirectにインターフェイスにローカルアドレスを設定するのと同じであると主張しています。これを考慮すると、ルールは次のようになります。dst-natdst-addr

iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -j REDIRECT --to-ports 9040

明らかに言葉ではありません。これがうまくいくなら、TORはみんなパケットの宛先はです127.0.0.1:9040。アプリケーションがパケットを取得し、何らかの方法でそれに応答する一般的なアプリケーション（Webサーバーなど）の場合、これは完全に理解されています。なぜなら、これらのサーバープロセスはとにかくパケットの最終的な宛先なので、宛先はアドレスはlocalhostですが、それは問題ありません。ただし、TORルーターは良いルーターであるため、パケットの元の宛先を知る必要があります。私は何を逃したことがありませんか？DNATローカルアプリケーションが受信する内容に影響しませんか？それともREDIRECT命令の特定の動作ですか？

ベストアンサー1

この回答を確認してください。透明なSOCKSプロキシはどのIPアドレスを使用するのかをどのように知ることができますか？

引用:

iptablesは元の宛先アドレスを上書きしますが、古いアドレスは覚えています。その後、アプリケーションコードは特別なソケットオプションを要求してそれを取得できますSO_ORIGINAL_DST。

おすすめ記事