SQL Server mengikat alamat VPN yang tidak ada saat boot

Baca baris log SQL Server tentang pengikatan yang gagal saat layanan masih berjalan, dan Anda telah menemukan ketergantungan urutan boot, bukan crash. Kombinasi itu adalah petunjuknya: mesin dimulai sebelum alamat yang diperintahkan untuk didengarkannya ada di mesin. Adaptor VPN yang muncul setelah masuk adalah prasyarat buruk untuk layanan basis data tanpa pengawasan, jadi telusuri kegagalan dalam urutan yang dilihat mesin.

Mulai dari log startup, bukan dari klien

Buka log kesalahan instans dan baca entri di sekitar inisialisasi jaringan, bukan hanya baris terakhir. Mesin melaporkan alamat mana yang dicoba dan protokol mana yang diaktifkan, dan catatan itu berasal dari sebelum klien mana pun terhubung. Sekarang lihat apa yang ada di host saat ini. Jika antarmuka yang memiliki alamat terkonfigurasi baru muncul setelah pengguna masuk dan menjalankan klien, alamat itu tidak ada saat boot dan kegagalan pengikatan sepenuhnya dijelaskan.

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

Sesuaikan jalur instans dengan instalasi Anda, dan baca daftar antarmuka sebelum menarik kesimpulan. Alamat yang ada tetapi dimiliki adaptor yang salah adalah masalah berbeda dari alamat yang belum ada.

Telusuri urutan pengikatan yang benar-benar diikuti mesin

Mesin membaca konfigurasi listener-nya, lalu meminta sistem operasi untuk mengikat. Jika alamat tidak lokal pada saat itu, pengikatan gagal untuk alamat tersebut sementara sisa instans dapat berjalan normal. Itulah sebabnya protokol atau alamat lain masih bisa berfungsi, dan itulah sebabnya „SQL Server mati“ adalah ringkasan yang salah. Simpan titik akhir persis dari log: alamat, port, dan protokol, karena perbaikannya bergantung pada mana dari ketiganya yang salah.

Memulai ulang layanan setelah adaptor muncul biasanya membuat listener berhasil, dan itulah tepatnya jebakannya. Itu membuktikan ketergantungan alih-alih menghilangkannya, dan memutus setiap pengguna yang terhubung setiap kali tunnel menyambung ulang.

Baca listener sebagaimana mesin membacanya

Di SQL Server Configuration Manager, buka properti TCP/IP instans dan perhatikan pengaturan Listen All sebelum mengedit alamat individual. Saat Listen All bernilai Yes, nilai Enabled per alamat diabaikan, jadi mengeditnya tidak mengubah apa pun yang digunakan listener. Catat tiga hal secara berurutan: alamat yang ingin Anda layani, port, dan apakah listener dimaksudkan mencakup semua alamat atau hanya satu. Lalu terapkan perubahan melalui prosedur mulai ulang yang didukung dan baca log startup berikutnya untuk memastikan mesin mengikat apa yang Anda minta.

Mendengarkan di setiap alamat bukanlah kontrol akses. Jika listener luas benar-benar diperlukan, setiap antarmuka yang dapat dijangkau memerlukan keputusan firewall dan otorisasi basis data sendiri, termasuk antarmuka apa pun yang menghadap internet.

Beri klien tujuan yang stabil

Klien tidak memerlukan host basis data memakai alamat kumpulan. Desain berutip berfungsi dengan server mendengarkan di alamat privatnya yang stabil sementara gateway VPN meneruskan lalu lintas klien kepadanya dan membawa balasannya kembali.

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

Jika klien mencapai 10.80.0.15, jalurnya terbukti dan basis data hanya perlu mengotorisasi klien itu. Jika tidak, perbaiki perutean dan DNS sebelum menyentuh listener lagi, karena masalah pengikatan di server tidak pernah menjadi alasan klien tidak dapat menemukannya. Menambahkan alamat kumpulan palsu ke server, atau gateway default kedua agar listener senang, menciptakan masalah jaringan baru di atas yang lama. Jaga pengalamatan server tetap statis dan biarkan tunnel membawa klien kepadanya.

Verifikasi titik akhir yang digunakan klien

Akhiri dengan pemeriksaan tingkat aplikasi alih-alih uji port. Hubungkan dari klien dengan akun yang digunakan aplikasi dan baca detail koneksi sisi server, yang menunjukkan alamat lokal tempat sesi Anda mendarat.

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"

Bandingkan alamat itu dengan listener yang Anda konfigurasi. Ketidakcocokan berarti listener kedua atau nama yang diselesaikan di tempat tak terduga, dan keduanya layak diketahui sebelum reboot berikutnya menguji perbaikan Anda untuk Anda. Lalu reboot host tanpa pengguna yang masuk dan pastikan pengikatan berhasil. Satu uji itu adalah perbedaan antara listener yang diperbaiki dan solusi sementara yang gagal pada malam patch berikutnya.