VPN 経由の 169.254：このアドレスは決してルーティングできなかった

経路を追加し、トンネルは上がる。それでも対向への ping は「network unreachable」ではなく完全なロスで落ちる。この違いは重要で、視線をルーティングテーブルからアドレスそのものへ移させる。169.254 の宛先はリンクローカルであり、その範囲は設計上最初のホップで終わる。設定ミスではない。

続く判断は狭いが、明示的に取る価値がある。サーバ側のサブネットを直すか、レイヤー2 のセグメントを広げてアドレスを再びローカルな意味に戻すかだ。より広い経路を足すことを含め、それ以外は同じ障害をより多くの宛先に広げるだけである。

このアドレスは経路がないのではなく、経路を持てない

IPv4 のリンクローカルアドレスは、より良い応答がないときに自ら名乗る。Windows の自動プライベートアドレス指定はここに由来する。この範囲はどのリンクでも同時に使われており、だからこそ機能する。同一セグメントの二台は調整なしに会話できる。

同じ性質のため、ルーターはこれらのパケットをネットワーク間で転送してはならない。リンクローカル宛てのパケットを別のインターフェースから出すと曖昧さが生じる。送信者の「ローカル」と受信者の「ローカル」は別の場所だからだ。ここでの転送は管理者が有効化できる選択肢ではなく、アドレスのクラスがそれを排除している。

したがって 169.254.1.10 をトンネル経由で到達可能として登録するゲートウェイは、アドレス形式が禁じていることをカーネルに求めている。パケットは遠隔ホストに届くはるか前に破棄され、経路の細かさはその結果を変えない。

トンネルが範囲の問題を可視化する理由

TUN インターフェースは二者間で IP パケットを運び、背後に共有セグメントを持たない。ブロードキャストも、対向のための ARP も、リンクローカル宛先をリンク層アドレスに解決する近隣探索もない。

何を探すべきか分かれば症状は整って一致する。経路はテーブルにあり、ping は到達不能ではなく完全なロスを報告し、近隣テーブルは不完全な項目を示す。トンネルでのキャプチャはパケットが出ていくのを見せるため、人々はアドレスのクラスではなく遠い側を見に行く。

Windows には同じ根を持つ、無関係に見える第二の症状がある。リンクローカルアドレスだけが残ったアダプターには使えるゲートウェイがなく、ネットワーク識別が接続を分類できず、ファイアウォールのプロファイルがパブリックになる。原因はトンネルではなくアドレスである。

三つの質問で決める

サブネットを直すかリンクをブリッジするかの選択は三つの条件にかかっており、どれか一つで設定ファイルを開く前に決まる。

ほとんどの事例は最初の質問で止まる。リンクローカルアドレスを示すホストは、DHCP が応答しなかった、ケーブルや VLAN が違う、誰かが手で入力した、のいずれかを意味する。それを直す方がトンネル作業より安く、この一台だけでなく将来のすべてのクライアントから問題を消す。

何かを仮定する前にサーバ側を確認する。ホストで ip addr show と ip route を、クライアントで arp -n または route print -4 を実行し、プレフィックスが実在するのか古い項目がそう主張しているだけなのかを見る。

ブリッジが正解であるときのコスト

物理アダプターを TAP アダプターとブリッジすると、遠隔クライアントはローカルのブロードキャストドメインの一部になる。するとブロードキャストと近隣探索が機能し、リンクローカルアドレスが再び意味を持つ。

コストは現実であり、誰かが同意する前に示すべきだ。ブロードキャストトラフィックがトンネルを越え、クライアントは必要なサービスだけでなくあらゆる目的でローカルセグメントに露出し、サーバーはパケットをルーティングする代わりにフレームを転送しなければならない。実験用ベンチやルーティング可能な設定経路を持たない機器には妥当な交換であり、遠隔アクセスの既定値としては悪い。

ブリッジするときは両半分が必要だ。サーバー側のブリッジと、クライアントプロファイルにどの宛先が向こう側にあるかを伝える経路である。ブリッジだけではクライアントは推測に頼り、経路だけではアドレスのクラスを直せない。