新しいホットスポットのクライアントが IP 取得で止まるのは VPN の不具合ではない

スマートフォンがホットスポットに参加し、「IP アドレスを取得しています」のまま止まり、やがて諦めます。当然の結論は端末の VPN が DNS に干渉しているというもので、そこで人々はリゾルバや追加したルールを編集し始めます。それは間違った段階です。クライアントはローカルアドレスを一度も受け取っておらず、それがなければゲートウェイもリゾルバも転送するものもないので、ホスト側の端末の VPN 設定ではこの失敗を説明できません。接続、ローカルアドレスの割り当て、転送は三つの別々の段階であり、トンネルが関わるのは最後の段階だけです。

三つの段階と、いまどの段階にいるか

まず接続です。クライアントがホットスポットの無線ネットワークに参加し、パスワードの誤り、WPA3 の不一致、無線の互換性の問題はここで失敗して、クライアントはたいていそう表示します。次にアドレスの割り当てで、IPv4 ではクライアントがリースを要求してアドレスとローカルのゲートウェイ設定を受け取り、一方 IPv6 は通常 DHCP ではなくルーター広告を使います。AOSP のテザリングに関するドキュメントが説明しているとおりです。三つ目が外向きのアクセスで、ホスト側の端末は許可された通信を自分が選んだ上流の経路へ転送します。それが自身のトンネルである場合も、そうでない場合もあります。

クライアントの表示が段階を教えてくれます。アドレス取得で止まっているのは第二段階で、まだインターネットへパケットは出ていません。接続済みでアドレスもあるのに何も読み込めないのは第三段階で、ここでは経路、名前、トンネルの適用範囲がすべて関係します。クライアントが第二段階で止まっているのに第三段階を診断するのは、五分のリースの問題を DNS 編集で半日つぶす近道です。

俗説：経路化された VPN はローカル DHCP を遠隔要求に変える

経路化されたトンネルは、選択した宛先について IP パケットを運びます。DHCP ディスカバーはホットスポット自身のセグメントにおけるブロードキャストであり、端末のテザリングサービスがローカルで応答します。だからトンネルが上がっていてもクライアントはアドレスを取得できるのです。意図的にブリッジまたはリレーする設計だけがそのやり取りを別の場所へ送り、それは別の失敗の特徴を持つ別の構成です。

つまり「VPN サーバーが DHCP に応答しない」は診断ではなく、モデルの誤りです。ローカルの仲介者は端末の上にあります。応答をやめたなら、理由はローカルです。テザリングサービス、クライアント数の上限、リースプール、あるいは接続を正しく完了しなかったクライアントです。それらのどれもトンネルの遠い側にはありません。

既存のクライアントが動くことは実際に何を証明するか

すでに接続していたノート PC が動き続け、新しい端末が動かないなら、ホットスポットと上流の経路はおおむね生きています。その比較は有用ですが、どの構成要素が原因かの証明にはなりません。動いているクライアントは、変更前のリースを保持して静かに更新しているだけかもしれないからです。

そこにいる間に確認する価値があるローカルの上限が二つあります。ホットスポットは有限のリースプールと設定可能なクライアント上限を提供するので、参加して休止した端末がアドレスを保持したまま、新しい端末が待つことがあります。また、別のネットワークの静的構成を覚えているクライアントはリースをまったく要求しません。外からは同じに見え、端末側ではなくクライアント側で直します。

比較はローカルで可逆に保つ

ポリシーが許す端末で、トンネルを無効にした状態と有効にした状態で新しいクライアントの一度の参加を比較し、ホットスポットとクライアントはそれ以外変えないでください。端末とクライアントのバージョン、選択したプロファイル、失敗した正確な段階を記録します。管理された端末では、よりきれいな試験のために適用を無効にするのではなく、承認された比較を依頼してください。

トンネルに依存した一貫したリース失敗は、ローカルのポリシーや実装間の相互作用について有用な証拠です。端末上のすべての転送規則と NAT 規則を消してよいという許可証ではありません。それらの規則は無関係な通信を守っており、広い転送許可はローカルの DHCP サービスが応答をやめた理由を説明しません。

欠けたリースを推測の静的アドレスで覆ってはいけません。意図的な静的構成には、実際のサブネット、ゲートウェイ、割り当て計画、衝突確認が必要です。クライアントの DNS を変えてもそのどれも得られず、次の端末に同じ失敗を残します。

リースが証明しないこと

アドレスを取得したことはローカルネットワークへの参加を証明しますが、端末のトンネルによる保護を証明するものではありません。クライアントがリースを持ったら、下流の経路を単独で評価してください。クライアントの通信は実際に端末を通っているか、名前解決は期待した場所で行われているか、外側のアドレスは意図した出口と一致するか。これらは第三段階の問いであり、参加に折り込むのではなく独自の試験に値します。

段階を順に追えば、失敗は動き回らなくなります。アドレス取得で止まるクライアントはローカルのテザリングの問題です。アドレスはあるがページが出ないクライアントは転送か名前の問題で、ページは出るが出口が違うクライアントはトンネルの適用範囲の問題です。これらを分けておくことが、デバッグの大部分です。