Navngivet SQL Server-instans over VPN: opdagelse, ikke port 1433

De fleste behandler et SQL Server-værtsnavn som en komplet adresse og en VPN som enten tilladt eller ikke. I praksis får en navngivet instans klienten til at lave et ekstra opslag efter DNS, og det opslag er den del, en tunnel oftest bryder. Et eksplicit endepunkt omgår det, og derfor kan tcp:host,port virke, mens host\INSTANCE løber ud. Forskellen er mellem at finde tjenesten og at få lov til at bruge den.

Myten: ét værtsnavn betyder én port

Værtsnavnet opløses til en adresse, og det er der, dets arbejde slutter. En navngivet instans tilføjer et instansnavn, som serveren skal oversætte til en TCP-port, og klienten kan ikke gætte det. Port 1433 er standard for en standardinstans, ikke en egenskab ved hver instans på maskinen. Behandler man de to som det samme, får man det klassiske symptom: ping virker, DNS virker, scanningen af 1433 viser intet, og konklusionen er, at netværket blokerer SQL.

En anden antagelse fejler på samme måde: at det er nok at åbne TCP 1433. Hvis instansen lytter et andet sted, beviser en åben 1433 kun, at der er noget andet der. Porten skal matche lytteren, og at lytteren er en konfigurationsdetalje på serversiden, det skal man spørge om i stedet for at gætte.

Hvad klienten egentlig gør med en navngivet instans

Efter at have opløst værten sender klienten en opdagelsesanmodning til SQL Server Browser på UDP 1434 og spørger, hvilken port den navngivne instans bruger. Browsertjenesten svarer ud fra serverens egen registreringsdatabase, og derefter åbner klienten en TCP-forbindelse til den port. To protokoller og to porte er involveret, før et login overhovedet forsøges.

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

Derfor giver en blokering af kun UDP en timeout, der ligner en død vært. Hvis browsertjenesten er stoppet eller deaktiveret, forbliver opdagelsesanmodningen ubesvaret, selv om databasemotoren kører, og dens TCP-port er åben. Hvis instansen er konfigureret med en statisk port, spørger klienten stadig, medmindre den fik endepunktet direkte. Hver af disse fejl ser ens ud i programmets fejlmeddelelse, og de kræver forskellige rettelser.

Browsertjenesten er en bekvemmelighed til opdagelse, ikke databasen. At stoppe den stopper ikke motoren, og at starte den åbner ikke instansens TCP-port.

Hvorfor det eksplicitte endepunkt virker, når navnet ikke gør

Et eksplicit endepunkt fjerner opslaget fra sekvensen: klienten forbinder direkte til den adresse og port, du angav. Det er først en diagnose, ikke automatisk en permanent løsning, fordi porten kan ændre sig, hvis instansen senere omkonfigureres til en dynamisk. Sammenlign de to former med samme klient og samme konto, før du drager konklusioner.

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

Hvis den eksplicitte form lykkes, og den navngivne form fejler, er opdagelsen hullet, og du kan vælge, hvordan det lukkes: tillad UDP 1434 gennem tunnelen, eller bed administratoren fastgøre en statisk port og dokumentere endepunktet. Begge er bevidste beslutninger med forskellige vedligeholdelsesomkostninger. At åbne hver port i området er ingen af dem, og det er den mulighed, der plejer at blive foreslået ved afslutningen af en lang dag. Skriv valget ned, hvor forbindelsesstrengene bor.

Hvis ingen af formerne virker, sidder problemet opstrøms for opdagelsen. Kontroller lytteren, ruten og adgangsreglen for den port, instansen faktisk bruger, før du giver browsertjenesten skylden.

Efter opdagelsen: godkendelse og identitet er adskilte

En loginfejl er en anden begivenhed end en timeout, og VPN-identiteten bliver ikke et SQL-login i kraft af tunnelen. Når klienten når den rigtige port, anvender databasemotoren sin egen godkendelse og sine egne tilladelser. At blande de to faser i én sag er måden, hvorpå et opdagelsesproblem bliver tildelt det forkerte team. Læs fejlnummeret, før du ændrer noget.

Behold det dokumenterede værtsnavn, hvis driveren validerer serverens certifikat, fordi forbindelse via numerisk adresse kan ændre den kontrol i stedet for at løse det oprindelige problem. Nyere Microsoft-drivere krypterer som standard, så et navnemismatch dukker op som en certifikatfejl efter en vellykket TCP-forbindelse. Det er fremskridt, ikke en ny fejl.

Myten, der skal skrottes, er, at et SQL Server-værtsnavn er en komplet adresse. Det er en vært plus, for en navngivet instans, et opslag, som tunnelen måske ikke bærer. Navngiv porten, navngiv opdagelsesvejen, og den næste fejl vil fortælle dig, hvilket lag der skal rettes.