Benoemde SQL Server-instantie oor 'n VPN: ontdekking, nie poort 1433 nie

Die meeste mense behandel 'n SQL Server-gasheernaam as 'n volledige adres, en 'n VPN as óf toegelaat óf nie. In die praktyk laat 'n benoemde instansie die kliënt ná DNS 'n tweede opsoek doen, en dit is juis daardie opsoek wat 'n tonnel die meeste keer breek. 'n Eksplisiete eindpunt omseil dit, en daarom kan tcp:host,port werk terwyl host\INSTANCE uittyd. Die onderskeid is tussen die diens vind en toegelaat word om dit te gebruik.

Die mite: een gasheernaam beteken een poort

Die gasheernaam los op na 'n adres, en dit is waar sy taak eindig. 'n Benoemde instansie voeg 'n instansienaam by wat die bediener in 'n TCP-poort moet vertaal, en die kliënt kan dit nie raai nie. Poort 1433 is die verstek vir 'n verstekinstansie, nie 'n eienskap van elke instansie op die masjien nie. Om die twee as dieselfde ding te behandel, lewer die klassieke simptoom: ping werk, DNS werk, die skandering van 1433 wys niks, en die gevolgtrekking is dat die netwerk SQL blokkeer.

'n Tweede aanname misluk op dieselfde manier: dat dit genoeg is om TCP 1433 oop te maak. As die instansie elders luister, bewys 'n oop 1433 net dat iets anders daar is. Die poort moet by die luisteraar pas, en die luisteraar is 'n konfigurasiedetail aan die bedienerkant moet jy vra eerder as aflei.

Wat die kliënt werklik met 'n benoemde instansie doen

Ná die oplos van die gasheer stuur die kliënt 'n ontdekkingsversoek na SQL Server Browser op UDP 1434 en vra watter poort die benoemde instansie gebruik. Die blaaierdiens antwoord uit die bediener se eie register, en die kliënt maak dan 'n TCP-verbinding na daardie poort. Twee protokolle en twee poorte is betrokke voordat daar selfs aan 'n aanmelding gedink word.

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

Daarom lewer 'n slegs-UDP-blok 'n uittyding wat soos 'n dooie gasheer lyk. As die blaaierdiens gestop of gedeaktiveer is, bly die ontdekkingsversoek onbeantwoord, selfs al loop die databasisenjin en is sy TCP-poort oop. As die instansie met 'n statiese poort opgestel is, vra die kliënt steeds, tensy die eindpunt direk aan hom gegee is. Elkeen van daardie foute lyk in die toepassing se foutboodskap identies, en hulle het verskillende regstellings nodig.

Die blaaierdiens is 'n ontdekkingsgerief, nie die databasis nie. Om dit te stop stop nie die enjin nie, en om dit te begin maak nie die instansie se TCP-poort oop nie.

Waarom die eksplisiete eindpunt werk wanneer die naam dit nie doen nie

'n Eksplisiete eindpunt verwyder die opsoek uit die reeks: die kliënt verbind reguit na die adres en poort wat jy genoem het. Dit is eers 'n diagnostikum, nie outomaties 'n permanente oplossing nie, want die poort kan verander as die instansie later na 'n dinamiese een herkonfigureer word. Vergelyk die twee vorms met dieselfde kliënt en dieselfde rekening voordat jy gevolgtrekkings maak.

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

As die eksplisiete vorm slaag en die benoemde vorm misluk, is ontdekking die gaping, en jy kan kies hoe om dit te sluit: laat UDP 1434 deur die tonnel toe, of laat die administrateur 'n statiese poort vaspen en die eindpunt dokumenteer. Albei is doelbewuste besluite met verskillende onderhoudskoste. Om elke poort in die reeks oop te maak is nie een van hulle nie, en dit is die opsie wat geneig is om aan die einde van 'n lang dag voorgestel te word. Teken die keuse aan waar die verbindingstringe woon.

As nie een van die vorms werk nie, sit die probleem stroomop van ontdekking. Kontroleer die luisteraar, die roete en die toegangsreël vir die poort wat die instansie werklik gebruik voordat jy die blaaierdiens blameer.

Ná ontdekking: verifikasie en identiteit is aparte dinge

'n Aanmeldingsfout is 'n ander gebeurtenis as 'n uittyding, en die VPN-identiteit word nie op grond van die tonnel 'n SQL-aanmelding nie. Sodra die kliënt die regte poort bereik, pas die databasisenjin sy eie verifikasie en toestemmings toe. Om die twee stadiums in een kaartjie te meng, is hoe 'n ontdekkingsprobleem aan die verkeerde span toegewys word. Lees die foutnommer voordat jy enigiets verander.

Hou die gedokumenteerde gasheernaam as die drywer die bediener se sertifikaat valideer, want om per numeriese adres te verbind kan daardie kontrole verander eerder as om die oorspronklike probleem op te los. Onlangse Microsoft-drywers versyfer by verstek, so 'n naamwanpassing verskyn as 'n sertifikaatfout ná 'n suksesvolle TCP-verbinding. Dit is vordering eerder as 'n nuwe fout.

Die mite om af te skaf is dat 'n SQL Server-gasheernaam 'n volledige adres is. Dit is 'n gasheer plus, vir 'n benoemde instansie, 'n opsoek wat die tonnel dalk nie dra nie. Noem die poort, noem die ontdekkingspad, en die volgende fout sal jou vertel watter laag om reg te maak.