OpenVPN が DNS をプッシュした後にローカルの Samba 共有が消えた

Samba は OpenVPN が接続した瞬間にローカル共有を失いますが、トンネルが原因であることはほとんどありません。マウントは正常で、NAS も稼働しており、トンネルが導入したリゾルバーが見たことのない名前について答えています。Samba は検索順序の早い段階でそのリゾルバーに問い合わせ、その回答を信じ、何も待ち受けていないアドレスに接続します。共有を直すということは、マウントではなく回答を直すことです。

五つの確認を、各段階で最も多くの可能性を排除できる順に行います。

短い名前には誰が答えるのか

ファイルマネージャーではなく OS に尋ねます。resolvectl status は各リンクに関連付けられた DNS サーバーを表示し、どのリンクが既定ルートかを示し、短い名前の問い合わせでは応答したサーバーが報告されます。NAS の名前で一度、オフィスのドメインに存在すると分かっている名前でもう一度実行します。二つの回答が別のサーバーから来ていれば、分割を突き止めたことになります。

回答が否定応答だったのかアドレスだったのかを確認します。否定応答なら Samba は別の仕組みに進むべきで、障害は別の場所にあります。アドレスなら Samba は実在する場所に接続して何も得られなかったことになります。

Samba が誤った回答を信じる理由

Samba は name resolve order で設定された固定の順序で名前を解決します。ほとんどのディストリビューションでは既定値に host が含まれ、これは DNS を意味し、NetBIOS ブロードキャストのような LAN 専用の仕組みより先に実行されます。そのためリゾルバーをプッシュするトンネルは、建物の外に出るはずのなかった単一ラベルの名前も含め、すべての共有名に対して最初の拒否権を得ます。

通常、未知の名前は否定応答を返し、次の仕組みに順番が回ります。一部のリゾルバー、特に消費者向け ISP や公開リゾルバーは、未知の名前に検索ページや広告用アドレスで答えます。その応答はリゾルバーライブラリには成功に見えるため、Samba は検索をやめ、あなたのネットワークとは無関係なアドレスに発信します。

結果は、エラーダイアログも出ずに消える共有です。この順序のどこにも VPN ルーティングの失敗はないので、NAS への ping は通るのに閲覧はできない、という状態になります。

範囲の異なる二つの修復

狭い修復はプッシュされたリゾルバーを残したまま、Samba がそれを問い合わせてよい内容を変えます。デーモンが実際に読む Samba 設定に二行を追加し、サービスを再起動します：

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

その一覧に host がなければ DNS は共有検索の経路から外れ、単一ラベルの名前はローカルセグメントに残ります。オフィスの名前はほかのすべてのプログラムでは今までどおり解決されます。変わるのは Samba だけだからです。代償は、Samba が DNS をまったく使えなくなることなので、完全修飾されたオフィス名で指定された共有は問題になります。

広い修復は原因を取り除きます。自分が管理していない名前に答えるリゾルバーをプッシュするのをやめるか、オフィスのサフィックスだけがオフィスのリゾルバーに届くように分割 DNS ポリシーをプッシュします。管理されたネットワークでは、ブラウザーとパッケージマネージャーも守れるため長期的にはこちらが優れた回答ですが、サーバー側の管理者権限と、 プッシュされた設定に従うクライアントが必要です。

どちらかを意図的に選びます。リゾルバーの変更はすべてのアプリケーションの名前解決を一度に変えるので、変更記録の対象であり、サポート通話のための編集ではありません。

サフィックスがすべてを説明することもある

クライアントが検索サフィックスもプッシュしている場合、短いローカル名は問い合わせの前にオフィスのドメインへ書き換えられます。その場合リゾルバーは少しも嘘をついておらず、オフィスの名前について正当な質問を受けて正しい回答を返しています。ファイルマネージャーでは二つの障害が同じに見えるため、広告アドレスの場合と区別するにはリゾルバーの出力で問い合わせ名を読んでください。

ここでの対処は、完全修飾されたローカル名を使うか、ローカルのサフィックスを管理する分割 DNS ルールを追加するかのどちらかです。どちらも Samba に触れる必要はありません。

再接続後に証明する

一度のセッションで三つの名前を試します。短い名前でのローカル共有、名前でのオフィスのホスト、そして普通の Web サイトです。一つ目が通り二つ目が壊れるなら、修復は障害を取り除かずに移したことになります。三つ目が壊れるなら、リゾルバーの変更が意図より行き過ぎており、すべての検索が疑わしくなっています。

そのあとトンネルを切断して再接続し、三つとも繰り返します。プッシュされたオプションは接続のたびに再適用されるため、実行時にしか存在しなかった修復は、設定ファイルが変わらないまま消えることがあります。どのサフィックスをどのリゾルバーが管理しているか、有効な検索順序、そして日付を記録してください。これが再発したとき、次のクライアント更新が明らかな容疑者になるからです。

五つの確認をすべて終えても共有が失敗する場合は、ほかの何かを変える前に、正確な問い合わせと正確な応答を記録してください。その二行が、リゾルバーの障害と本当に存在しない名前を区別し、書ける中で最速の引き継ぎメモになります。