Namngitt SQL Server-forekomst over VPN: oppdaging, ikkje port 1433

Dei fleste handsamar eit SQL Server-vertnamn som ei fullstendig adresse og ein VPN som anten tillaten eller ikkje. I praksis får ei namngitt forekomst klienten til å gjere eit ekstra oppslag etter DNS, og det oppslaget er den delen ein tunnel oftast bryt. Eit eksplisitt endepunkt går utanom det, difor kan tcp:host,port virke medan host\INSTANCE renn ut. Skilnaden er mellom å finne tenesta og å få løyve til å bruke ho.

Myten: eitt vertnamn tyder éin port

Vertnamnet blir slått opp til ei adresse, og der sluttar jobben. Ei namngitt forekomst legg til eit forekomstnamn som serveren må omsetje til ein TCP-port, og klienten kan ikkje gjette det. Port 1433 er standarden for ei standardforekomst, ikkje ein eigenskap ved kvar forekomst på maskina. Handsamar ein dei to som det same, får ein det klassiske symptomet: ping virkar, DNS virkar, skanninga av 1433 viser ingenting, og konklusjonen er at nettverket blokkerer SQL.

Ei anna føresetnad feilar på same vis: at det er nok å opne TCP 1433. Viss forekomsta lyttar ein annan stad, beviser ein open 1433 berre at noko anna er der. Porten må stemme med lyttaren, og at lyttaren er ein konfigurasjonsdetalj på serversida det bør ein spørje om i staden for å gjette.

Kva klienten faktisk gjer med ei namngitt forekomst

Etter å ha slått opp verten sender klienten ein oppdagingsførespurnad til SQL Server Browser på UDP 1434 og spør kva port den namngitte forekomsta brukar. Nettlesartenesta svarar frå serveren sitt eige register, og deretter opnar klienten ei TCP-tilkopling til den porten. To protokollar og to portar er med før ein innlogging i det heile blir forsøkt.

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

Difor gir ei blokkering av berre UDP ein tidsavbrot som ser ut som ein død vert. Viss nettlesartenesta er stoppa eller deaktivert, blir oppdagingsførespurnaden utan svar sjølv om databasemotoren køyrer og TCP-porten er open. Viss forekomsta er sett opp med ein statisk port, spør klienten likevel, med mindre han fekk endepunktet direkte. Kvar av desse feila ser like ut i feilmeldinga til programmet, og dei treng ulike rettingar.

Nettlesartenesta er ei bekvemmelegheit for oppdaging, ikkje databasen. Å stoppe ho stoppar ikkje motoren, og å starte ho opnar ikkje TCP-porten til forekomsta.

Kvifor det eksplisitte endepunktet virkar når namnet ikkje gjer det

Eit eksplisitt endepunkt tek oppslaget ut av sekvensen: klienten koplar seg direkte til adressa og porten du oppgav. Det er først ein diagnose, ikkje automatisk ei varig løysing, fordi porten kan endre seg viss forekomsta seinare blir sett om til ein dynamisk. Samanlikn dei to formene med same klient og same konto før du dreg konklusjonar.

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

Viss den eksplisitte forma lukkast og den namngitte feilar, er oppdaginga gapet, og du kan velje korleis du lukkar det: tillat UDP 1434 gjennom tunnelen, eller be administratoren feste ein statisk port og dokumentere endepunktet. Begge er medvitne avgjerder med ulike vedlikehaldskostnader. Å opne kvar port i området er ingen av dei, og det er alternativet som plar bli føreslått på slutten av ein lang dag. Skriv ned valet der tilkoplingstekstane bur.

Viss ingen av formene virkar, sit problemet oppstraums for oppdaginga. Kontroller lyttaren, ruta og tilgangsregelen for porten forekomsta faktisk brukar, før du gir nettlesartenesta skulda.

Etter oppdaginga: autentisering og identitet er skilde

Ein innloggingsfeil er ei anna hending enn eit tidsavbrot, og VPN-identiteten blir ikkje ei SQL-innlogging i kraft av tunnelen. Når klienten når rett port, brukar databasemotoren si eiga autentisering og sine eigne rettar. Å blande dei to fasane i éi sak er måten eit oppdagingsproblem blir tildelt feil team. Les feilnummeret før du endrar noko.

Hald på det dokumenterte vertnamnet viss drivaren validerer sertifikatet til serveren, fordi tilkopling via numerisk adresse kan endre den kontrollen i staden for å løyse det opphavlege problemet. Nyare Microsoft-drivarar krypterer som standard, så eit namneavvik dukkar opp som ein sertifikatfeil etter ei vellukka TCP-tilkopling. Det er framgang, ikkje ein ny feil.

Myten som bør leggjast bort, er at eit SQL Server-vertnamn er ei fullstendig adresse. Det er ein vert pluss, for ei namngitt forekomst, eit oppslag som tunnelen kanskje ikkje ber. Namngi porten, namngi oppdagingsvegen, og neste feil vil fortelje deg kva lag som skal reparerast.