OpenVPN 用 SOCKS5 プロキシ：TCP トンネルか、アプリをプロキシするか

プロキシ経由の外向き通信しか許さないネットワークでは、動いていたプロファイルが突然死にます。その失敗で最も面白みのない変数がプロキシのアドレスです。すべてを決めるのはプロキシが中継するトラフィックの形で、これらのプロキシはバイトストリームを転送し、UDP トンネルはそれではないからです。残るのは二つのアーキテクチャで、壊れる場所が異なります。

一つの制約が設計を決める

SOCKS5 には UDP アソシエーションモードの仕様があります。それでも OpenVPN クライアントのプロキシ対応はストリームを前提に組まれており、たとえば socks-proxy は TCP プロファイル向けと記述され、HTTP CONNECT プロキシにはデータグラムの経路が一切ありません。ドキュメントの一行が、設定ファイルに触れる前にアーキテクチャを決めます。

したがって問いは、どのプロキシを選ぶかではありません。トンネルがストリームになるのか、それともデータグラムのままで、プロキシ処理を何か別のものに吸収させるのか、です。

選択肢 A：トンネルをストリームにする

これには TCP リスナーを持つサーバーと、プロキシを指定するクライアントプロファイルの両方が必要で、忘れられがちなのはサーバー側です。

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

最後の行を http-proxy proxy.internal 8080 に置き換え、プロキシが HTTP を話す場合は資格情報ファイルを追加します。プロキシは VPN ポートへの CONNECT を実行する必要があり、サーバーは TCP で応答しなければなりません；UDP のみのリスナーはその試行を無視します。443 を選ぶのは実際的な判断で、多くの制限ネットワークがそれ以外をほとんど許さないからです。

コストは TCP の上に TCP を重ねることです。外側のセグメントが一つ落ちると、その接続を共有する内側のストリームがすべて止まるため、本来は独立していた回復が共有されます。セットアップにも時間がかかり、不安定な外側の経路は遅いトンネルではなく不安定なトンネルになります。

選択肢 B：トンネルをそのままにする

トンネルを UDP のままにしなければならない場合、設定する場所はトンネルではありません。代わりに、アプリケーションからの外向き TCP がローカルの SOCKS リスナーへリダイレクトされ、アプリケーションはプロキシの存在を一切知りません。Linux では通常 redsocks と nat テーブルの NAT REDIRECT ルールです。

ここでも TCP のみです。privoxy のような HTTP 専用プロキシは任意のプロトコルを中継できず、この設計はアプリケーションにデータグラムのサポートも加えません。

ソフトウェアが対応している場所では、各アプリケーションにプロキシを直接伝えるほうが普通は優れています。監査しやすく、実際に見える場所で失敗するからです。

それぞれの選択肢が破綻する場所

選択肢 A が破綻するのは、サーバーに TCP リスナーがないとき、プロキシが CONNECT の宛先を拒否したとき、あるいは外側のストリームがトンネルの必要量を下回るよう絞られたときです。最初の二つはプロキシのログに記録を残し、三つ目は確立したのに何かがおかしいと感じる接続を残します。プロファイルを編集する前にそのログを読んでください、権限の問題と容量の問題を切り分けられるからです。完了した CONNECT は調査をトンネルの内側へ移します。

選択肢 B が破綻するのは、データグラムを必要とするすべて、プロキシが理解しないプロトコル、そしてリダイレクトのルールはあるのにルーティングがトラフィックを脇へ流すホストです。

どちらの選択肢もデバイスの要件を変えません。パケットはカーネルがルーティングする前に依然として TUN か TAP ノードを必要とするため、プロセスは今も /dev/net/tun への権限を必要とします。ラッパーはそのノードが開いた後に何が起きるかを変えるだけで、必要かどうかを変えるわけではありません。

どの経路を作ったかを証明する

トレイアイコンではなくソケットを見て、VPN プロセスがプロキシのアドレスへの確立済み接続を保持し、プロキシが到達を求められたターゲットをログに残していることを確認してください。

ss -tnp | grep openvpn

次に、トンネルだけが提供できる宛先へ、そして トンネルのリゾルバーだけが答えられる名前へ向かいます。死んだトンネルなのにプロキシ接続が完了しているのは、通常、遠端がプロファイルに記されたトランスポートを一度も提示しなかったという意味です。

トランスポートと接続を受け入れたプロキシを長く残る場所に書き留めてください。同じプロファイルが別のネットワークで失敗したとき、そのメモが数秒でプロキシを除外するか確認します。