resolvconf データベースから古い VPN レコードを削除する

トンネルが閉じた翌日になっても、内部名はまだ VPN サーバーに解決され、リゾルバファイルはそのエントリを伴って何度も戻ってきます。Debian の resolvconf が状態を管理している環境では、そのファイルは供給元のレコードから組み立てられ、そのうちの一つが残留物です。レコードの削除は一分で終わりますが、削除して安全だと証明することが本当の作業です。これらのゲートは順番に実行され、失敗したゲートは手順を終わらせ、次の手順へ送ることはありません。

resolvconf が状態を管理していることを確認する

最初に所有者を特定するのは、systemd-resolved 環境では同じ症状でも必要なコマンドと修理方法が異なるからです。resolvconf パッケージは /run/resolvconf の下にデータベースを置き、/etc/resolv.conf をそのデータベースから組み立てたファイルに向けます。二つの読み取りで決着します：シンボリックリンクの指し先と、パッケージがインストールされ有効かどうかです。/run/systemd/resolve の下が指し先なら別の設計であり、以下の内容は当てはまりません。

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

リンクが別の場所を指しているか、パッケージが無い場合は、ここで止めてください。名前を借りた互換ラッパーが別のリゾルバ管理ソフトから提供されていても、このデータベースの所有者ではありません。

データベースが持つのは入力であり、答えではない

データベースは入力を持ち、ファイルは出力なので、入力を一覧することが、消したいエントリをどのプログラムが設置したかを見る唯一の方法です。レコードは短く、そのキーは後で必要になる取っ手です。VPN インターフェースに見える名前が別のクライアントのものかもしれないので、どれが古いかを決める前に読んでください。プライベートアドレスと内部検索ドメインは共有の診断情報から外してください（キーだけでレコードを特定できるのが普通です）。

sudo resolvconf --list
sudo resolvconf -i

最初のコマンドは供給されたレコードを処理せずに出力し、二つ目は現在 DNS 設定を提供しているインターフェースを一覧します。キーは慣例としてインターフェース名と供給元のプログラムから作られます。resolvconf のマニュアルが、それらのキーが指すデータベースを説明しています。

キーは作り直さず、出力からコピーしてください。古いスクリプトがその名前を使っていたからといって、エントリが tun0 と呼ばれるわけではありません。

レコードに所有者がいないことを証明する

生きている接続が設置していないレコードは、削除しても安全です。キーを作成した接続と関連づけ、その接続が消えたことを確認します。この対応づけがゲートそのものであり、削除コマンドへ向かう途中で最も飛ばされやすい手順です。証拠が曖昧なら、レコードは生きているものとして扱い、止めてください。

プロセス名は弱い証拠です。OpenConnect は vpnc-script を呼ぶので、vpnc プロセスの確認はどのレコードが現在のものかを何も語りません。新しい接続が古い接続の残したインターフェース名を再利用することもあり、その場合キーは実際より古く見えます。レコード内のサーバーアドレスを、まだ稼働中のトンネルのアドレスと比べ、一致したら止めてください。

所有するマネージャーを通した通常の切断が最初の手段です。それはその接続が設置したものを取り下げ、他の供給元には手を付けません。

削除と書き換えを確認する

レコードが古いと確認できたら、正確なキーで削除し、それから結果を仮定せずに読みます。このコマンドはホスト上のすべてのアプリケーションのリゾルバ状態を変えるので、自分が管理するウィンドウで実行してください。キーはシェルが展開してしまう文字を含むので、引用符で囲んでください。ブロック内のプレースホルダーは、一覧からコピーしたキーを表し、リテラル文字列を表すものではありません。

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

更新が有効なら削除は更新スクリプトを実行し、更新が無効なら更新を延期するので、レコードの削除とファイルの書き換えは別々の出来事になります。ファイルを見る前に一覧を読み直し、キーが消えたことを確認してください。次に、残った供給元を通してまだ解決されるはずの名前と、公開名を一つずつ問い合わせ、どちらも変更前に見たものと比べます。プライベートな名前が完全に解決されなくなったなら、そのレコードがまだそれを運んでいたのです。

resolvconf -u はそれらの更新スクリプトを実行するだけです。古いレコードを特定したり削除したりは決してせず、古い入力から作り直せば同じ不要なファイルが再現されます。

殺された切断フックはレコードを残す

一度きりの掃除は今日の状態を戻しますが、次に中断されたシャットダウンがレコードを戻します。解体の経路をたどってください：クライアントの切断フック、そのフックが呼ぶヘルパー、そしてどちらかが殺されたときに何が起きるかです。フックがまったく実行されなかったのですから、中断されたシャットダウンが通常の原因です。フックの終了ステータスを一度記録すれば、静かに失敗しているかどうかが分かります。

設定と掃除は一人の所有者の下に置いてください。インターフェース名を推測する二つ目のスクリプトは、いずれ別の接続のレコードを削除しますが、それは最初の古いエントリより悪い結果です。どの接続が設置したかを知っているのですから、所有者はレコードがいつ古いかも決めるべきです。

そしてライフサイクルを試してください：接続し、切断し、もう一度レコードを一覧します。エントリがひとりでに消えることが、修理が保たれている唯一の証拠です。