VPN 接続中にローカルネットワークへ届かない？四つの確認

トンネルが張られ、イントラネットは見えるのに、プリンターが応答しなくなる。LAN 側では何も壊れておらず、クライアントが、ローカルと見なさなくなったアドレスに使う経路を変えただけだ。同じ症状にはよくある原因が四つあり、VPN の設定を変えて直るのはそのうち一つだけなので、以下の四つの確認を順番に実行し、具体的な不一致が出たところで止めてほしい。

まず、クライアントが入れた経路表を見る

VPN 接続中にクライアントの経路表を開く。Linux では ip route、Windows では route print または Get-NetRoute、macOS では netstat -rn を使う。トンネル経由のデフォルト経路と、物理側のデフォルト経路がどうなったかを見るのだ。

フルトンネルのクライアントは、0.0.0.0/0 を置き換える代わりに、0.0.0.0/1 と 128.0.0.0/1 という二本の半デフォルト経路を追加することが多い。元のデフォルト経路は見えたままなのにすべての照合で負けるので、経路表は無傷に見えるのにサブネット外の通信だけが移ってしまう。VPN クライアントにスプリットトンネルの設定があり、ポリシーが許すなら、それが最もきれいな直し方だ。

トンネルをデフォルトのまま残す必要があるなら、代わりにローカルサブネットを固定する。Linux では経路に物理インターフェースとゲートウェイを指定し、Windows では -p を付けて永続化し、インターフェース番号は推測せず route print から読む:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

固定した経路は、そこに書いたアドレスが同じ間だけ効き、接続のたびに Wi-Fi アダプターの番号が変わるノート PC ではまた同じ規則が破れる。だから直らなかったと判断する前に、インターフェースのアドレスを確認する。

次に、そのアドレスがもともとローカルだったかを確かめる

宛先が接続中のサブネット内にあるなら、トンネルのデフォルト経路は決して適用されないため、VPN が原因ではない。192.168.1.0/24 のクライアントで 192.168.1.40 のプリンターに届かないなら、VPN ではなく機器、スイッチ、クライアントのファイアウォールを見る。

人を惑わすのは、ローカルサーバーにパブリックアドレスを付けた場合だ。LAN の内側からルーターの WAN アドレスに出て戻ってくるにはヘアピン NAT が必要で、多くのルーターはポート転送に対してそれを実装していない。プライベートアドレスとパブリックアドレスを並べて試す。プライベートは通り、パブリックが通らないなら、VPN はもともとあった NAT の制限を露呈させただけだ。

ホスト名が入るとさらに悪くなる。ローカルの名前が今パブリックアドレスに解決されるなら、クライアントは戻れない経路を試し続ける。試験にはプライベートアドレスを使い、ポート転送を増やすのではなく名前のほうを直す。

三つ目に、今どのリゾルバーが名前を答えているかを見る

社内リゾルバーはイントラネットを知っていても、NAS のホスト名、プリンターの Bonjour 名、ルーターのローカル別名はほとんど知らない。VPN が自分の DNS サーバーを押し込むと、アドレスにはまだ届くのに、それらの名前が解決されなくなる。名前を直接引いて、機器が持っていると分かっているアドレスと答えを比べる。

Linux では resolvectl query nas.local がどのリゾルバーが答えたかを示す。Windows では nslookup nas.local がサーバー名を示し、ipconfig /all がリゾルバーの順序を示す。ローカルのサフィックスがいま社内リゾルバーの担当になっているなら、そのサフィックスをローカルのリゾルバーへ戻すか、機器には IP アドレスを使う。

検出は別の層だ。mDNS とブロードキャストはルーティングされたトンネルを越えないので、アドレスでは届いても名前は見えないままになる。リフレクターかローカル DNS の登録で解決するが、経路では解決しない。

四つ目に、相手のマシンも VPN につながっていないかを確かめる

つなぎたいマシンも VPN クライアントを動かしていると、こちらのセッションは届いても、その返事が別のトンネルから出ていくことがある。すると接続は確立したあとで止まるか、RDP や SSH が手元にエラーを出さないままタイムアウトする。自分のクライアントを責める前に、相手ホストの経路表とデフォルト経路を見る。

サービスが待ち受けているアドレスも確認する。トンネルのアドレスだけに束縛されたリスナーは、VPN からの接続は受け入れ、LAN からの接続は拒否し、経路が完璧でもそうなる。これはネットワーク経路ではなくサービスの設定で、VPN のアドレスに閉じた管理画面によくある。

トンネルに依存しない管理経路——送信元ネットワークを指定した静的経路、LAN につないだ別のインターフェース、トンネルを完全に迂回するコンソール——を用意しておく。セッションが切れてからその経路を設計するのは、次の接続の前に足しておくよりずっと難しい。

失敗した確認に対応する直し方を当てる

経路表に半デフォルトの乗っ取りが見えたなら、ポリシーが許せばスプリットトンネルを、許さなければ固定のローカル経路を選ぶ。アドレスがパブリックだったなら、試験と名前をプライベートアドレスに切り替える。リゾルバーが持ち主を変えたなら、ローカルのサフィックスを限定するかアドレスを使う。相手ホストがトンネル側なら、その戻り経路かリスナーの束縛を直す。

一つだけ変えて、同じ確認を繰り返す。間違ったサブネットに足した経路も、綴りを間違えたリゾルバーのサフィックスも、番号が変わるインターフェースに固定した経路も、元の故障と同じに見える。繰り返して確かめることで、直ったのか偶然なのかが分かれる。

VPN 接続中に通っていた経路、アドレス、リゾルバーを書き留めておく。次の再接続でその少なくとも一つは変わるので、メモがあれば次の障害は新たな調査ではなく短い比較で済む。