問題タブ [tun]

VpnServiceを使用して TUN デバイスを作成しました。デバイスの他のネットワーク インターフェイスの中で、TUN インターフェイスが最も優先度が高いのはなぜですか?

更新 #1

これは、TUN デバイスを構成する方法です。

アップデート #2

これは、TUN デバイスを使用しroute -n ない場合の出力です。

これは、TUN デバイスroute -n での出力です。

ショートバージョン。OSバッファから実際にデータを削除せずにファイル記述子から読み取ることができるLinux APIはありますか(read()に似ています)? read() を front() (削除せずに読み取る) と pop() (削除) に相当するものに分割する方法。

シナリオ。独自のネットワーク スタックを介して IP データグラムを配信するために使用する TUN デバイスがあります。問題は、特に上記のアプリケーションが UDP を使用している場合、TUN デバイスが OS によってデータでフラッディングされる可能性があり、スタックが十分に高速に管理できないことです。

ゴール。やりたいこと: データグラムが TUN デバイスに到着したらすぐに、カーネル バッファーから削除せずに読み取り、データグラムを検査し、以下の残りの独自プロトコル スタックで処理できるかどうかを判断し、処理できる場合はポップします。 () カーネル バッファからのデータ、それ以外の場合はそこにデータを保持します。

なぜ。カーネル バッファから pop() しないことが違いを生む理由は、上記のアプリケーションが、ネットワーク プロトコルの下位層が混雑していることを実際に認識することができるためです (ネットワーク インターフェイスを介した独自の write() または send() が失敗するため)。 ）、それに応じて行動します。通常の read() のようにデータが削除された場合、アプリケーションは輻輳について何の手がかりも持たず、フラッディングを続けます。

私は Android VPN アプリを作成中ですが、インバウンド マルチキャスト パケットをテスト アプリに配信しようとするたびに、レンガの壁にぶつかっています。VPN アプリがインバウンド マルチキャスト IP パケット (IP ヘッダーの宛先アドレス フィールドにマルチキャスト範囲内のアドレスが含まれる) を TUN デバイスのファイル記述子側に書き込むと、テスト アプリにパケットが表示されません。マルチキャスト パケットの受信に使用します。ただし、ユニキャスト パケットがテスト アプリによって受信されていることがわかります。また、VPN アプリが混在していない場合でも、テスト アプリがマルチキャスト パケットを受信して​​いることがわかるので、マルチキャストを受信できることがわかります。

私の VPN アプリによって作成された TUN デバイスは、デフォルトでマルチキャスト機能を有効にしていないのではないかと疑っています。また、Android によってそのように公開されている手段も見つかりませんでした。TUN デバイスのマルチキャストを有効にできるかどうかは誰にもわかりませんか? それとも、何か他のものを完全に見逃しているのでしょうか?

次のコードを使用して、VpnService.Builder クラスを使用して TUN デバイスを作成します。

次のコードを使用してファイル記述子を作成し、IP パケットを TUN デバイスに送信します。

Android デバイスで VPN Client を作成しました。tun0 が作成されると、すべてのトラフィックが tun0 にルーティングされます。tun0 経由のトラフィックを防止したいと考えています。tun0 経由のトラフィックを防ぐ方法があるかどうか教えてください。

Linux::TunTap 経由でパケットをユーザー空間に読み込む perl スクリプトを作成しましたが、すべて正常に動作しているようです。

問題は、tuntap デバイスから読み込まれた生の IP パケットを表す文字列を、処理のために適切なデータ構造に変換するにはどうすればよいかということです。特に、送信元、送信先、およびシーケンス番号が気になります。

明らかに、生の IP パケットは、元の形式では人間が判読できるものではありません。tuntap インターフェイスを介して ping を送信した後の出力は次のとおりです。

{{{�}/��8V�| !"#$%&'()*+,-./0123456ET��@@4

このデータをプログラムで処理できるようにするには、ここからどのように進めればよいですか?

TUN インターフェイスを使用してワイヤレス デバイスの最大スループットをテストしようとしていますが、実際にデバイスに到達する前にパケットがドロップされる送信バッファのオーバーフローを回避したいと考えています。したがって、理想的には、TIOCOUTQ を使用して送信バッファーにクエリを実行し、オーバーフローすることなくキューに常にデータがあることを確認したいと思います。以下に示す簡単なテストを作成しました。

標準のイーサネット デバイスを介してルーティングされるように sock が作成された場合、出力はゼロ以外になりますが、TUN インターフェイスを介してルーティングされるように作成された場合、出力はすべてゼロになります。この場合、データを消費するプロセスがなかったため、バッファがいっぱいになると思います。データを消費するプロセスがある実際のアプリケーションでも同じ動作が得られます。

したがって、TIOCOUTQ は単に TUN インターフェイスでは機能しないという結論が正しいかどうか、および送信バッファーの状態を判断する他の方法があるかどうか疑問に思っています。