Instance bernama SQL Server melalui VPN: penemuan, bukan port 1433

Kebanyakan orang menganggap nama hos SQL Server sebagai alamat lengkap, dan VPN sebagai sama ada dibenarkan atau tidak. Dalam amalan, instance bernama memaksa klien membuat carian kedua selepas DNS, dan carian itulah bahagian yang paling kerap dipecahkan oleh terowong. Titik akhir eksplisit mengelakkannya, sebab itu tcp:host,port boleh berfungsi sementara host\INSTANCE kehabisan masa. Perbezaannya ialah antara menemui perkhidmatan dan mendapat kebenaran menggunakannya.

Mitos: satu nama hos bermaksud satu port

Nama hos diselesaikan kepada alamat, dan di situ tugasnya berakhir. Instance bernama menambah nama instance yang perlu diterjemahkan pelayan kepada port TCP, dan klien tidak boleh menekanya. Port 1433 ialah lalai bagi instance lalai, bukan sifat setiap instance pada mesin. Menganggap kedua-duanya sebagai perkara yang sama menghasilkan gejala klasik: ping berfungsi, DNS berfungsi, imbasan 1433 tidak menunjukkan apa-apa, dan kesimpulannya rangkaian menyekat SQL.

Andaian kedua gagal dengan cara yang sama: bahawa membuka TCP 1433 sudah memadai. Jika instance mendengar di tempat lain, 1433 yang terbuka hanya membuktikan ada sesuatu yang lain di sana. Port mesti sepadan dengan pendengar, dan bahawa pendengar ialah butiran konfigurasi di bahagian pelayan itu perlu ditanya bukan diandaikan.

Apa yang sebenarnya dilakukan klien dengan instance bernama

Selepas menyelesaikan hos, klien menghantar permintaan penemuan kepada SQL Browser melalui UDP 1434 dan bertanya port mana yang digunakan instance bernama. Perkhidmatan pelayar menjawab daripada registri pelayan itu sendiri, kemudian klien membuka sambungan TCP ke port tersebut. Dua protokol dan dua port terlibat sebelum log masuk cuba dilakukan.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Sebab itu sekatan hanya UDP menghasilkan tamat masa yang kelihatan seperti hos mati. Jika perkhidmatan pelayar dihentikan atau dilumpuhkan, permintaan penemuan kekal tanpa jawapan walaupun enjin pangkalan data berjalan dan port TCP-nya terbuka. Jika instance dikonfigurasikan dengan port statik, klien tetap bertanya kecuali titik akhir diberikan secara langsung. Setiap kegagalan itu kelihatan sama dalam mesej ralat aplikasi, dan ia memerlukan pembetulan yang berbeza.

Perkhidmatan pelayar ialah kemudahan penemuan, bukan pangkalan data. Menghentikannya tidak menghentikan enjin, dan memulakannya tidak membuka port TCP instance.

Mengapa titik akhir eksplisit berfungsi apabila nama tidak berfungsi

Titik akhir eksplisit mengeluarkan carian daripada urutan: klien menyambung terus ke alamat dan port yang anda namakan. Itu pertama sekali diagnostik, bukan pembetulan kekal secara automatik, kerana port boleh berubah jika instance dikonfigurasikan semula kepada port dinamik kemudian. Bandingkan kedua-dua bentuk dengan klien dan akaun yang sama sebelum membuat kesimpulan.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Jika bentuk eksplisit berjaya dan bentuk bernama gagal, penemuan ialah jurangnya, dan anda boleh memilih cara menutupnya: benarkan UDP 1434 melalui terowong, atau minta pentadbir menetapkan port statik dan mendokumentasikan titik akhir. Kedua-duanya keputusan sengaja dengan kos penyelenggaraan berbeza. Membuka setiap port dalam julat bukan kedua-duanya, dan itulah pilihan yang cenderung dicadangkan pada penghujung hari yang panjang. Catat pilihan itu di tempat rentetan sambungan berada.

Jika tiada bentuk berfungsi, masalahnya berada di hulu penemuan. Periksa pendengar, laluan dan peraturan akses untuk port yang benar-benar digunakan instance sebelum menyalahkan perkhidmatan pelayar.

Selepas penemuan: pengesahan dan identiti adalah berasingan

Kegagalan log masuk ialah peristiwa berbeza daripada tamat masa, dan identiti VPN tidak menjadi log masuk SQL kerana adanya terowong. Sebaik klien mencapai port yang betul, enjin pangkalan data menggunakan pengesahan dan kebenarannya sendiri. Mencampurkan kedua-dua peringkat dalam satu tiket ialah cara masalah penemuan ditugaskan kepada pasukan yang salah. Baca nombor ralat sebelum mengubah apa-apa.

Kekalkan nama hos yang didokumenkan jika pemacu mengesahkan sijil pelayan, kerana menyambung melalui alamat berangka boleh mengubah pemeriksaan itu daripada menyelesaikan masalah asal. Pemacu Microsoft terkini menyulitkan secara lalai, jadi ketidakpadanan nama muncul sebagai ralat sijil selepas sambungan TCP berjaya. Itu kemajuan, bukan kegagalan baharu.

Mitos yang perlu ditinggalkan ialah nama hos SQL Server ialah alamat lengkap. Ia ialah hos serta, untuk instance bernama, carian yang mungkin tidak dibawa terowong. Namakan port, namakan laluan penemuan, dan kegagalan seterusnya akan memberitahu lapisan mana yang perlu dibaiki.