openfortivpnがDNSを上書きし続ける？本当の所有者を見つける

接続が立ち上がった瞬間から、クライアントが認証し、pppdが折衝し、そのあと何かがDNS設定をオペレーティングシステムに書き込むまでの流れをたどってください。VPNがリゾルバを変えたという事実だけでは、そのどの段階がやったのかはまだ分かりません。そのうち二つが可能で、文書化されたpppd統合を使うクライアントでは、両者はひとつの主体に見えるほど近接して動きます。書き込み側を名指しするのが第一歩、その代替を選ぶのが第二歩であり、これは独自の故障モードを持つ別の判断です。

以下の順序は、接続が何を変えたのか、どのスイッチがどの書き込み側を抑えるのか、誰が引き継ぐべきか、そして結果が再接続を生き延びることをどう確認するかという形で、クライアントを外側へたどります。各段階は異なる痕跡を残し、その痕跡が引き継ぎが実際に起きたかどうかを教えてくれます。

接続が実際に何を変えたかから始める

いつものコマンドで一度接続し、前後の解決を比較します。systemd-resolvedを動かすLinuxホストでは、resolvectl statusがリンクごとのDNSサーバーと検索ドメインを出力し、独自のサーバーを持つ新しいtunまたはpppリンクはクライアント側更新の指紋です。macOSでは、scutil --dnsがアプリケーションの参照する順序でリゾルバ設定を表示します。

それを、変化するはずだと思っていたファイルと比べます。リンクごとの表示にある接続スコープの項目と、書き換えられた/etc/resolv.confは別の結果であり、後者はまったく別の何かが管理するシンボリックリンクかもしれません。リゾルバのアドレス、検索ドメイン、インターフェース名を同じ瞬間に記録し、どれかひとつでも変われば別の書き込み側を指すと見てください。その基準線がなければ、後の修正はすべて三つの構成要素のどれが動いたかという推測になります。

二つのスイッチと、それぞれが抑える書き込み側

openfortivpnは、制御できる両方の書き込み側を切るオプション断片を文書化しており、各スイッチにはマニュアルが同じ設定として扱う完全に書き下した等価形があります。

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dnsはクライアントがゲートウェイから学んだDNSサーバーを適用するのを止め、--pppd-no-peerdnsはpppdがピアのDNSをシステムへ押し込むのを止めます。 upstreamのマニュアル は、PPP経由のDNS更新がクライアント自身のDNS更新と競合しうると警告しており、だからこそどちらか一方を十分と見なすのではなく、両方のスイッチを断片に入れるべきなのです。

どちらのスイッチも代替リゾルバを名指しせず、ネットワークマネージャー、DHCPクライアント、あるいは別のVPN統合が後から解決を書き込むのを止めもしません。二つの書き込み側を抑えることは、領域を所有するのではなく開いたままにします。第三の構成要素がすでにDNSを管理しているなら断片は観察できるものを何も変えず、何も管理していないなら私的な名前解決の唯一の源をいま外したところです。それが有効な配置になるのは、代替の所有者を先に選び、単独で試験した場合だけです。

何かを無効にする前に所有者を選ぶ

まず業務名の問い合わせに誰が答えるかを決めますが、その選択が以後のすべてを制約します。既存のリゾルバを保つということは、私的ゾーンがクライアントのいる場所からすでに到達可能でなければならないということであり、社内の私的リゾルバにはトンネルが立ち上がっても生き残る経路が必要です。すべての問い合わせを単一の内部サービスへ送るのはより鋭い故障モードを持つ第三の政策であり、そのサービスに到達できないとき公開名は私的名とともに失敗します。

経路の所有権は意図的に分けたままにする。経路オプションはDNSを変えたから必要というわけではなく、代替を入れずに経路の導入を切ると、いま選んだリゾルバに到達できなくなることがあります。ルーティングテーブルは、たまたま試したアプリケーションのサブネットだけでなく、リゾルバのアドレスについて具体的に確認してください。

解決はファイル単位ではなくリンク単位で確認する

スコープ付きまたはドメイン単位の解決を持つホストでアプリケーションが実際に何を使うかの一覧を、単一の/etc/resolv.confが示すわけではないので、プラットフォームが公開する形でリゾルバの状態を読んでください。

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

接続が上がったら私的名をひとつ、公開名をひとつ問い合わせ、どちらのリンクが答えたかを記録します。VPNリンクがドメイン単位の検索リストを持つ場合、私的名は正しく解決できても公開名はローカルリゾルバへ行くことがあり、その分割は故障ではなく設計が働いている証拠です。私的な問い合わせが失敗したらもう一度DNSに触る前にリゾルバへの経路を調べ、成功するのにアプリケーションが失敗するなら、そのアプリケーションは独自のキャッシュ済みまたは別設定のリゾルバを読んでいるのかもしれません。

再接続して切断状態を確認する

接続を落として両方の問い合わせを繰り返します。選んだ所有者が入れたものは、黙らせたクライアントが置き去りにするのではなく、その所有者が外すか戻すべきです。トンネルより長生きする古いリンク単位の項目は、もう到達できないアドレスへ私的な問い合わせを送り続けます。

そのあと再接続して、リゾルバのアドレス、検索ドメイン、インターフェースという同じ三つの値をもう一度読みます。

それらが書き留めた方針と一致するなら、引き継ぎは完了しており、VPNクライアントはもう書き込み側のひとつではありません。リンクが上がって数秒後に値が戻るなら、何か別のものがまだ設定を適用しており、次の手順は別のフラグを足すことではなくその構成要素を特定することです。望む最終状態は、所有者がひとつ、文書化された方針がひとつ、そしてトンネルが存在する前とまったく同じように解決する切断されたホストという平穏なものです。