Pomenovaná inštancia SQL Server cez VPN: zisťovanie, nie port 1433
Pomenovaná inštancia sa pred pripojením pýta SQL Browseru na port. Ak meno cez VPN zlyhá, ale tcp:host,port funguje, medzerou je zisťovanie.
Väčšina ľudí považuje názov hostiteľa SQL Serveru za úplnú adresu a VPN za niečo, čo je buď povolené, alebo nie. V praxi pomenovaná inštancia prinúti klienta vykonať po DNS druhý dopyt, a práve tento dopyt tunel najčastejšie láme. Explicitný koncový bod sa mu vyhne, preto tcp:host,port môže fungovať, kým host\INSTANCE vyprší. Rozdiel je medzi nájdením služby a získaním povolenia ju používať.
Mýtus: jeden názov hostiteľa znamená jeden port
Názov hostiteľa sa preloží na adresu a tým jeho práca končí. Pomenovaná inštancia pridáva názov inštancie, ktorý musí server preložiť na TCP port, a klient ho nedokáže uhádnuť. Port 1433 je predvolený pre predvolenú inštanciu, nie vlastnosť každej inštancie na stroji. Ak sa obe považujú za to isté, vznikne klasický príznak: ping funguje, DNS funguje, sken 1433 nič neukáže a záver je, že sieť blokuje SQL.
Druhý predpoklad zlyháva rovnako: že stačí otvoriť TCP 1433. Ak inštancia načúva inde, otvorený 1433 dokazuje len to, že tam je niečo iné. Port sa musí zhodovať s naslúchajúcou službou a že naslúchajúca služba je detail konfigurácie na strane servera, to sa má zistiť dopytom, nie odhadom.
Čo klient s pomenovanou inštanciou skutočne robí
Po preložení hostiteľa pošle klient žiadosť o zistenie na SQL Server Browser cez UDP 1434 a pýta sa, ktorý port pomenovaná inštancia používa. Služba prehliadača odpovedá z vlastného registra servera a klient potom otvorí TCP pripojenie k tomuto portu. Pred pokusom o prihlásenie sa zúčastňujú dva protokoly a dva porty.
nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser
Preto blokovanie iba UDP vytvára časový limit, ktorý vyzerá ako mŕtvy hostiteľ. Ak je služba prehliadača zastavená alebo zakázaná, žiadosť o zistenie zostane bez odpovede, hoci databázový stroj beží a jeho TCP port je otvorený. Ak je inštancia nakonfigurovaná so statickým portom, klient sa stále pýta, ak nedostal koncový bod priamo. Každá z týchto porúch vyzerá v chybovej správe aplikácie rovnako a potrebujú rôzne opravy.
Služba prehliadača je pohodlie pre zisťovanie, nie databáza. Jej zastavenie nezastaví stroj a jej spustenie neotvorí TCP port inštancie.
Prečo explicitný koncový bod funguje, keď názov nie
Explicitný koncový bod odstraňuje dopyt z postupnosti: klient sa pripojí priamo na adresu a port, ktoré ste uviedli. To je najprv diagnostika, nie automaticky trvalé riešenie, pretože port sa môže zmeniť, ak sa inštancia neskôr prekonfiguruje na dynamický. Pred vyvodením záverov porovnajte obe formy s rovnakým klientom a rovnakým účtom.
sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433
Ak explicitná forma funguje a pomenovaná zlyháva, medzerou je zisťovanie a môžete si zvoliť, ako ju uzavrieť: povoliť UDP 1434 tunelom, alebo požiadať správcu, aby pripol statický port a zdokumentoval koncový bod. Oboje sú zámerné rozhodnutia s rôznymi nákladmi na údržbu. Otvoriť každý port v rozsahu nie je ani jedno z toho a je to možnosť, ktorá sa zvyčajne navrhuje na konci dlhého dňa. Zapíšte voľbu tam, kde žijú pripojovacie reťazce.
Ak nefunguje ani jedna forma, problém je vyššie ako zisťovanie. Skontrolujte naslúchajúcu službu, trasu a prístupové pravidlo pre port, ktorý inštancia skutočne používa, skôr než obviníte službu prehliadača.
Po zistení: overovanie a identita sú oddelené
Zlyhanie prihlásenia je iná udalosť ako časový limit a identita VPN sa tunelom nestane prihlásením SQL. Keď klient dosiahne správny port, databázový stroj uplatní svoje vlastné overovanie a oprávnenia. Zmiešanie oboch fáz v jednom tikete je spôsob, akým sa problém so zisťovaním priradí nesprávnemu tímu. Pred zmenou čohokoľvek si prečítajte číslo chyby.
Ponechajte zdokumentovaný názov hostiteľa, ak ovládač overuje certifikát servera, pretože pripojenie cez číselnú adresu môže túto kontrolu zmeniť namiesto vyriešenia pôvodného problému. Novšie ovládače Microsoftu štandardne šifrujú, takže nezhoda názvu sa prejaví ako chyba certifikátu po úspešnom TCP pripojení. To je pokrok, nie nová porucha.
Mýtus, ktorého sa treba vzdať, je že názov hostiteľa SQL Serveru je úplná adresa. Je to hostiteľ plus, pre pomenovanú inštanciu, dopyt, ktorý tunel nemusí preniesť. Pomenujte port, pomenujte cestu zisťovania a ďalšia porucha vám povie, ktorú vrstvu opraviť.