web-dev-qa-db-ja.com

TUNインターフェースを使用したIPパケットスニファ/フィルタ/マニピュレータ

要約すれば

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への道を見つけることができます。私見では、ルーティングルールに問題がありますが、変更方法がわかりませんでした。

コメントは大歓迎です、よろしくお願いします

linuxnetworkingroutingfirewallnetwork-interface
3
Hamid

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

1
sourcejedi