Windows に VPN を入れたのに Linux 起動時はネットワーク不通：確認すべきこと

Windows に VPN を入れ、Linux に再起動すると、有線接続が死んでいる。わかりやすい物語はひとりでに書かれるが、その物語は誤りだ。二つの起動は別々のカーネル、別々のドライバー、別々のルーティングテーブル、別々のリゾルバーを動かしている。Windows のネットワークフィルターは Linux の内部では実行されないため、不具合は Linux 側のスタックか、両方の起動が本当に共有するもの、たとえばハードウェア、ファームウェア、ルーターにある。

症状と誤った結論

観察の役に立つ部分はタイミングだ。不具合は変更のあとに現れた。役に立たない部分は Windows の VPN への因果の飛躍で、それは別の OS では動けない。この二つを切り分けることが仕事のすべてだ。ケーブルに触る前に時系列を書き出す。

両方の起動が共有しているのは、物理アダプター、ケーブル、スイッチのポート、そして上流にあるものだ。これらは本当の共通変数であり、Linux 側のスタックを調べたあとに確認する価値がある。

四つのコマンドで Linux の状態を記録する

何も変える前に読み取り専用で状態を記録する。インターフェースの有無は ip -br link、アドレスは ip -br address、IPv4 のルートは ip route、IPv6 が重要な場合は ip -6 route を使う。ip ツールのリファレンスはこれらのオブジェクトを区別しており、一覧にインターフェースが現れても、有効なアドレスや使えるルートがある証拠にはならない。

出力はファイルに保存し、あとで正常な起動と比べられるようにする。再現できないスナップショットは、状態の記憶にすぎない。

リンクか、アドレスか、ルートか、名前か？

四つの異なる不具合はブラウザーからは同じに見える。デバイスがまったく無い場合、キャリア無しで存在する場合、リンクはあるが期待したアドレスが無い場合、アドレスはあるが宛先へのルートが無い場合がある。生のアドレスは通るのに名前解決が失敗するのは五番目のケースで、これはドライバーではなくリゾルバーの問題だ。

各ケースは別の作業を指す。デバイスが無ければドライバーかファームウェア、キャリアが無ければ配線かスイッチ、アドレスが無ければ DHCP か静的設定、経路が無ければルーティングかポリシーだ。リゾルバーの問題は systemd-resolved、NetworkManager、ローカルの DNS 設定を指す。

Linux 側に独自の VPN や常設のファイアウォール設定が無いか確認する。ローカルのトンネルや nftables のルール群は Linux 側の原因であり、動いていない Windows のプログラムよりはるかに説明力が高い。

次に起動の切り替えを比べる

Windows Fast Startup は、完全な起動の代わりにカーネルのセッション状態を保持するハイブリッドシャットダウンだ。Microsoft の電源状態のドキュメントは、これを再起動とも完全なシャットダウンとも区別している。だから同じハードウェアでも二つの遷移で挙動が変わりうる。

不具合が一方の OS から他方への移動に依存しているなら、作業を保存したうえで、文書化された再起動または完全なシャットダウンを通常の経路と比べる。遷移に従う結果は、ドライバーやデバイス、ファームウェアの状態を調べる根拠になるが、それだけで Fast Startup が特定のアダプター不具合を起こしたと証明するわけではない。

最後にアダプターを使った OS、遷移の種類、Linux のリンク状態、最初に失敗した操作を記録する。コールドスタートとウォーム遷移の再現できる差は、どちらのスタックが壊れたかも分からないまま両方のインストールから VPN ソフトを消すより、はるかに価値がある。

変えてはいけないもの

最初の一手として両方のネットワークスタックをリセットしない。それは比較を壊し、実際の原因を特定しないままなので何も直らないことが多い。Linux を直すために Windows の VPN を再インストールせず、起動の遷移が不具合と相関したという理由でファームウェア設定を闇雲に変えない。

ip ツールのリファレンスは、上で使ったリンク、アドレス、ルートのオブジェクトを説明している。まず Linux 側を読み、スナップショットを残し、そのうえで共有ハードウェア層を調べる価値があるかを決める。