ホテルのWi-FiでOpenVPNがつながらない？ TCP 443を試す

クライアントを開き、接続を押して、その後に出るダイアログではなくステータス行を読んでください。ホテル、キャンパス、モバイル回線のあとで接続中やサーバーを待機中に止まるプロファイルは、たいてい経路のどこかでトランスポートを失っているのであって、認証情報を失っているのではありません。次に役立つのは、サーバーに触る前にそのネットワークが何を運ぶのかを調べることです。同じプロファイルが別の場所で動くまでは、何も変えないでください。

まずスマートフォンのテザリングで試してください。そこでトンネルが張れるなら、サーバー、証明書、アカウントはすべて正常で、残る変数は目の前のネットワークだけです。

クライアントから始める：ステータス行を読む

ステータス行はどの段階で失敗したかを教えてくれます。接続中で止まるクライアントはまだホスト名を解決しているか外側のソケットを開いている段階であり、サーバーを待機中まで進むものは経路はあるが応答がなく、認証してから切れるものはまったく別の問題です。クライアントのログとプロファイル自身の remote と proto フィールドは、クライアントが何をしようとしているかを示し、コマンドラインのクライアントでは --verb 4 が同じ詳細を出力します。それを目の前のネットワークと比べることこそが、VPNが遮断されているという言葉を具体的な主張に変えます。

次に、すでに手元にある道具でネットワークを調べます。nc -vzu 203.0.113.10 1194 はUDPデータグラムを送り、curl -v telnet://203.0.113.10:443 はTCPのハンドシェイクが完了するかを報告し、HTTPSページを読み込むブラウザーは、外向きの443がその一台のホストに届くことしか証明しません。小さな調査は、どのポートとプロトコルがそもそもこのネットワークを出られるのかという、VPNクライアントには答えられないことに答えます。

三つのネットワークの挙動はクライアントからは同じに見え、それぞれ別の対処を必要とします。外向き443が開いている場合、プロキシだけが許されている場合、443が透過的に検査装置へ転送されていてその中身を読めない場合です。一つ目は下のプロファイル変更で、二つ目はプロキシ設定で直り、三つ目はハンドシェイクが完了したあと検査装置がそのストリームを好まないと判断した時点で止まることがあります。どれに直面しているかを知ることが、十分の変更と、半日かけてクライアントを入れ直すことの差になります。

リスナーとプロファイルを同時に移す

サーバー側では、ネットワークが許すものにリスナーを合わせます：サーバー設定で port 443 と proto tcp を指定し、サービスを再起動して ss -lntp でソケットを確認します。トランスポートとポートはトンネルの外側にあるため、クライアント側でもプロファイルを合わせる必要があり、.ovpn では proto tcp と port 443、アプリの設定画面では対応するフィールドになります。UDP 1194 を向いたままのプロファイルは以前とまったく同じように失敗し、すでに直したファイアウォールのせいにしたくなります。同じホストが443でHTTPSにも応答するなら、二つのリスナーはそのアドレスとプロトコルを共有できません；VPNに二つ目のアドレスを与えるか、手前に分離装置を置いてください。

最初の接続を両端で tcpdump -ni any port 443 を使って見守ります。クライアントを出て届かないパケットは、結局ネットワークがフィルタリングしているか、プロファイルのアドレスが想定と違うことを意味します。応答なしで届くパケットはサーバーログへ戻します；そこではプロトコルの不一致が破棄されたパケットとしてすぐに現れます。

プロキシだけが外に出られる場合

ゲストネットワークによってはHTTPプロキシ以外を一切許さず、これは閉じたポートとは別の制約で、OpenVPNよりも多くを排除します。PPTP、L2TP/IPsec、素のIPsecしか話せないクライアントは通り抜けられません；そうした設計は外側のプロトコルがサーバーへ直接届くことを前提にしているからです。OpenVPN は可能で、クライアントプロファイルに http-proxy proxy.example.net 8080 を入れ、プロキシがあなたのポートへのCONNECTメソッドを許せば通ります。SOCKSプロキシはさらに簡単で、中身を気にせずストリームを転送します。

クライアントにプロキシ対応がない場合、通常は443上のSSHトンネルが残ります。層がもう一つ増え、ネットワークの運用者に意見があるかもしれないので、アーキテクチャではなく一度の出張のための橋として扱ってください。

残す前に代替手段の代償を測る

TCPの中のTCPにはよく知られた代償があります。外側の接続がTCPでペイロードもTCPだと、セグメント損失が両方の層で再送を起こし、内側の接続は見えない損失から後退します。閲覧はそれに耐えますが、対話的なセッションや通話は影響を受けます。TCP 443のリスナーは、それを要求するネットワーク向けの代替として残し、まだ通るものすべてにはUDPを既定のままにしてください。

選択をプロファイル名とサポートの記録に残します：どのポート、どのプロトコル、どのネットワークがきっかけだったかです。そのうえで、次に機器が更新されたあともそのポートが開いたままかどうかをネットワーク管理者に尋ねてください；黙って消える代替手段は、代替手段がないより悪いからです。