☰

iptables / 元のインターフェイス (eth0) から着信トラフィックを返すためのパス

tag-icon • tag-icon linux iptables raspberry-pi firewall vpn
iptables / 元のインターフェイス (eth0) から着信トラフィックを返すためのパス

私はLinux/IPTABLESを扱い始め、この素晴らしいチュートリアルに従いました。ここRaspBerry Piデバイス（RaspBerryPi OS / Debianを実行）をVPNゲートウェイとして正常に設定しました。同じネットワーク上のすべてのデバイスは手動でネットワーク設定を構成し、そのデバイスのIPアドレスにルーティングを設定できます。その後、デバイスはVPNを介して情報を処理して再送信します（すべて同じネットワーク上）。イーサネット0相互作用）。

私が持っている問題はVPNソフトウェアにあります。Linux用NordVPN削除Tun0VPNの接続を切断またはログアウトすると、インターフェイスが自動的に接続され、ラップトップのインターネットが機能しなくなります。私が理解しているように、これはパケットがまだ転送するように指示されているからです。Tun0インターフェイスがないと、これらのパケットはラップトップに返すことはできません。

すべての着信トラフィックを返すための理想的なプログラムは何ですか？イーサネット0に戻るイーサネット0いつTun0存在しない？

構造:

たとえば、ノートパソコン → raspBerry pi（eth0> tun0> eth0） →ノートパソコン

RaspBerry Piのiptablesは次のとおりです。

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

sudo iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

sudo iptables -A INPUT -i lo -j ACCEPT

sudo iptables -A INPUT -i eth0 -p icmp -j ACCEPT

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

sudo iptables -P FORWARD DROP
sudo iptables -P INPUT DROP

これまでの研究により、次のようないくつかの回答が得られました。

https://unix.stackexchange.com/a/322386

常にトラフィックが開始されたインターフェイスからトラフィックを転送します。

ip route add table 2 default via 192.168.0.1おそらく、次のようになります。

ベストアンサー1

一般的な誤解を修正してください。iptablesルーティングされていません。ルーティングフローが継続可能であるかどうかを制御するだけで、方向は変更されません（変更可能なNATなどを使用しない限り）。ルーティング運命は依然としてルーティングスタックによって行われます。そのため、質問で最も重要なのは、ルートとルーティングテーブルを提供することです（この場合、ルーティングルールも提供する必要があるようです）。

トンネルインターフェイスが消えると、それを使用するすべてのパスも消えます。単一のインターフェイスからルータのパスを取得できます。受信インターフェイスは送信インターフェイスでもあります。イーサネット0。

デフォルトのポリシーは転送されたパケットを破棄するため、iptablesを使用してこのフローを有効にするだけです。

sudo iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT

それはあなたが必要とするすべてです。通常、RPi には 192.168.0.1 ルータを使用するようにデフォルトのルートが設定されているため、追加の作業は不要です。パスが標準でない場合は、質問に追加してこの回答を更新する必要があります。

次は小さな文字:

  • ホストノードがRPiを介してパケットを送信すると、RPiはこれが最良の経路ではないことを検出し、いくつかのパケットを再送信します。ICMPリダイレクトパケットは、192.168.0.1 を介して直接、より直接的なパスを使用できることをクライアントに警告します。ノードは情報をキャッシュし、次のパケットをそのルータに直接送信することを選択するか、RPi を使用し続け、RPi は関係なくパケットを転送し続けることができます。実際のルータはレスポンスをホストノードに直接送り返し、非対称ルーティングを生成します。これらのタスクはすべて同じLAN上で発生するため、同じインターフェイスなので問題はなく、この現象は発生しません。厳格なリバースパスの転送どこかに。

  • したがって、この場合、追加のconntrackルールを使用しないでください（既存のルールで十分です）。-m conntrack --ctstate NEW,ESTABLISHEDすべてのパケットと同じではありません。つながるRPiを迂回するパケットはウィンドウ外TCPパケットを引き起こし、これらのパケットはINVALIDとしてマークされます（ただし、転送は許可される必要があります）。

おすすめ記事