Nei, ein tilkoplingsstreng kan ikkje starte VPN-tunnelen din

Utviklarar leitar framleis etter staden der ein tilkoplingsstreng, ein JDBC-URL eller ein tnsnames.ora-oppføring vel VPN-en. Ein slik stad finst ikkje. Tunnelen blir sett opp av operativsystemet eller ein klient frå ein leverandør som registrerer ein virtuell adapter, og kvart databasebibliotek over brukar socketlaget som følgjer. Ein tilkoplingsstreng nemner ein vert, ein port og ein påloggingsinformasjon, og det er heile ordforrådet.

Myte: tilkoplingsstrengen kan velje ein tunnel

Drivaren opnar ein TCP-socket til ein vert og ein port. Han har ingen API for å reise ein tunnel, ingen felt for ein tunnelprofil og ingen måte å autentisere mot ein VPN-gateway.

Difor oppfører verktøya seg likt når det først finst ei rute. SSMS, DBeaver, Eclipse Data Tools og ein vanleg sqlcmd oppfører seg som om tenaren er på det lokale nettet, fordi det sett frå socketen si side er han. Den virtuelle adapteren gjorde databasesubnettet tilgjengeleg, og drivaren veit aldri korleis.

Det forklarar også kvifor ein tilkoplingsstreng ikkje kan reparere ein tapt tunnel. Når sambandet døyr, rapporterer drivaren ein timeout eller ein generell nettverksfeil, og applikasjonskode som handsamar det som eit spørjeproblem, gjer den feil laget om att for alltid.

Reis tunnelen før drivaren køyrer

Kople til VPN-en på operativsystemnivå, etter instruksjonane frå leverandøren eller nettverksteamet, og opne først deretter verktøyet. I praksis tyder det at det finst ei rute til databasesubnettet før drivaren slår opp vertsnamnet.

Hald tilsynet med tunnelen utanfor applikasjonen. Ein PHP- eller Java-teneste som sjølv prøver å reise sambandet, kodar åtferda til ein leverandør inn i forretningskoden, og kvar failover blir ein applikasjonsutgjeving. Ein supervisør som eig tunnelen, overvakar han og startar han på nytt, er ei eiga sak frå spørjevegen.

Sjekk ruta før du gir drivaren skulda: viss vertsnamnet ikkje blir slått opp eller porten ikkje svarar frå skalet, endrar ingen tilkoplingsstreng det.

Myte: ein Windows-autentiseringsfeil tyder på at ruta er broten

Windows-autentisering over ein VPN mislukkast ofte med ein feil som ser ut som ein nettverksfeil, medan ruta er i orden. Når kontoen høyrer til eit anna domene og laptopen ikkje kan bli med i det, start klienten med eksplisitte påloggingsdetaljar i staden for identiteten til skrivebordsøkta.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

/netonly-brytaren held desse opplysningane berre for fjernautentisering. Stadfest kva tenaren faktisk tok imot med SELECT SUSER_SNAME() i staden for å stole på tilkoplingsdialogen. Det blir rapportert at lagring av påloggingsinformasjonen for tenaradressa i Windows Credential Manager fungerer for SSMS, men ikkje alltid for ein teneste som køyrer under ein annan konto, så sjekk kva identitet prosessen brukar før du endrar pålogginga.

Forsinking gjer ein markør på tenarsida om til ein timeout

Ein markør på tenarsida ber databasen halde resultatet og hente det trinnvis, noko som gjer eitt stort resultat om til mange små rundturar. På eit LAN er det billeg. Over ein tunnel med titals millisekund ekstra forseinking kan den same spørjinga overskride kommandotimeouten utan å overføre særleg mykje data.

Byt til ein markør på klientsida, eller auk hentestorleiken og batch radene, og talet på rundturar søkk. Flaskehalsen er talet på utvekslingar, ikkje den nominelle lenkefarten, så måling av gjennomstrøyming vil villede deg, medan måling av rundturar ikkje vil. Test med det største resultatsettet brukarane dine faktisk hentar, ikkje med ei spørjing på éi rad som kjem attende med ein gong. Viss timeouten flyttar seg men ikkje forsvinn, auk kommandotimeouten og hentestorleiken saman og mål på nytt.

Den same aritmetikken gjeld for snakkesalige ORM-ar og for kvar klient som sender éi setning per rad. Viss spørjeplanen er god og overføringa lita, tel nettverksutvekslingane før du tunar databasen.

Sjekk porten, instansen og det lokale filteret

Ein namngjeven instans lyttar på ein dynamisk port, så stadfest porten i staden for å ante 1433. På ein standardinstans kan verdien lesast frå TcpPort-registerverdien under SuperSocketNetLib-nøkkelen til instansen. For Oracle, kontroller at verten i tnsnames.ora blir slått opp, at adressa svarar og at lyttarporten er tillaten; 1521 er ein vanleg standardverdi, ikkje ein garanti.

Utelukk deretter eigen tilgangsliste for tunnelen og til slutt eit lokalt antivirusprogram eller ein vertsbrannmur som blokkerer sambandet sjølv når klient og tenar er same maskin. Fang stadiet som feilar før du endrar konfigurasjonen, fordi namneoppslag, TCP-tilgjenge og TLS eller pålogging feilar kvart med ei anna melding.

Skriv stadiet i saka. Elles vil den neste personen gjere den same leitinga etter tilkoplingsstrengen som starta alt.