Nomita SQL Server-instalaĵo tra VPN: malkovro, ne pordo 1433

Plej multaj homoj traktas gastigantnomon de SQL Server kiel kompletan adreson, kaj VPN kiel ion permesitan aŭ ne. En praktiko, nomita instalaĵo igas la klienton fari duan serĉon post DNS, kaj ĝuste tiu serĉo estas la parto, kiun tunelo plej ofte rompas. Klara finpunkto evitas ĝin, tial tcp:host,port povas funkcii dum host\INSTANCE finiĝas per tempolimo. La diferenco estas inter trovi la servon kaj ricevi permeson uzi ĝin.

La mito: unu gastigantnomo signifas unu pordon

La gastigantnomo solviĝas al adreso, kaj tie ĝia laboro finiĝas. Nomita instalaĵo aldonas instalaĵan nomon, kiun la servilo devas traduki al TCP-pordo, kaj la kliento ne povas diveni ĝin. Pordo 1433 estas la defaŭlto por defaŭlta instalaĵo, ne eco de ĉiu instalaĵo en la maŝino. Se oni traktas ambaŭ kiel la saman aferon, aperas la klasika simptomo: ping funkcias, DNS funkcias, la skano de 1433 montras nenion, kaj la konkludo estas, ke la reto blokas SQL.

Dua supozo malsukcesas same: ke malfermi TCP 1433 sufiĉas. Se la instalaĵo aŭskultas aliloke, malfermita 1433 pruvas nur, ke io alia estas tie. La pordo devas kongrui kun la aŭskultanto, kaj ke la aŭskultanto estas agordo-detalo ĉe la servila flanko, pri tio oni demandu anstataŭ diveni.

Kion la kliento efektive faras kun nomita instalaĵo

Post solvo de la gastiganto, la kliento sendas malkovran peton al SQL Server Browser per UDP 1434 kaj demandas, kiun pordon la nomita instalaĵo uzas. La retumila servo respondas el la propra registrejo de la servilo, kaj poste la kliento malfermas TCP-konekton al tiu pordo. Du protokoloj kaj du pordoj partoprenas antaŭ ol eĉ proviĝas ensaluto.

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

Tial nur-UDP-blokado produktas tempolimon, kiu aspektas kiel morta gastiganto. Se la retumila servo estas haltigita aŭ malŝaltita, la malkovra peto restas senresponda, kvankam la datumbaza motoro funkcias kaj ĝia TCP-pordo estas malfermita. Se la instalaĵo estas agordita kun statika pordo, la kliento tamen demandas, krom se la finpunkto estis donita rekte al ĝi. Ĉiu el tiuj fiaskoj aspektas idente en la erarmesaĝo de la aplikaĵo, kaj ili bezonas malsamajn riparojn.

La retumila servo estas malkovra oportuneco, ne la datumbazo. Haltigi ĝin ne haltigas la motoron, kaj startigi ĝin ne malfermas la TCP-pordon de la instalaĵo.

Kial la klara finpunkto funkcias, kiam la nomo ne funkcias

Klara finpunkto forigas la serĉon el la sinsekvo: la kliento konektiĝas rekte al la adreso kaj pordo, kiujn vi nomis. Tio unue estas diagnozo, ne aŭtomate daŭra solvo, ĉar la pordo povas ŝanĝiĝi, se la instalaĵo poste reagordiĝos al dinamika. Komparu la du formojn per la sama kliento kaj la sama konto antaŭ konkludi.

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

Se la klara formo sukcesas kaj la nomita fiaskas, la malkovro estas la manko, kaj vi povas elekti, kiel fermi ĝin: permesi UDP 1434 tra la tunelo, aŭ peti la administranton fiksi statikan pordon kaj dokumenti la finpunkton. Ambaŭ estas konsciaj decidoj kun malsamaj prizorgaj kostoj. Malfermi ĉiun pordon en la gamo estas nek unu nek la alia, kaj ĝi estas la opcio, kiu emas esti proponita ĉe la fino de longa tago. Notu la elekton tie, kie loĝas la konektaj ĉenoj.

Se neniu formo funkcias, la problemo sidas supre de la malkovro. Kontrolu la aŭskultanton, la itineron kaj la alirregulon por la pordo, kiun la instalaĵo efektive uzas, antaŭ ol kulpigi la retumilan servon.

Post la malkovro: aŭtentikigo kaj identeco estas apartaj

Ensalta fiasko estas alia evento ol tempolimo, kaj la VPN-identeco ne fariĝas SQL-ensaluto pro la tunelo. Post kiam la kliento atingas la ĝustan pordon, la datumbaza motoro aplikas sian propran aŭtentikigon kaj permesojn. Miksi la du etapojn en unu bileto estas la maniero, kiel malkovra problemo estas atribuata al la malĝusta teamo. Legu la erarnumeron antaŭ ol ŝanĝi ion ajn.

Konservu la dokumentitan gastigantnomon, se la pelilo validigas la servilan atestilon, ĉar konektiĝo per numera adreso povas ŝanĝi tiun kontrolon anstataŭ solvi la originan problemon. Lastatempaj Microsoft-peliloj ĉifras defaŭlte, do nom-miskongruo aperas kiel atestila eraro post sukcesa TCP-konekto. Tio estas progreso, ne nova fiasko.

La mito, kiun oni forlasu, estas, ke gastigantnomo de SQL Server estas kompleta adreso. Ĝi estas gastiganto plus, por nomita instalaĵo, serĉo, kiun la tunelo eble ne portas. Nomu la pordon, nomu la malkovran vojon, kaj la sekva fiasko diros al vi, kiun tavolon ripari.