Windows VPN でネットにつながらない？ 疑わしいのはアドレスプールだ

Windows はトンネルを接続済みと表示し、インターネットアクセスなしというラベルを付ける。人はそれを Windows の癖と読む。これはクライアントが受け取った内容についての陳述だ。使える既定ゲートウェイがない、動くリゾルバがない、またはトンネル内のアドレスへの戻り経路がない。サーバーが Windows の Incoming Connection である場合、ひとつの設定でこうした報告の大半が説明できる。ラベルは診断ではないが、調査を三か所に絞り込む。

変更する前にリースを読む

クライアントで ipconfig /all を実行し、項目の中から VPN アダプターを見つける。そこに列挙されるアドレス、既定ゲートウェイ、DNS サーバーが、必要な事実である。そしてそれらは、管理者が配布されたと思っている内容としばしば異なる。

三つのパターンが三つの障害に対応する。169.254.0.0/16 のアドレスは、クライアントが何も受け取らず、自分にリンクローカルアドレスを割り当てたことを意味する。もっともらしいアドレスにゲートウェイがないのは、クライアントに既定ルートを与えるオプションなしでプールが提供されたことを意味する。完全なリースなのに何にも届かない場合は、サーバー側の転送または変換を示す。

サーバーに触れる前に値を書き留める。次の手順で、サーバーが配布していると考える範囲と比較する。記憶はリースの代わりにはならない。

自動割り当てがゲートウェイを残さない理由

Incoming Connections の項目には、物理アダプターとは別に独自の IPv4 プロパティがある。そこの既定はアドレスの自動割り当てを提供し、アドレス、マスク、ゲートウェイ、DNS を供給するために接続の組み込みアロケーターに依存する。

スタンドアロンのワークステーションでは、マシン上の何かが一つを提供しない限り、そのアロケーターには引き出す範囲がない。そのためクライアントはリンクローカルアドレスになるか、アドレスはあってもゲートウェイがない状態になりうる。リンクが上がったので接続は確立したように見えるが、その背後の構成は不完全である。

だからこそ、指定した範囲に切り替えるとこれほど多くの報告が直る。動いていないかもしれないサービスにリースを考案してもらうのをやめ、自分でリースを述べ始めるのだ。

同じ混乱は、LAN ルーターの DHCP サーバーがトンネルのクライアントにサービスすることを期待するときに現れる。ブロードキャストによる探索はルーティングされたトンネルを越えないので、そのサーバーは要求を決して見ない。そうでないと想定することが、何も尋ねていないクライアントのせいでプールが責められる最も一般的な理由である。

サーバーがルーティングできる明示的な範囲を設定する

サーバーが到達できるサブネット内で、LAN ルーターが配る範囲の外、ネットワーク上の他のどのプールの外にある小さなブロックを選ぶ。サーバーが 172.20.10.0/24 にあり、ルーターが 172.20.10.1 を保持しているなら、そのサブネットの上端近くの短いブロック、たとえば 172.20.10.201 から 172.20.10.209 までが、トンネルのリースをルーターがすでに管理する配布から遠ざける。

Incoming Connection の IPv4 プロパティに入力し、クライアントを再接続し、他を変更する前にアダプターをもう一度読む。二度目の読み取りが、プールが原因だったのか、いくつかのうちの一つにすぎなかったのかを教えてくれる。

これらのコマンドは、結果の構成とクライアントが現在持つルートを出力する:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

リース内のゲートウェイはサーバーが保持するアドレスであるべきで、クライアントの既定ルートはそれを指すべきだ。リースが完全なのにルートが存在しないなら、サーバーはゲートウェイを押し出さずに割り当てており、プールの設定が依然として見るべき場所である。

アドレスはインターネットへの経路ではない

リースを受け取ることは、パケットをクライアントからサーバーへ移すだけだ。インターネットアクセスのためには、サーバーがそれらのパケットを転送し、自身のアップリンクへ向けて変換する必要があり、それは独自の障害モードを持つ別の構成である。

Internet Connection Sharing が近道だ。インターネット側のアダプターを共有ゲートウェイに変え、独自のアドレス指定を実行する。それはそのアダプターのアドレスを書き換え、既存の NAT ルールを、もう存在しない値を指したまま残すことがある。有効にする前に元の設定を記録する。

ルーティングの代替はアドレス指定を安定に保ち、転送と変換を明示的に構成するよう求める。どちらのアプローチも間違いではない。中途半端に混ぜると、リースはあるが出口のないトンネルになり、それはまさに最初の症状である。一つのモデルを選び、もう一方を加える前に仕上げる。

まず外側の経路を除外する

トンネルが形成されなければ、どんなプールも助けにならない。プロトコルが経路の運ぶものを決める。PPTP は TCP 1723 と GRE を要求し、GRE はポートではなく IP プロトコル 47 だ。L2TP/IPsec は UDP 1701 と 500、4500 を要求する。SSTP は TCP 443 を要求する。

ポートは転送するがプロトコルは転送しないルーターは、決して認証されない接続試行を生む。それは、トンネルが形成されてから何にも届かない場合とは別の障害であり、両方を一緒にデバッグすべきではない。

同じ LAN からとリモートネットワークから試す。LAN からの試行が成功し、リモート側が認証に到達しないなら、外側の経路が問題だ。両方が認証され、リモートのクライアントだけがインターネットに接続できないなら、プールと出口に戻る。