NetGuardのSOCKSモードが覆うのはTCPだけ、全プロトコルではない

NetGuardは通信を絞り込むためにAndroidのVPNインターフェースを占有し、対応する接続をSOCKSエンドポイントへ渡すことができます。この二つの事実はしばしば「端末はVPN上にある」と読まれますが、それはこの仕組みが支えない結論です。フィルターはパケットを見るのに対し、プロキシが見るのは実際に渡された接続だけです。この二つの文の間にあるのが、カバレッジという問いの全体です。

上流プロジェクトのFAQは、単一サービスという制限とSOCKSオプションの両方を記録しています。オプションの存在は、許可されたすべてのパケットがそれを使う証拠ではなく、カバレッジの疑問はまさにこの隙間から生じます。

一つのアプリの中にある二つの転送経路

実装のTCP側にはSOCKS接続の処理があり、許可されたTCP接続はプロキシと折衝してその中を通せます。UDP側には別のソケット経路があり、その送受信の処理はこのTCPの折衝に依存しません。したがって、フィルターが許可したデータグラムはプロキシを一度も通らずに通常のネットワークへ届くことがあります。これはアプリの欠陥ではなく、二つの経路が実装している内容そのものです。

この区別には、人々が両方向に誤って述べる帰結があります。すべてのUDPパケットを漏洩と呼ぶのは遮断規則を無視しており、拒否されたデータグラムは決して外へ出ません。この構成全体をVPNと呼ぶのは許可された直接経路を無視しており、一部の通信は実際にプロキシなしで外へ出ます。手元にあるのは部分的なプロキシを伴うフィルター済みの端末であり、正直な説明はラベルではなくマトリクスです。

UDPを宣伝することは実装することではない

UDP対応をうたうSOCKSサーバーは、端末のアプリにそれに対応するクライアント側の処理を加えるものではありません。プロトコルの理論上の機能と、インストールされたビルドの挙動は別の話題であり、あなたの通信を説明するのは後者だけです。

実際に動かしているバージョンと設定を確認し、次に無害なデータグラムの流れを試して、それがプロキシに現れるか観察してください。それ以外は機能一覧からの推測であり、機能一覧は意図を述べるもので、コードの経路を述べるものではありません。

DNSは三つ目の経路であり、細部ではない

名前解決はマトリクスに独自の枝を加えます。ローカルのDNSフォワーダー、通常のUDP問い合わせ、プロキシ自身が解決する宛先ホスト名、ブラウザー内の暗号化リゾルバーは四つの異なる構成です。違いは誰が問い合わせを見るか、どのネットワーク経路がそれを運ぶかにあり、これらを混ぜると他の構成について何も証明しない試験になります。

どれを望むかを意識的に決めてください。名前がトンネルを通じて解決されることが要件なら、ブラウザーの設定だけではそれを実現できず、ホスト名を自分で解決するプロキシは実際に扱う接続についてだけ答えを変えます。

プロキシの伝送は自動的に私的とは限らない

素のSOCKSは端末からプロキシへの暗号化されたリンクではありません。エンドポイントが別の保護された経路で到達されているなら、開放されたネットワークへのフォールバックが警告なしに私的な構成を公的なものへ変えるため、その経路と障害時の方針を名指ししてください。プロキシ自身の認証も重要で、共有端末上の開いた待ち受けは誰も会計をしないサービスです。

プロファイルをまたぐ構成にも同じ吟味が必要です。仕事用プロファイルのVPNはその経路を使う通信だけを守り、個人用プロファイルのファイアウォールと仕事用トンネルが併存しても、ファイアウォールの先の接続がそのトンネルに届くことは証明されません。二つのプロファイルが協力すると仮定せず、到達性と認証を検証してください。

ページの読み込みではなくマトリクスでカバレッジを監査する

許可された評価では、関心のある各分類を代表する無害な例、つまり必要なTCP、許可されたUDP、両方のアドレスファミリーでのDNSを選びます。それぞれについて、プロキシされたか、遮断されたか、直接送られたかを記録してください。その一枚の表が成果物であり、読み込まれたページのスクリーンショットよりはるかに役に立ちます。

選択したアプリの通信すべてが遠隔のトンネルを通ることが要件なら、複合的なフィルタリングとトンネル化を明示的に支える実装を選んでください。TCPのみのプロキシ構成は、他の通信を忘れず意図的に扱う限り、より狭い作業には有用であり続けます。