OpenVPNプロファイルが自宅では動くのにホテルで失敗する理由

オフィスのWi-Fiとホテルの部屋では、同じノートPCにまったく異なる二つのネットワークが与えられることがあり、その間にあるプロファイルは何も知りません。自宅で動く設定は、寛容な上流回線、正常な名前解決、トンネルが運ぶものと衝突しないローカルサブネットを前提にしています。これらの前提はそれぞれ独立して崩れ得ます。

これをデバッグする有効な方法は、ネットワークを四つの独立した事実として扱い、順番に検証することです。まずプロファイルを当て推量すると、何も直らず証拠を覆い隠す変更になりがちです。

場所によって変わる四つのネットワーク事実

一つ目の事実は、ローカルネットワークがそもそも外に出してくれるかどうかです。キャプティブポータルは端末をログインページへ通し、そのページが完了するまで他のすべてを遮断しますから、プロファイルがどれほど正しくてもトンネルは開始できません。

二つ目は名前解決です。DNSを横取りするポータルはすべての問い合わせに自分のアドレスで応答するため、VPNのホスト名はポータルに解決され、クライアントはWebページへトンネルを張ろうとします。

三つ目はトランスポートのフィルタリングです。閲覧だけを許可したいネットワークは、TCP 443を任意の宛先へ通し、UDPを含むほぼすべてを落とします。

四つ目はアドレッシングです。ローカルサブネットがトンネルの向こう側のネットワークと重なっていたり、上流回線が使えるIPv4経路をまったく提供しないことがあります。

名前解決とキャプティブポータル

プロファイルのホスト名をサーバーの数値アドレスに置き換えて、もう一度試してください。IPは接続できて名前がだめなら、原因は名前解決で、プロファイル自体は問題ありません。

VPNに触る前にブラウザを開き、普通のHTTPページを開いてみてください。ログインページへのリダイレクトはポータルが未完了だという意味ですから、完了してから再接続してください。多くのホテルは数時間でセッションを失効させるので、ログイン問題ではなく日中に切れるように見えます。

数値アドレスでも失敗するなら、名前解決は原因ではありませんからトランスポートへ進んでください。試したアドレスは残しておけば、次の確認でパケットがそもそも端末を出たかどうかが分かります。

トランスポートのフィルタリング：まずUDP、予備としてTCP 443

UDP 1194上のOpenVPNのフローは、ホテルのファイアウォールが見覚えのあるものには見えないため、エラーもなく破棄されます。クライアントはタイムアウトまで再試行し、利用者には拒否ではなく、決して確立しない接続が見えます。こうした挙動のファイアウォールは破棄を目に見える場所に記録することはほとんどありません。拒否がないこと自体が手がかりです。

TCP 443は、ネットワークが通常のHTTPSと区別できないため信頼できる予備です。存在する場合は、サーバーもそのトランスポートとポートで待ち受ける必要があり、クライアントだけを変えると別の種類の失敗になるため、事業者のTCPプロファイルを使ってください。TCPプロファイルがなければ、ポートを書き換えて作るのではなく事業者に問い合わせてください。サーバー側の合意が必要で、不一致はまたファイアウォール問題のように見えます。

性能の代償を見込んでください。TCPの内側のTCPは損失のある回線で再送を増幅するため、動くTCPトンネルでも混雑したホテルのネットワークでは遅く感じられます。これは到達性との引き換えであり、追いかけるべき不具合ではありません。

アドレスの衝突とIPv4のない上流回線

トンネルは確立しても何も運ばないことがあります。ローカルLANと遠隔ネットワークが192.168.1.0/24のようなプレフィックスを共有すると、クライアントは遠隔ホストを直接接続とみなし、パケットをトンネルではなくローカルリンクへ送ります。症状は、到達できないサブネットが一つあるだけの接続成功で、サーバー側のルート問題と誤読しやすいものです。

恒久的な修正は、遠隔LANを珍しいプライベート範囲へ移すことです。自宅で誰も使わない範囲、たとえば10.42.0.0/24を選べば、一か所だけでなく将来のすべての場所で問題を防げます。その場しのぎはそのホテルやホットスポット、ルーターを避けることで、まったく修正ではありません。

モバイル回線は二つの変種を加えます。キャリアグレードNATは着信接続が届かないことを意味し、サーバーを運用する場合には重要ですが、外向きクライアントには関係ありません。NAT64変換を伴うIPv6のみのAPNでは、実際のIPv4経路を要求するクライアントが失敗することがあり、通常の対処はAPNのプロトコルをIPv4またはデュアルスタックに変えることです。

トンネル確立後の症状

接続してから沈黙するトンネルは通常、ブロックされたポートではなくkeepaliveかMTUの問題です。一定の分数で切れる接続はkeepaliveや再ネゴシエーションのタイマーを示します。応答が止まったら再起動するようクライアントに設定し、pingは通るのに大きな転送が止まるなら、より小さいトンネルMTUを試してください。

助けを求める前に、試したアドレスと応答の有無、使ったトランスポートとポート、失敗したネットワークのローカルサブネットの三つを書き留めてください。これらを合わせると、名前解決・トランスポートのフィルタリング・アドレスの衝突を切り分けられ、証拠と向き合って生き残る原因が分かります。