☰

想像する：

tag-icon • tag-icon linux networking routing firewall network-interface
想像する：

要するに

TUNインターフェイスから読み取られたパケットは、同じTUNインターフェイスに書き戻されたときにパスを見つけることができません。

全体で

想像する：

マシンにのみ1NIC（eth0）がインターネットに接続されている場合、TUNインターフェースからIPパケットを読み取るアプリケーションを作成しました。

  • 変更なしで同じTUNインターフェイスにパケットを書き換えます。
  • パケットブロック
  • パケットを変更し（ペイロード暗号化など）、操作されたパケットをTUNインターフェイスに書き換えます。

完璧：

次の手順を完了しました。

  1. 私のプログラムを実行します。 TUNデバイスを割り当ててインスタンス化し、デバイスが起動するのを待ちます。

  2. 次に、次のコマンドを実行します。

    ifconfig tun0 up ifconfig tun0 10.0.0.2 route add -net 0.0.0.0 netmask 0.0.0.0 dev tun0 echo 1 > /proc/sys/net/ipv4/ip_forward

  3. これで、私のプログラムは正常にパケットの読み取りを開始します（そしてその内容を印刷/記録します）。

  4. 私のプログラムはパケットを書き換えます。何も変わらないtun0 デバイスを返す

質問:

書き換えられたデータパケットは、eth0やアプリケーション層などの戻りパスを見つけることができません。たとえば、pingをすると：

ping 4.2.2.4

他の端末から：

tshark -i tun0

tun0（私のプログラムでもあります）にICMPエコーパケットが表示されます。

 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=2/512, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=3/768, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Unknown ICMP (obsolete or malformed?)

私のプログラムはパケットをtun0に書き戻し、tsharkそれを確認します（上記のコードで）。

しかし、ICMP要求は到着しません。イーサネット0だから道を見つけることができます4.2.2.4。 IMHOルーティングルールに問題がありますが、修正する方法がわかりません。

どんな意見でも歓迎します。

答え1

もちろん、ルーティングルールに問題があります。カーネルにすべてのパケットをルーティングするように指示しますtun0。 :) そのパケットを再送信すると、代わりにtun0再ルーティングされます。あなたの場合を除いて、「リバースパスフィルタ」によってパケットが破棄されるように聞こえます。つまり、入力したインターフェイスと同じインターフェイスでパケットが返送されるのを拒否します。tun0eth0

関連情報