SQL Server が起動時に存在しない VPN アドレスへバインドする

サービスが動作している最中に「バインドに失敗した」という SQL Server のログ行を読んだなら、それはクラッシュではなく起動順序への依存を見つけたことになります。その組み合わせが手がかりです。エンジンは、待ち受けるよう指示されたアドレスがマシン上に存在する前に起動していたのです。サインイン後に上がってくる VPN アダプターは、無人で動くデータベースサービスには不適切な前提条件です。だからエンジンが見る順序で失敗をたどってください。

クライアントではなく起動ログから始める

インスタンスのエラーログを開き、最後の行だけでなくネットワーク初期化の前後のエントリを読みます。エンジンは試したアドレスと有効にしたプロトコルを記録しており、その記録はどのクライアントも接続する前のものです。次に、いまホスト上に何が存在するかを見ます。設定されたアドレスを持つインターフェースが、ユーザーのサインインとクライアント起動の後にしか現れないなら、起動時にアドレスは存在せず、バインド失敗は完全に説明できます。

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

インスタンスのパスを自分のインストールに合わせ、結論を出す前にインターフェース一覧を読みます。存在するが誤ったアダプターに属するアドレスは、まだ存在しないアドレスとは別の問題です。

エンジンが実際にたどるバインド順序を追う

エンジンはリスナー設定を読み、次にオペレーティングシステムにバインドを要求します。その時点でアドレスがローカルになければ、そのアドレスのバインドは失敗しますが、インスタンスの残りは正常に続行できます。だから他のプロトコルや他のアドレスが動き続けることがあり、だから「SQL Server が落ちている」という要約は誤りなのです。ログから正確なエンドポイント、つまりアドレス、ポート、プロトコルを保存してください。修正は三つのうちどれが誤っているかで決まります。

アダプターが現れた後にサービスを再起動すると、たいていリスナーは成功します。これこそが罠です。依存を除去するのではなく証明してしまううえ、トンネルが再接続するたびに接続中の全ユーザーを切断します。

エンジンが読むようにリスナーを読む

SQL Server Configuration Manager でインスタンスの TCP/IP プロパティを開き、個々のアドレスを編集する前に Listen All の設定を確認します。Listen All が Yes のときはアドレスごとの Enabled 値が無視されるため、編集してもリスナーが使うものは何も変わりません。三つを順に記録します。提供したいアドレス、ポート、そしてリスナーが全アドレスを対象とするのか一つだけなのか。その後、サポートされた再起動手順で変更を適用し、次の起動ログを読んでエンジンが要求どおりにバインドしたことを確認します。

すべてのアドレスで待ち受けることはアクセス制御ではありません。広いリスナーが本当に必要な場合、到達可能な各インターフェースにはそれぞれファイアウォールとデータベース認可の判断が必要で、インターネットに面するインターフェースも含まれます。

クライアントに安定した接続先を与える

クライアントは、データベースホストがプールのアドレスをまとう必要はありません。ルーティング設計では、サーバーは安定したプライベートアドレスで待ち受け、VPN ゲートウェイがクライアントの通信をそこへ転送して応答を戻します。

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

クライアントが 10.80.0.15 に到達できれば経路は証明され、データベースはそのクライアントを認可するだけで済みます。到達できなければ、リスナーに再び触れる前にルーティングと DNS を直してください。サーバー側のバインド問題が、クライアントがサーバーを見つけられない理由だったことは一度もありません。サーバーに偽のプールアドレスを足したり、リスナーを満足させるために二つ目のデフォルトゲートウェイを足したりすると、古い問題の上に新しいネットワーク問題を作ります。サーバーのアドレス指定は静的に保ち、トンネルにクライアントを運ばせてください。

クライアントが使ったエンドポイントを検証する

ポート試験ではなくアプリケーション層の確認で締めくくります。アプリケーションが使うアカウントでクライアントから接続し、サーバー側の接続詳細を読みます。そこにはセッションが着地したローカルアドレスが表示されます。

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

そのアドレスを設定したリスナーと比較します。不一致は二つ目のリスナーか、予期しない場所で解決される名前を意味し、どちらも次の再起動があなたの代わりに修正を試す前に知っておく価値があります。次に、誰もサインインしていない状態でホストを再起動し、バインドが成功することを確認します。その一つの試験が、直ったリスナーと次のパッチ夜に失敗する回避策との違いです。