Navngitt SQL Server-forekomst over VPN: oppdagelse, ikke port 1433

De fleste behandler et SQL Server-vertnavn som en fullstendig adresse og en VPN som enten tillatt eller ikke. I praksis får en navngitt forekomst klienten til å gjøre et ekstra oppslag etter DNS, og det oppslaget er den delen en tunnel oftest bryter. Et eksplisitt endepunkt omgår det, derfor kan tcp:host,port virke mens host\INSTANCE løper ut. Forskjellen er mellom å finne tjenesten og å få lov til å bruke den.

Myten: ett vertnavn betyr én port

Vertnavnet slås opp til en adresse, og der slutter jobben. En navngitt forekomst legger til et forekomstnavn som serveren må oversette til en TCP-port, og klienten kan ikke gjette det. Port 1433 er standarden for en standardforekomst, ikke en egenskap ved hver forekomst på maskinen. Behandler man de to som det samme, får man det klassiske symptomet: ping virker, DNS virker, skanningen av 1433 viser ingenting, og konklusjonen er at nettverket blokkerer SQL.

En annen antakelse feiler på samme måte: at det er nok å åpne TCP 1433. Hvis forekomsten lytter et annet sted, beviser en åpen 1433 bare at noe annet er der. Porten må stemme med lytteren, og at lytteren er en konfigurasjonsdetalj på serversiden det bør man spørre om i stedet for å gjette.

Hva klienten faktisk gjør med en navngitt forekomst

Etter å ha slått opp verten sender klienten en oppdagelsesforespørsel til SQL Server Browser på UDP 1434 og spør hvilken port den navngitte forekomsten bruker. Nettlesertjenesten svarer fra serverens eget register, og deretter åpner klienten en TCP-forbindelse til den porten. To protokoller og to porter er involvert før en innlogging i det hele tatt forsøkes.

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

Derfor gir en blokkering av bare UDP en tidsavbrudd som ser ut som en død vert. Hvis nettlesertjenesten er stoppet eller deaktivert, blir oppdagelsesforespørselen ubesvart selv om databasemotoren kjører og TCP-porten er åpen. Hvis forekomsten er konfigurert med en statisk port, spør klienten likevel, med mindre den fikk endepunktet direkte. Hver av disse feilene ser like ut i programmets feilmelding, og de trenger ulike rettelser.

Nettlesertjenesten er en bekvemmelighet for oppdagelse, ikke databasen. Å stoppe den stopper ikke motoren, og å starte den åpner ikke forekomstens TCP-port.

Hvorfor det eksplisitte endepunktet virker når navnet ikke gjør det

Et eksplisitt endepunkt fjerner oppslaget fra sekvensen: klienten kobler seg direkte til adressen og porten du oppgav. Det er først en diagnose, ikke automatisk en varig løsning, fordi porten kan endres hvis forekomsten senere konfigureres om til en dynamisk. Sammenlign de to formene med samme klient og samme konto før du trekker konklusjoner.

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

Hvis den eksplisitte formen lykkes og den navngitte feiler, er oppdagelsen gapet, og du kan velge hvordan du lukker det: tillat UDP 1434 gjennom tunnelen, eller be administratoren feste en statisk port og dokumentere endepunktet. Begge er bevisste beslutninger med ulike vedlikeholdskostnader. Å åpne hver port i området er ingen av dem, og det er alternativet som pleier å bli foreslått på slutten av en lang dag. Skriv ned valget der tilkoblingsstrengene bor.

Hvis ingen av formene virker, sitter problemet oppstrøms for oppdagelsen. Kontroller lytteren, ruten og tilgangsregelen for porten forekomsten faktisk bruker, før du gir nettlesertjenesten skylden.

Etter oppdagelsen: autentisering og identitet er atskilt

En innloggingsfeil er en annen hendelse enn en tidsavbrudd, og VPN-identiteten blir ikke en SQL-innlogging i kraft av tunnelen. Når klienten når riktig port, bruker databasemotoren sin egen autentisering og sine rettigheter. Å blande de to fasene i én sak er måten et oppdagelsesproblem blir tildelt feil team. Les feilnummeret før du endrer noe.

Behold det dokumenterte vertnavnet hvis driveren validerer serverens sertifikat, fordi tilkobling via numerisk adresse kan endre den kontrollen i stedet for å løse det opprinnelige problemet. Nyere Microsoft-drivere krypterer som standard, så et navneavvik dukker opp som en sertifikatfeil etter en vellykket TCP-forbindelse. Det er fremgang, ikke en ny feil.

Myten som bør legges bort, er at et SQL Server-vertnavn er en fullstendig adresse. Det er en vert pluss, for en navngitt forekomst, et oppslag som tunnelen kanskje ikke bærer. Navngi porten, navngi oppdagelsesveien, og neste feil vil fortelle deg hvilket lag som skal repareres.