VPN アプリを削除した後に Ubuntu がインターネットに接続できない

VPN クライアントをアンインストールし、再起動し、そのあとブラウザが何も読み込めないと気づくのは、Ubuntu ではよくある流れです。トンネルは消えても、通信をそこへ向けていたポリシーは消えておらず、Ubuntu ではそうした残骸はパッケージではなく NetworkManager に残るのが普通です。実行時に作られた接続プロファイルとダミーインターフェースはどのパッケージにも属さないため、パッケージを削除しても消えません。

トンネルは消えたが、ポリシーは残っている

キルスイッチは、トンネルがない状態ではネットワークを使えなくすることで機能します。その状態が有効なままクライアントを削除すると、それを解除するものが残りません。結果は壊れたネットワークアダプターとまったく同じに見え、たいていはルートを保持したプロファイルが原因です。

再インストールで接続が戻ることがあるのは、自分のポリシーを取り消す方法を知っているプロセスが作り直されるからです。スイッチが有効なまま削除されたクライアントは、誰も片付けられない状態を残しました。

パッケージが一度も所有していなかったオブジェクトを読む

変更する前に状態を読みます。デバイス、アクティブな接続、両方のルーティングテーブルを一覧し、接続済みと報告するダミーデバイスや、それを指すデフォルトルートを探します。IPv4 と IPv6 は別々に失敗するので、名前解決が壊れたアドレスへの ping が通る場合は、死んだルートとは別のオブジェクトを指しています。デフォルトルートを持つダミーデバイスだけで、停止全体を説明できます。

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

見つけた内容を書き留めてください。修正は特定のオブジェクトを一つ削除することであり、すべてをリセットすることではありません。それより広い対応は二度目の停止を招き、そこが修理と当て推量の違いです。

接続済みのデバイスがあるのにルーティングテーブルが空なら別の不具合で、残ったプロファイルではなく DHCP を指します。何かを編集する前にリースを読みます。

削除するのはプロファイルで、鍵ファイルではない

鍵ファイルを消すのではなく、NetworkManager 経由でプロファイルを削除します。ファイルを消すと、プロファイルは次の再起動までメモリ上で有効なままで、正しい修理が不安定に見えます。そのあとサービスを再起動し、デバイス一覧を読み直します。削除を本当にするのは再起動です。

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

ダミーリンクが残っている場合はそのリンクも削除し、そのうえでアドレスと名前を別々に試します。名前だけ失敗するなら DNS、アドレスが失敗するならルートかファイアウォールを指します。

繰り返される前に起動時のフックを確認する

残骸の中には起動のたびに自分を再インストールするものがあります。手書きのユニットや、ファイアウォール規則を追加する if-up スクリプトは、パッケージが消えたあともそれを続けるため、停止が再発し、以前の修理は偶然に見えます。もう一度再起動する前に、ユニットファイルとネットワークのフックを検索します。たいていはユニット名が手がかりです。

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

特定のファイルを削除するかマスクし、一度再起動して、トンネルのない状態が望むものか確認します。この最後の再起動がテストなのは、次の起動までしか持たない修正は修正ではないからです。そのあとはメモをマシンと一緒に保管します。nmcli のリファレンスは、上で使ったデバイスと接続のコマンドを扱っています。