Windows VPN が 255.255.255.255 を表示する：マスクは間違いか

ポイントツーポイントのトンネルではホストマスクが正常です。インターフェイスの種類を確認し、失敗するホストの経路を読み、DNS とサービス到達を切り分けます。

トンネルは接続できているのに、アダプターの詳細を開くとマスクが 255.255.255.255 になっている。オフィス LAN の 255.255.255.0 と見比べて故障だと判断されがちだが、たいていはそこで話がこじれる。ポイントツーポイントのリンクでは、ホストマスクはローカル端点の正しい記述であり、リモートのネットワークは直結サブネットではなく経路として届く。以下の手順は二つの問いを切り分け、表示値のためだけに正常な DHCP スコープを作り直さないようにするためのものだ。

ポイントツーポイントリンクはイーサネットセグメントではない

イーサネットインターフェイスにサブネットマスクが必要なのは、その範囲の各アドレスが同じケーブル上で到達可能になり得るからだ。PPP 形式のトンネルの向こう側には相手がちょうど一つしかない。ブロードキャストドメインも ARP もなく、ローカルアドレスが範囲を表す理由もない。

このモデルのアドレス交渉は RFC 1332 で定義されており、両端が自分のアドレスについてどう合意するかが書かれている。ただし、オフィス LAN を直接接続されたネットワークとしてクライアントに渡すわけではない。クライアントはリンク経由で経路を入れることでオフィスの場所を学び、実際に到達性を決めるのはこの経路である。

だからといって、目にするマスクがすべて正しいわけではない。設定を誤ったクライアントも奇妙なアドレスを作り得る。論点はもっと狭い。この種のアダプターのホストマスクは想定どおりであり、それ自体は故障の証拠にならない。

ステップ 1：インターフェイスの種類を確認する

何を言っているかを判断する前に、アダプターが何であるかを見る。説明文字列がドライバーを示し、割り当てアドレスのプレフィックス長がクライアントの交渉結果を裏づける：

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

議論を終わらせるのは三番目のコマンドだ。最大転送単位が小さいのはカプセル化されたリンクの特徴で、イーサネットに近い値は 別の仮想アダプターモデルを示す。説明に PPP や RAS のドライバーがあり、プレフィックスが 32 なら、まさに上で説明した設計であり、マスクの心配は不要になる。

ObservationWhat it meansReasonable next step
/32 on a PPP or RAS adapterPoint-to-point endpoint addressingLook at routes, not the mask
/32 on an Ethernet-like adapterClient chose host addressing deliberatelyConfirm against the server's push policy
Mask differs from the office LANUsually irrelevant to reachabilityTest the destination instead

ステップ 2：失敗する宛先の経路を読む

到達性は宛先ごとに決まる。接続済みのインターフェイスが一つあるだけでは何も分からない。利用者が実際に到達したいアドレスを経路表に直接問い合わせる：

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute が直接の答えだ。その宛先に使うインターフェイスと送信元アドレスを示す。トンネルが返れば、そのホストへの通信はトンネルを通っており、マスクは最初から問題ではなかった。

物理アダプターが返る場合は、二つの候補経路とそのメトリックを比べる。より具体的なローカル経路、別クライアントの残骸、物理経路の低いメトリックはいずれも広いトンネル経路に勝つ。見える症状は、他は全部動くのに一つのリソースだけ届かないというものだ。長いプレフィックスが常に優先されるため、勝っているのは数か月前に誰かが追加して忘れたホスト経路であることが多い。

ついでに両方向を確認する。サーバー側への経路は必要条件であって十分条件ではない。戻りもトンネルを通る必要があるからだ。内部ホストの一方が通り、他方が通らないとき、違いはたいていこの表にあって、アダプターの設定にはない。

ステップ 3：名前解決とサービス到達を切り分ける

共有を開けないアプリは、まったく異なる二つの段階のどちらかで失敗し得る。まず名前を解決し、次にアドレスへ到達する。前者が失敗して後者が成功するなら、トンネルは正常でリゾルバーが問題だ：

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

アドレスのテストが成功し名前のテストが失敗すれば、問題は名前解決に絞られる。二番目のコマンドで、トンネルのインターフェイスがサーバーを受け取っているかどうかも分かる。多くのクライアントはトンネル設定の一部として DNS を配布する。その配布された設定を無視するプロファイルでは、プライベートゾーンが見えないリゾルバーが残ってしまう。

通るアドレスを恒久的な修正と見なさないこと。アドレスで接続すると名前解決を迂回し、本来アプリが行うサーバー身元確認を弱めかねない。これは一時的な回避策の姿をしたセキュリティ後退だ。切り分けに使い、その後に名前解決を直す。

ロールバック：表示値のために DHCP を作り直さない

アドレスサービスを変え始めているなら、いったん止めて、変えたものが土台を支えていないか確認する。スコープの作り直し、リースの再発行、プールの移動は他のクライアントが依存する状態を変える。ポイントツーポイントのアダプターのホストマスクは、そのどれの理由にもならない。

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

対象を絞った変更のたびにこの三つを実行し、直前の結果と比べる。得たい成果は、リソースへの記録可能な経路であって、マスクがオフィス LAN に似たアダプターではない。

最後に、そのマスクが実際に何を意味するのかを書き残す。次に同じ画面を開く人は、同じ誤った結論に達するからだ。プロファイルのメモに一行、「トンネルはポイントツーポイントで、リモートサブネットは経路として届く」と書いておけば、次回は調査そのものが不要になる。

関連記事