Megnevezett SQL Server-példány VPN-en át: felderítés, nem a 1433-as port

A legtöbb ember egy SQL Server-gépnevet teljes címnek tekint, a VPN-t pedig vagy engedélyezettnek, vagy nem. A gyakorlatban a megnevezett példány arra készteti a klienst, hogy a DNS után egy második keresést is végezzen, és éppen ezt a keresést töri meg leggyakrabban egy alagút. Egy explicit végpont megkerüli, ezért működhet a tcp:host,port, miközben a host\INSTANCE időtúllépésbe fut. A különbség a szolgáltatás megtalálása és a használatára kapott engedély között van.

A mítosz: egy gépnév egy portot jelent

A gépnév egy címre oldódik fel, és ott véget ér a feladata. A megnevezett példány hozzáad egy példánynevet, amelyet a kiszolgálónak TCP-porttá kell alakítania, a kliens pedig nem tudja kitalálni. A 1433-as port az alapértelmezett példány alapértéke, nem a gépen lévő minden példány tulajdonsága. Ha a kettőt ugyanannak tekintjük, megjelenik a klasszikus tünet: a ping működik, a DNS működik, a 1433 vizsgálata semmit sem mutat, és a következtetés az, hogy a hálózat blokkolja az SQL-t.

Egy második feltevés ugyanígy megbukik: hogy a TCP 1433 megnyitása elég. Ha a példány máshol figyel, egy nyitott 1433 csak azt bizonyítja, hogy ott valami más van. A portnak egyeznie kell a figyelővel, és erről hogy a figyelő kiszolgálóoldali konfigurációs részlet, kérdezni kell, nem feltételezni.

Mit tesz valójában a kliens egy megnevezett példánnyal

A gépnév feloldása után a kliens felderítési kérést küld a SQL Server Browsernek UDP 1434-en, és megkérdezi, melyik portot használja a megnevezett példány. A böngészőszolgáltatás a kiszolgáló saját beállításjegyzékéből válaszol, majd a kliens TCP-kapcsolatot nyit arra a portra. Két protokoll és két port vesz részt, mielőtt bármilyen bejelentkezést megkísérelnének.

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

Ezért egy csak UDP-t érintő blokk olyan időtúllépést okoz, amely halott gépnek látszik. Ha a böngészőszolgáltatás leáll vagy le van tiltva, a felderítési kérés válasz nélkül marad, pedig az adatbázismotor fut, és a TCP-portja nyitva van. Ha a példány statikus portra van beállítva, a kliens mégis kérdez, hacsak nem kapta meg közvetlenül a végpontot. E hibák mindegyike azonosnak látszik az alkalmazás hibaüzenetében, és különböző javításokat igényelnek.

A böngészőszolgáltatás felderítési kényelmi eszköz, nem az adatbázis. Leállítása nem állítja le a motort, elindítása pedig nem nyitja meg a példány TCP-portját.

Miért működik az explicit végpont, amikor a név nem

Az explicit végpont kiveszi a keresést a sorrendből: a kliens közvetlenül az általad megnevezett címre és portra csatlakozik. Ez először diagnózis, nem automatikusan tartós megoldás, mert a port megváltozhat, ha a példányt később dinamikusra állítják át. Hasonlítsd össze a két formát ugyanazzal a klienssel és ugyanazzal a fiókkal, mielőtt következtetéseket vonsz le.

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

Ha az explicit forma sikerül, a megnevezett pedig nem, a felderítés a hiányzó láncszem, és eldöntheted, hogyan zárod be: engedélyezed az UDP 1434-et az alagúton, vagy megkéred az adminisztrátort, hogy rögzítsen statikus portot és dokumentálja a végpontot. Mindkettő szándékos döntés, eltérő karbantartási költséggel. A tartomány minden portjának megnyitása egyik sem, és ez az a lehetőség, amelyet hosszú nap végén szoktak javasolni. Jegyezd fel a választást ott, ahol a kapcsolati karakterláncok élnek.

Ha egyik forma sem működik, a probléma a felderítés felett van. Ellenőrizd a figyelőt, az útvonalat és a hozzáférési szabályt arra a portra, amelyet a példány valóban használ, mielőtt a böngészőszolgáltatást hibáztatnád.

Felderítés után: a hitelesítés és az identitás különvált

A bejelentkezési hiba más esemény, mint az időtúllépés, és a VPN-identitás nem lesz SQL-bejelentkezés az alagút miatt. Amikor a kliens eléri a megfelelő portot, az adatbázismotor a saját hitelesítését és engedélyeit alkalmazza. A két szakasz egy jegybe való keverése az, ahogy egy felderítési probléma a rossz csapathoz kerül. Olvasd el a hibaszámot, mielőtt bármit módosítanál.

Tartsd meg a dokumentált gépnevet, ha az illesztőprogram ellenőrzi a kiszolgáló tanúsítványát, mert a numerikus címen való csatlakozás megváltoztathatja ezt az ellenőrzést ahelyett, hogy megoldaná az eredeti problémát. A Microsoft újabb illesztőprogramjai alapértelmezés szerint titkosítanak, ezért a névegyezés hiánya tanúsítványhibaként jelenik meg egy sikeres TCP-kapcsolat után. Ez előrelépés, nem új hiba.

A mítosz, amelyet el kell vetni, hogy az SQL Server gépneve teljes cím. Ez egy gépnév plusz, megnevezett példány esetén egy keresés, amelyet az alagút esetleg nem visz át. Nevezd meg a portot, nevezd meg a felderítési utat, és a következő hiba megmondja, melyik réteget kell javítani.