☰

シナリオ：

tag-icon • tag-icon linux networking routing firewall network-interface
シナリオ：

要約すれば

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

略さずに

シナリオ：

マシンに1インターネットに接続されている NIC (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リクエストは届かないeth0そうすれば、 への道を見つけることができるでしょう4.2.2.4。私見では、ルーティング ルールに問題があるのですが、それを変更する方法がわかりませんでした。

ご意見は大歓迎です。よろしくお願いいたします

答え1

もちろん、ルーティング ルールに問題があります。カーネルtun0に、すべてのパケットを からルーティングするように指示しました :)。そのパケットを に送り返すと、ではなく、再びtun0からルーティングされます。ただし、あなたのケースでは、パケットが「リバース パス フィルタ」によってドロップされているようです。つまり、パケットが入ったのと同じインターフェイスからパケットをバウンスすることを拒否しているようです。tun0eth0

関連情報