OpenVPN の内側で TLS はどこに位置し、何が形を変えるのか

OpenVPNがTLSを使うのは事実だが、そこから人がよく広げる主張は支えきれない。トンネルがだからといってサイトを訪れるブラウザのように見える、という主張である。前半は正しい。後半は正しくない。ここでのTLSはOpenVPN自身のコンテナの内側を通る制御チャネルに属し、まったく別の暗号を備えたペイロードチャネルと並んでいる。だから先頭のバイトを見る者はOpenVPNを見る。

ひとつの封筒に二つの会話

セッションは、ひとつの封筒を共有する二つの会話だと考えてほしい。一方は証明書を検証し、鍵素材を導出する。もう一方は、実際に送っているものを最初の会話が生み出したもので暗号化する。

封筒とはプロトコルのことだ。すべてのパケットは自分の種類を示す小さなヘッダーで始まり、そのヘッダーが何よりも先に届く。

実際に最初に届くもの

その順序のため、回線上で最初に現れるのはTLSレコードではない。OpenVPNのヘッダーであり、そのあとにヘッダーが告げるチャネルの内容が続く。ClientHelloはその中にあるが、バイトゼロではない。違いに気づくのに復号は要らない。形だけでばれてしまう。

既定値もここでは効く。プロファイルがTCPを選ばない限り、流れはUDPで1194に向かう。どちらでも外見はトンネルであり、ウェブ要求ではない。

形を変える三つの正直な方法

stunnelのようなTLSターミネーターは両端のポートでTLSを受け、復号したストリームをローカルでOpenVPNに渡すので、ネットワークにはそのポートへのTLSが見える。最初のバイトからTLSであるプロトコルはさらに違う振る舞いをする。ocservが実装するAnyConnect互換のやり取りは、多くのネットワークがすでに想定している企業のリモートアクセスに似ている。Windowsに付属するSSTPも、別の製品で同じ性質を持つ。

Linuxでは、SSHの-wオプションがSSHセッションの内側でポイントツーポイントのリンクを運ぶ。SSHだけが許されたプロトコルという状況では役に立つ。そのネットワークからSSHがすでに通るなら四つのうち最も安く、通らないなら最も役に立たない。

どれも変えないこと

どれも、トンネルが届く範囲を変えない。遮断されたアドレスを届くようにもしないし、誰かを認証もしないし、経路を決めもしない。

ラッパーは部品を一つ増やす。二つのリスナーと二つの設定ファイルは故障箇所が二つあるということで、どちらも利用者の席からは同じに見える。導入する前にそこを予算に入れておくべきだ。セッションは一つの宛先への単一の長命な暗号化フローのままで、その量と時間は見えたままである。

まず診断し、それから選ぶ

だからまず診断する。落とされたUDPにはTCPモードで応える。認識されたシグネチャには別のプロトコルかラッパーで応える。遮断を知る前に道具を選ぶと、同じ理由で全部失敗する三つの層を維持することになる。

ウェブのポートだけを許すネットワークなら、選択肢は443のTLSベースのプロトコルに狭まる。三つを同時に当てはめると誰もデバッグできない積み重ねになるので、一つ変えて同じ流れを試し直す。

どれも当てはまらないなら、正確な答えはこのネットワークはあなたのためにトンネルを運ばない、である。それは努力の失敗ではなく発見だ。より多くの選択肢を回しても、上流で決まった方針は覆らない。

そのすべての手前に一つの境界がある。他人のネットワークでトンネルを動かす許可は方針の問題であり、仕組みが機能するかどうかとは別に決まる。これらの事実は観察者に見えるものを説明するが、許可を与えるものではない。