NetDiag+
WireGuard のハンドシェイクが iOS だけで失敗する
同じネットワーク、同じ設定ファイル。Linux のノートと Android の端末は即座につながるのに、iPhone だけが handshake did not complete を繰り返す。その iPhone を 5G に切り替えると、トンネルはすぐ張れる。この時点でほぼ全員が MTU 設定に手を伸ばし、ほぼ全員が一晩を無駄にします。失敗したハンドシェイクが MTU の問題であることはありえないのです。
調べる順番
- MTU をいじるのをやめます。 WireGuard のハンドシェイク開始パケットは 148 バイト、応答は 92 バイトです。これまで運用されたどの MTU にも収まるので、分割されているものは何もありません。ハンドシェイクが完了しないのは、パケットがそもそも届いていないという意味です。MTU を 1420 に戻して、そのままにしてください。
- UDP が端末から出ているかを確かめます。 失敗する Wi-Fi 上で STUN 問い合わせを実行します。応答があれば UDP の送出は正常で、問題は特定のポートかエンドポイントです。ここではタイムアウトするのにモバイル回線では応答するなら、このネットワークがこの端末に対して UDP を選別しています。
- 二台の端末が見ているものを並べます。 iPhone の IP、サブネットマスク、ゲートウェイ、DNS をノート側の値と並べてください。サブネットやゲートウェイが違えば、端末はゲスト VLAN に入れられているか、ルーター側で端末別のプロファイルを当てられています。制限はそこに住んでいて、あなたの設定ファイルの中にはありません。
無料 · 25のツール · 買い切りで広告を削除 · サブスクなし
実際によく聞かれること
なぜ 5G では動いて Wi-Fi では動かないのですか？
それが手元にある最も有用な手がかりです。設定もサーバーも同一で結果が違う — つまり変数はネットワークであり、トンネルではありません。携帯事業者はハンドシェイクを通し、この Wi-Fi は通していないのです。
MTU を 1280、1200、1100 と試しましたが何も変わりません。
当然の結果です。MTU が支配するのはトンネルの内側を運ばれるパケットの大きさで、それが問題になるのはトンネルが存在してからです。ハンドシェイク完了前にはトンネルも、分割すべきものも存在しません。
ネットワークが UDP ポートを塞いでいる可能性は？
単独の原因としては最も可能性が高く、とくにホテル、学内、社内、一部のモバイルホットスポットで起きます。サーバーの待ち受けポートを 443 か 53 に移してみてください。これらのポートを塞ぐと全員のウェブが壊れるため、通常は通過します。
プライベートリレー、IP アドレス追跡の制限、プライベート Wi-Fi アドレスはどうですか？
検証中は切っておく価値がありますが、原因であることはまれです。これらが変えるのは「どのアドレスから見えるか」であって、UDP パケットがエンドポイントに届くかどうかを決めるものではありません。
では WireGuard で MTU が本当に関係するのはいつですか？
ハンドシェイクのあとです。特徴は、トンネルは問題なく張れるのに大きいものすべてで止まること — ページが半分だけ読み込まれる、転送が数キロバイトで固まる。IPv4 上での通常値は 1420 です。
トンネルは張れるのに大きな転送で止まるなら、そのときは本当に MTU の問題です。 本当の Path MTU を測る方法 →