proto udp か tcp-client か:サーバーはどちらを聞いているのか

先月まで動いていたプロファイルが今はタイムアウトし、誰かが proto udp を proto tcp-client に変えようと言い出す。それが正しいこともあれば、サーバーがもう一方のトランスポート用に設定されていないために、何も待ち受けていないポートへ接続するクライアントができあがることもある。このディレクティブが表すのは自分の側がどう話すかであり、相手側にリスナーを作ることはできない。どちらを変える前に、プロファイルとサーバーを一緒に読もう。

選択された接続が使うトランスポートを読む

プロファイルは複数の remote 項目を持て、それぞれが独自のトランスポートを指定できる。クライアントは順番に試すので、最初に見える行が必ずしも適用される行とは限らない。

実際に試されている項目を探し、そのトランスポートを読む。クライアントは黙って次へ進むわけではないので、順番が重要だ。ビルドによってはタイムアウト後にしか次の項目を試さないため、ファイル末尾の使える代替は思ったより数秒遅れて到達する。どのエンドポイントが試されているかをログで見て、最初の行が勝ったと決めつけないこと。

ファイルの先頭近くに proto 行が一本だけあり、その下に remote 項目が複数ある場合、その行はそれを上書きしないすべての remote の既定値になる。既定値をローカルで編集しても、独自のトランスポートを指定する remote 項目には何の効果もない。

grep -nE '^(remote|proto)\b' client.ovpn

UDP と TCP は速度の設定ではない

UDP は順序づけられたストリームを作らずにデータグラムを送るので、トンネル自身のトラフィックが二つ目の信頼できるトランスポートに包まれることはない。TCP は UDP を落とす、あるいは遮断するネットワークを通る経路を与えるが、その代償として入れ子の再送が生じ、損失のあるリンクをより悪く感じさせることがある。

これは到達性の交換であり、普遍的な順位ではない。正しい選択は、クライアントの前にあるネットワークが許すものだ。VPN ポートで UDP を落とす経路は、プロファイルがどれほど良く書かれていても決してネゴシエートしない。経路を試してからトランスポートを選ぶこと。

測定値だけで両者を選ぶのは間違いだ。答えは目の前のネットワークが何を許すかにかかっている。ホテルや企業のプロキシは 443 番の外向き TCP だけを許すことがあり、だからこそプロバイダーはその変種を用意する。ポート番号がなじみ深くても、それは HTTPS セッションではなく、そのポート上の OpenVPN 接続のままだ。

tcp-client が実際に意味するもの

クライアント側のディレクティブは TCP 接続を開始する側を指す。サーバー側は独自の待ち受け形式を使うので、クライアント側の語をサーバー設定に写すと、接続を待つのではなく呼び出されることを期待するリスナーができてしまう。

一致するとは両端がトランスポートで合意することであり、同じ文字列を共有することではない。

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

プロファイルが間違っていると決めつける前に、サーバーが何を待ち受けているか尋ねること。UDP のリスナーは TCP ソケットの一覧には現れず、その逆も同じなので、一般的な表示ではなくプロトコル固有の表示を見る。

プロファイルを読み込んでも接続しないとき

すぐタイムアウトする読み込み済みプロファイルは、通常は認証より前に失敗する。パケットはリスナーのないポートへ向かうか、ネットワークによって黙って落とされる。

経路はできるだけ単純な方法で試す。失敗しているクライアントと同じネットワークから、プロファイルが主張するトランスポートで同じホストとポートに接続する。

UDP の検査が何も得ず、TCP の検査が接続するなら、サーバーはもう一方のトランスポートを提供しており、プロファイルが単に古いだけだ。どちらも応答しないなら、問題はトランスポートの選択より上流にあり、プロファイルをどう編集しても直らない。この二つの場合を見分けるのに一分かかり、決して関係のなかった証明書のデバッグ一時間を節約できる。

動いたトランスポートを記録する

組み合わせが動いたら、サーバー、ポート、プロトコルとともに書き留め、どのネットワークから試したかを記す。

そうしなければ、次にタイムアウトに遭った人が同じ実験を逆方向に試し、おそらく 問題なかったサーバーを変えてしまう。

プロバイダーが両方の変種を公開しているなら、両方のファイルを残し、適するネットワークでラベルを付ける。明確に名前を付けた二つのプロファイルは、クライアントのトランスポートと、それ用に設定されたことのないサーバーリスナーが偶発的に混ざるのを防ぐ。