Debian resolvconf のレコード順序：VPN のレコードを先頭にする

VPN のネームサーバーはいつも LAN のものより下に落ちてしまい、/etc/resolv.conf を編集しても数分で元に戻ります。このファイルは生成されるものなので、修正が定着することはありません。Debian の resolvconf では順序の入力が /etc/resolvconf/interface-order で、これは DNS アドレスではなくレコード名を並べ替えます。どちらのファイルに触る前に、どのリゾルバ構成が実際に担当しているかを確かめてください。

出力を所有しているのが resolvconf か確認する

まず、現在のファイルを何が書き、今後何が書き直すのかを問います。resolvconf パッケージは動的なリゾルバ設定のための枠組みだと名乗っており、systemd-resolved や NetworkManager 管理のリゾルバを動かすホストは、外から見れば同じでもまったく別のポリシーを使っていることがあります。

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

解決されたパスが resolvconf の実行時ディレクトリに入っていなければ、ここで止めてください。この手順書は別の構成のためのものです。

その確認をしてから初めて、resolvconf が現在保持しているレコードを一覧にする価値があります。

パターンを書く前にレコードを読む

interface-order が照合するのは供給元レコードの名前であり、アドレスでもカーネルのインターフェース名でもありません。登録されているものを一覧にして、パターンが実在する項目を指すようにしてください。

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

レコード名には通常、供給元を示す接尾辞が付くため、トンネルのレコードと DHCP のレコードが同じインターフェース接頭辞を共有していても、並び順は変わります。ディレクトリの一覧から正確な名前を写してください。インターフェース名から名前を推測してはいけません。何を登録するかはクライアント側の連携が決めるからです。勝手に作った名前は決して一致せず、レコードはエラーメッセージも出さずにすべてを受け取るパターンへ落ちます。

順序を最初に一致したパターンとして書く

このファイルはシェルの glob パターンの一覧で、一行に一つです。レコードは最初に一致したパターンの位置を取るため、具体的なパターンの上に広いパターンを置くと、その具体的な行には到達できなくなります。

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

トンネルの具体的なパターンを、すべてを受け取るパターンより上、かつ物理インターフェースのパターンより上に置きます。

ファイルに元からある他の行は残してください。ポリシー全体を例で置き換えると、無関係な供給元が静かに移動してしまいます。一行だけ変えて、再生成して比較してください。パターンには空白、スラッシュ、先頭のドットやチルダを含められず、空行とハッシュのコメントは無視されます。

再生成して結果を確認する

順序は更新スクリプトがファイルを再構築したときに効きます。生成された出力を編集するのではなく、対応している更新経路を実行し、そのうえでリゾルバが実際に受け取った内容を読んでください。

resolvconf -u
cat /etc/resolv.conf

照会は一つではなく二つ確認します。トンネル経由で解決されるべきプライベート名と、公開の対照名です。順序が正しく見えるのにプライベート名が失敗し続けるなら、問題はレコードの優先度ではなく名前空間の経路制御であり、並べ替えでは直りません。各応答は、成功したかどうかだけでなく、どのサーバーが返したかまで比べてください。誤ったリゾルバが答えたプライベート名も失敗であり、利用者には DNS 障害のように見えます。

古いレコードは格下げせずに廃止する

切断後に何度も現れる古い VPN レコードは、クライアント連携のライフサイクルの不具合です. 一覧の末尾へ移すのは症状を隠すだけで、死んだリゾルバを一覧に残します。

登録しているコンポーネントを通して廃止し、そのうえでレコードのディレクトリにもう載っていないことを確認してください。

供給元の名前、変更したパターン、実行した二つの照会を記録してください。次の人に必要なのは物語よりもその名前です。