OpenVPN が DNS サーバーを送ったのに Linux が無視する
送られた DNS サーバーはログにあり、トンネルは上がっているのに、社内の名前は解決に失敗し続けます。リゾルバのリンクを確認し、接続の所有者を一つに決めてください。
送られた DNS サーバーはログにあり、トンネルは上がっているのに、社内の名前は解決に失敗し続けます。送信そのものは壊れておらず、設定は届いたところで止まっています。送られた DNS オプションはクライアントへのメッセージであり、OS のリゾルバへの指示ではありません。両者の受け渡しこそが、こうした事例のほとんどが終わる場所であり、起きなかった受け渡しは五つの確認を順に行えば見つかります。
確認一: 接続はどう始まるか
接続の所有者が、リゾルバ設定を適用できる人を決めます。シェルからの直接の openvpn コマンドは自分のプロセス以外を所有しませんが、systemd ユニット、NetworkManager、ベンダーのクライアントにはそれぞれ DNS を公開する方法があります。どれかを前提にする前に、プロセス一覧とユニット名を読んでください。
コマンドラインのプロセスは自動的に NetworkManager の接続ではなく、NetworkManager の接続も自動的に resolv.conf を書いたものではありません。この二つの思い込みが、この調査で失われる時間の大半を説明します。実際に見えているインターフェースのために、どのコンポーネントが DNS を公開するのかを問い直してください。
続ける前に所有者を書き留めてください。以降の確認はすべてこれに依存します。
確認二: リゾルバのリンクが実際に持っているもの
systemd-resolved のホストでは、resolvectl status が各リンクを DNS サーバーとドメインとともに一覧表示します。トンネルのリンクを見つけて項目を読み、番号は作成順に従うため、インターフェース名が tun0 だと決めつけないでください。送られたアドレスがリンクに無ければ、失敗したのは問い合わせではなく受け渡しです。
アドレスがある場合、次の問いはそのリンクがどのドメインを主張するかです。ドメイン一覧の無いリンクは、直接問い合わせられた名前だけに答え、それは split-DNS の配備が求めるものではほとんどありません。アドレスだけでは必要ですが十分ではありません。
結論を出す前に、リゾルバの出力にあるリンク名と VPN ログのインターフェース名を比べてください。そこでの不一致は通常、ログ行が別のプロセスから来たことを意味します。
確認三: 名前空間がそのリンクを選ぶか
リゾルバが正しいサーバーを持っていても、照会されないことがあります。リンクごとのドメインが、どの問い合わせをどのリンクへ送るかを決め、ルーティングドメインが無ければプライベートな名前空間は既定のリンクの言うところへ戻ります。だからこそ、resolvectl query が社内名で成功してもアプリケーションは失敗し続けます。アプリケーションがまったく別のリゾルバ経路を使っている可能性があります。
サーバーアドレスだけでなく、ドメインの割り当てを確認してください。~corp.example と書かれたドメインはルーティングドメインで、チルダが名前の照合方法を変えます。
アプリケーションが独自のリゾルバを持つなら、システムのツールではなく、それ自身が使う仕組みで試してください。システムのリゾルバを迂回する照会ツールは、リンクの状態にかかわらず成功します。
確認四: 所有者は一つ、二つではない
NetworkManager がすでに VPN とリゾルバの状態を管理しているなら、無関係なフックスクリプトを足すと書き手が競合します。パッケージが提供する systemd-resolved 用のフックはサポートされた統合で、script-security 2、up のパス、up-restart、down のパス、down-pre という特定のライフサイクルを前提とします。これらのオプションにより、登録と削除は最初の接続時だけでなく正しい時点で行われます。
ガイドからコピーした例示的なパスではなく、パッケージがインストールしたパスを使ってください。フックは特権が下がった後に動くため、権限も重要です。
ディストリビューションのリゾルバスクリプトを編集して出力先を変えるのは、一台のホストの回避策を記録するだけです。一般的な修理ではありません。
確認五: 再接続しても同じ結果になるか
再接続してリンクを読み直してください。一度だけ現れて次の切り替えで消える登録は、このチェックリスト全体が存在する理由の故障です。サスペンド後、強制再接続後、リゾルバサービスの再起動後に試してください。切り替えのたびに別の順序の前提が試されます。
再接続で五つの確認がすべて通って初めて、送られた設定が使われていると言えます。それより前は、幸運な瞬間のスナップショットにすぎません。