自宅ではVPNが接続するのにホテルのWi-Fiではタイムアウトする
同じノートPC、同じアカウント、別のネットワーク。エラーコードを段階として読み、名前を確認し、どの設定も変える前に外側のパケットを取得します。
ノートPCは自宅のWi-Fiに参加し、クライアントは三秒で接続し、同じプロファイルが一時間後にホテルで失敗する。その間に何も更新されていない。顧客を目の前にしてこれをたどる作業は、主にどのエラーがどの段階に属するかを知ることにある。役に立つ情報はクライアントが出力するコードの中にあり、失敗したという事実の中にはない。以下の四つの手順を順番に実行すれば、名前、パケット、ポート、ポリシーのどれに拒否されたかが分かる。
エラーコードは判定ではなく段階として読む
トンネルが存在する前に、クライアントは三つの別々の節目に到達する。サーバー名を解決し、ネットワーク上の何かから応答を得て、セキュリティアソシエーションを交渉する。各節目には独自の失敗メッセージがあり、特にWindowsは、どの段階に属するか分かれば多様なコードを惜しみなく返す。
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
そのうち二つのコードは、ネットワークに非がないことを意味する。789は、パケットが流れていて両端が暗号について合意しなかったという意味であり、自宅で直せる設定の問題である。868は、外に出る必要のあるパケットがそもそもなかったという意味であり、名前が解決するまでトンネルの設計は無関係である。コードを正しい段階に振り分けることは、どんな取得よりも時間を節約する。次の三つの手順のどれを飛ばせるかが分かるからだ。
クライアントがWindowsでない場合は、それなりに慎重に構える。サードパーティのクライアントはこの大半を「接続失敗」にまとめてしまう。だから次の二つの手順は、そのメッセージにまったく頼らない。
トンネルを責める前に名前を確認する
ホテルや空港のネットワークはDNSを常に横取りし、ポータルのアドレスで応答するリゾルバーは、死んだサーバーとまったく同じに見える失敗を生むので、ローカルのリゾルバーが言うことと公開リゾルバーが言うことを比べる。
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"二つの応答が違えば、あなたは誘導されており、それが解決するまで残りの診断は無駄になる。とくにポータルのアドレスはTCP接続を喜んで受け入れてから停止する。だからブラウザーで試すと、ファイアウォールによる遮断のように見えるのだ。
次に、到達したいアドレスが実際に使われているものかを確認する。クライアントによっては前回の解決結果をプロファイルの存続期間中キャッシュするので、DNS変更後の再接続も古いアドレスへ向かう。再試験の前にクライアントを完全に閉じること。同じウィンドウで切断と接続を押すのではなく。
どの外側パケットが消えるのかを突き止める
トンネルには、あなたとサーバーの間の経路に完全に属する外側のフローがあり、中間装置が分類して落とすのはこのフローである。クライアントでそれを取得し、動作するネットワークと失敗するネットワークを比較する。Windowsなら内蔵の取得で最初の見当には足りる。
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl見たいのは、パケットがそもそも出ているか、そして何かが戻ってくるかである。外に出て何も戻らないなら経路か遠端が落としている。まったく出ていないならクライアントが送信まで至っておらず、名前解決かローカルのファイアウォールポリシーに話が戻る。
同じ試験をスマートフォンのテザリングで繰り返す。これは手元で可能な最も情報量の多い比較である。ノートPC、クライアント、資格情報を同一に保ったまま、ホテル内のあらゆる装置を経路から外せるからだ。テザリングでトンネルが上がるなら、サーバーを見るのはやめる。そこでも失敗するなら、ネットワークが原因ではなかったクライアントかアカウントの問題がある。
トランスポートを一つ変えて再試験する
外側のフローが落とされていると分かったら、実務的な問いはネットワークがどのフローを許すかである。多くの制限付きネットワークは外向きTCP 443を許可する、そうでなければ機能できないからであり、だからこそリスナーをそこへ移すのが通常の答えで、OpenVPNでは、サーバーが変更されるまでクライアント側の切り替えになる。
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4IPsecクライアントには独自の設定パネルに同等のつまみがあり、通常はTCP上のIPsecやNATトラバーサルと呼ばれる。これを変えることも診断になる。TCPでトンネルが上がりUDPで死ぬなら、ネットワークがUDPをフィルタしていると証明でき、その場所を訪れるたびに必要になる設定も見つかったことになる。
最初の試行でルーターの機能を無効にしたくなる誘惑に抗う。ホテルのネットワークでステートフル検査やフラッド保護を切ることはそもそもできないし、自分の機器では一台のノートPCのために実際の保護を手放すことになる。どの設定が結果を変えたかを記録し、元に戻してから、ネットワークがすでに許しているトランスポートを探す。
二つ目のネットワークで同じプロファイルを検証する
チケットを閉じる前に、変更が建物を出ても生き残ったことを証明し、元のネットワークで元の設定のまま再接続して最初の三十秒を取得し、クライアントがテザリングと同じ状態に達することを確認する。
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress最後のコマンドが炙り出す区別は残す価値がある。プロファイルは接続済みのトンネルを報告しても、その内部のルーティングが誤っていることがあり、それは「VPNは上がっているが何も動かない」という別の記事になる。編集後にトンネルの種類が変わったなら、そのプロファイルは試験したものではない。
そして、次の人が見る場所に所見を書く。「この拠点では社内プロファイルにTCP 443が必要で、UDP 500はホテルがフィルタしている」は同僚が行動できる文である。「ホテルではVPNが不安定」はそうではなく、来月また同じ一時間が費やされることを保証する。