Windows の接続を共有していませんか？VPN の経路はその下で変わります

共有アダプターは PC をルーターに変え、転送されたトラフィックはホストのアプリとは別の経路を通ります。ホストではなくクライアントからテストしてください。

ノート PC が Wi-Fi を共有し、ホストは文句もなくトンネル経由で閲覧し、その共有上のタブレットは何にも届きません。共有を有効にした瞬間にホストは単なるクライアントではなくなり、いまはルーターであって、転送されたパケットは別のルール群に遭遇します。ホストで動くことは、その背後にある機器について何も語りません。下流のクライアントから確認を実行すれば、この区別は理論上の話ではなくなります。

ホストの成功は何も証明しない

接続の共有は、アドレスの割り当て、転送、変換、フィルタリングという四つの仕事を一つのマシンに与えます。ローカルで生成されたトラフィックを守る VPN クライアントは、転送されたトラフィックを自分の範囲外と見なすか、漏洩として意図的に遮断することがあります。どちらの挙動も不具合ではなく、どちらも共有を有効にした画面には書かれていません。どちらなのかは、下流のテストだけが教えてくれます。

多くのクライアントはホストのトラフィックだけを転送し、それ以外はしないので、トンネルがタブレットのためにルーティングしてくれると信じるのではなく、クライアントのドキュメントの共有の節を確認してください。目に見える症状は、接続し、アドレスを受け取り、最初の要求で失敗する機器です。転送を拒否するクライアントも、ホスト上ではまったく健全に見えます。

どのアダプターが共有され、どれがクライアントに応えるのか

別のアドレスと別のフィルターを持ち、間違った側での変更が多くの混乱する結果を説明するので、両方のアダプターを記録してください。共有ホストは通常、下流側で固定アドレスを取り、そこ小さな DHCP と DNS のサービスを動かします。Windows は転送を全体ではなくアダプターごとに保持するので、状態はインターフェースごとに読む必要があります。

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

共有アダプターで転送が無効と表示されるなら、トンネルが何をしようと下流では何も動きません。他の機器のためにルーティングすることをポリシーが許すマシンでのみ有効にしてください。

転送、変換、フィルタリング

転送されたパケットはトンネルに届き、遠端が受け入れる形に変換され、同じ変換を通って戻らなければなりません。この三つの段階のどれも壊れ得て、どの破綻も同じブラウザーのタイムアウトを生みます。パケットキャプチャー、経路の照会、遠端からのログは、共有ダイアログをもう一度見直すより価値があります。どの段階が失敗しているかが、誰の変更が必要かを教えてくれます。

遠端は、VPN サーバーが見たことのない範囲である共有サブネットの戻り経路も必要とするかもしれません。クライアントが変換する場所では、サーバーはトンネルのアドレスだけを見て、戻り経路は不要です。変換しない場所では、ゲートウェイを持つ誰かがその経路を意図的に追加する必要があり、それはクライアントの設定ではなく変更依頼です。

確認はホストではなくクライアントで行う

すべての確認を、動いているホストではなく、失敗しているクライアントで実行してください。出口アドレス、リゾルバーの応答、アプリケーションのテストは、一時間離して集めた結果が三つの組み合わせについて何も語らないため、同じセッションに保ってください。

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

出口アドレスをホスト自身のアドレスと比べ、二つが一致するか記録してください。違う答えなら転送経路がトンネルを迂回しており、これは迅速な修正ではなく担当者のいるポリシーの問題です。アプリケーションが失敗しているのに一致する答えなら、作業は名前解決か遠端のポリシーに移ります。IPv4 の結果で止まらず、共有がすべての IPv4 確認を通っても IPv6 が別の出口から出ることがあるため、AAAA レコードと詳細な接続テストで名前と出口の確認を繰り返してください。

管理されたマシンでは、他の機器へのアクセスを開くのが便宜の切り替えではなく管理上の決定である以上、共有がそもそも許可されているかを確認してください。対応する変更のあとは、再接続時と障害時にあらためて確認を繰り返してください。ホストがきれいに再接続しても、クライアントが決して対応しなかった転送経路は戻りません。

関連記事