プロファイルは火曜日には動いていて、金曜日にはクライアントが三十秒回って諦める。あなたのマシンでは何も変わっていない。まさにそこが要点だ。ダウンロードした設定は、ある瞬間の一つのホストを記述したものであり、向こう側の運営者にはその記述を正しいまま保つ義務はない。トンネルが戻るまでセキュリティ設定をいじり始めたくなる。その衝動こそ、証明書の検証を無効にしたプロファイルを動かす羽目になる理由であり、トンネルがまったくないより悪い。

ファイルが記述するのは瞬間であり、契約ではない

設定ファイルは前提の集合だ。このホスト名はこのポートでこのプロトコルで待ち受け、この名前に一致する証明書を提示し、この認証情報を受け入れる。そのうちのどれか一つが成り立たなくなれば、ファイルは古くなっており、修正は境界の運営者側に属する。あなたの設定ではない。

公開ノード一覧 はその性質上、このことを明示している。ノードは有志が運営しており、現れては消え、アドレスは再利用され、ポートはその背後にあるネットワークによって遮断される。一覧は再生成されるスナップショットであり、あなたのディスク上のコピーはより古いスナップショットの写真だ。

商用サービスはよりゆっくりだが、決して変わらないわけではない。認証局は交代し、リスナーは共有アドレスから専用アドレスへ移り、古いプロトコルは引退し、新しい暗号スイートの一覧が届く。そのどれも、クライアントが接続を試みてファイルの期待と違う応答を受け取るまで見えない。

設定に触る前に失敗の段階を読む

エラーメッセージはどの前提が崩れたかを示し、前提ごとに修復はまったく違う。ホスト名がもう解決しないのに暗号をいじるのは、午後を無駄にするだけで誰のためにもならない。

What happensThe assertion that brokeSupported response
Name never resolvesThe host still exists under that nameGet a current endpoint from the operator
TCP connect times outThe listener is on that port and reachableCheck the current published port, then the local network
TLS or key exchange failsThe peer presents the expected identityCompare the certificate, not the cipher list
Authentication rejectedThe account is still validGet credentials reissued or stop using the service
dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

真ん中の行は遮断された経路と壊れたハンドシェイクを分け、三行目は実際に提示された証明書の発行者と有効期間を示す。その発行者がプロファイルで固定したものと違えば証明書は変わっており、クライアント側のどんなオプションでも古い固定を正しく戻せない。

証明書と身元の変化は静かなほうだ

ほとんどの失敗は自ら名乗り出る。身元の変化は名乗り出ない。証明書の名前を固定しているクライアントは、まったく正常な新しい証明書を、多くの人がバグと読むメッセージとともに拒否するからだ。トンネルは問題ない。固定が古いのだ。

何かを結論づける前に身元のオプションを探す。

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

プロファイルが埋め込みCAを持ち、運営者が新しい認証局へ移っていれば、古いファイルは新しいサーバーを検証できない。CAブロックを運営者の公開したものに置き換えるのは正当な修正だ。検証の指示を削除するのはそうではなく、同じキー操作で結果はまるで違う。

クライアントの更新でも、運営者の変更なしに同じ症状が出ることがある。黙って許容されていたオプションが拒否されたり、非推奨のプロトコルが削除されたりする。それはあなたのソフトウェアの互換性の限界であり、サーバーを責める前に同じクライアントで二つ目のプロファイルを試す価値がある。

有効な代替を公開できるのは運営者だけだ

ノードが消えたとき、代替は元を公開したのと同じ出所から来なければならない。「同じサーバー名を使っている」からという理由でダイレクトメッセージで届くプロファイルは、未知の相手による未検証の設定であり、それを取り込むことはその相手にあなたの経路制御を渡すことになる。

確認は安い。公開された場所から現在のファイルを取得し、エンドポイントとプロトコルを一覧と照合し、ファイル名を信じるのではなくCA素材のフィンガープリントを確認する。

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

二つのハッシュが空白だけ違うなら書式の変更だ。エンドポイントが違うなら運営者が何かを移しており、公開されたファイルが正しい。公開されたファイルが手元のものより古ければ、おそらくキャッシュを見ており、古い答えはあなたを間違った方向へ送る。

古い項目を退役させ、何が起きたかを記録する

機能する代替を確認したら、古いプロファイルは予備として残さず削除する。半分だけつながる古い項目は罠だ。障害時に選ばれ、ゆっくり失敗し、調べる人は最初の十分を間違ったファイルに費やす。

設定の外に短い記録を残す。日付、古いエンドポイント、失敗の段階、そして何が置き換えたか。公開ノードは入れ替わり、六週間後に同じ質問が別の人と一緒に来る。ノートファイルの一行が数秒で答える。

もし一つのネットワークからすべてのノードが同じように失敗するなら、別のネットワークからは一つも失敗しないのなら、プロファイルの編集をやめてローカルの経路を見る。キャプティブポータル、フィルタされたポート範囲、傍受するプロキシは無関係なプロバイダーで同じエラーを生み、そのパターンこそ問題が決してファイルではなかった唯一の合図だ。

関連記事