VPNアドレスのSamba：リスナーが消える理由

共有は午前中ずっと動いていたが、昼にトンネルが再接続し、同じUNCパスが今度はタイムアウトする一方で、サーバーへのpingはまだ応答している。共有の定義は何も変わっておらず、VPNも稼働している。変わったのはSambaがバインドしていたローカルアドレスで、インターフェースが作り直されたあとにそれは存在しない。この障害の形は権限の問題ではなく、リスナーのライフサイクルの問題である。

共有はトンネルが再起動するまで動く

サービスをアドレスにバインドすると、そのソケットはアドレスの寿命に結び付く。トンネルのインターフェースが破棄されて作り直されると、古いアドレスは消え、それにバインドされていたソケットも一緒に消える。サービスは動き続けるが、クライアントが振り向けられている場所では何も待ち受けていない。

新しいアドレスがICMPに応答すればpingは成功しうるので、共有が死んでいるのに到達性だけは正常に見える。この一つの紛らわしい成功が、人をファイアウォールへ向かわせる。

到達性はバインドアドレスではない

ここでは三つの判断が混ざっている。経路はクライアントのパケットが届くかを決める。待ち受けているソケットは、ローカルアドレスでそれを受け入れるものがあるかを決める。共有の設定とファイルシステムの権限は、その後に何が起きるかを決める。インターフェースが作り直されたときに壊れるのは二つ目だけである。

VPNプールのアドレスも自動的にローカルのバインドアドレスになるわけではない。それはクライアントのものであり、ファイルサーバーのものではない。ファイルサービスにとってpingは弱い検査である。

文書でもこれらの持ち主を分けておく。将来VPNプールを変えるときにSambaの編集が要るべきではないし、共有の権限を変えるときにトンネルの再起動が要るべきでもない。

代わりに安定したアドレスにバインドする

より安定した設計は、Sambaを固定アドレスに置き、VPNにクライアントをそこへ運ばせる。トンネルが揺れてもサーバーのアドレスは変わらないので、リスナーがインターフェースを追う必要はなく、受け入れを強制するのはVPNの経路とホストのファイアウォールである。これらはその仕事のために作られている。

トンネルにバインドしなければならないなら、インストールされたリリースの契約を理解すること。interfacesとbind interfaces onlyは同じものではなく、バインドの文書は断続的なインターフェースについて警告している。一部のプラットフォームには動的なリスナー処理があるが、それは前提にするものではなく検証する能力である。揺れる前と後でテーブルを読み、二つの出力を比較すること。

ss -ltnp | grep ':445'

再接続を試すのであって、緑のランプではない

サービスの起動後だけでなく、再接続のあとにリスナーを検証する。トンネルを作り直し、待ち受けテーブルを読んで、クライアントが振り向けられるアドレスにソケットがあることを確かめる。緑のトンネル表示と構成チェックの合格は、どちらも証明しない。

smbclient -L //files.corp.example -U alice

そのあとクライアントから許可される操作と拒否される経路を一つずつ実行し、二度目の再接続のあとに繰り返す。共有が最初の揺れまでしか動かないなら、バインドはまだインターフェースの寿命に縛られており、設計は直っていない。バインドかサービスのアドレスを変えれば、症状は戻らなくなる。