Nei, en tilkoblingsstreng kan ikke starte VPN-tunnelen din

Utviklere leter fortsatt etter stedet der en tilkoblingsstreng, en JDBC-URL eller en tnsnames.ora-oppføring velger VPN-en. Et slikt sted finnes ikke. Tunnelen settes opp av operativsystemet eller en klient fra en leverandør som registrerer en virtuell adapter, og hvert databasbibliotek over bruker socketlaget som følger. En tilkoblingsstreng navngir en vert, en port og en påloggingsinformasjon, og det er hele ordforrådet.

Myte: tilkoblingsstrengen kan velge en tunnel

Driveren åpner en TCP-socket til en vert og en port. Den har ingen API for å reise en tunnel, ingen felt for en tunnelprofil og ingen måte å autentisere mot en VPN-gateway.

Derfor oppfører verktøyene seg likt når det først finnes en rute. SSMS, DBeaver, Eclipse Data Tools og en vanlig sqlcmd oppfører seg som om serveren er på det lokale nettverket, fordi det sett fra socketens side er den. Den virtuelle adapteren gjorde databasesubnettet tilgjengelig, og driveren vet aldri hvordan.

Det forklarer også hvorfor en tilkoblingsstreng ikke kan reparere en tapt tunnel. Når forbindelsen dør, rapporterer driveren en timeout eller en generell nettverksfeil, og applikasjonskode som behandler det som et spørringsproblem, gjentar den feil laget for alltid.

Reis tunnelen før driveren kjører

Koble til VPN-en på operativsystemnivå, etter instruksjonene fra leverandøren eller nettverksteamet, og åpne først deretter verktøyet. I praksis betyr det at det finnes en rute til databasesubnettet før driveren slår opp vertsnavnet.

Hold tilsynet med tunnelen utenfor applikasjonen. En PHP- eller Java-tjeneste som selv prøver å reise forbindelsen, koder én leverandørs oppførsel inn i forretningskoden, og hver failover blir en applikasjonsutgivelse. En supervisor som eier tunnelen, overvåker den og starter den på nytt, er en egen sak fra spørringsveien.

Sjekk ruten før du gir driveren skylden: hvis vertsnavnet ikke slås opp eller porten ikke svarer fra skallet, endrer ingen tilkoblingsstreng det.

Myte: en Windows-autentiseringsfeil betyr at ruten er brutt

Windows-autentisering over en VPN mislykkes ofte med en feil som ser ut som en nettverksfeil, mens ruten er i orden. Når kontoen tilhører et annet domene og laptopen ikke kan bli med i det, start klienten med eksplisitte påloggingsdetaljer i stedet for identiteten til skrivebordsøkten.

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

/netonly-bryteren beholder disse opplysningene bare for fjernautentisering. Bekreft hva serveren faktisk mottok med SELECT SUSER_SNAME() i stedet for å stole på tilkoblingsdialogen. Det rapporteres at lagring av påloggingsinformasjonen for serveradressen i Windows Credential Manager fungerer for SSMS, men ikke alltid for en tjeneste som kjører under en annen konto, så sjekk hvilken identitet prosessen bruker før du endrer påloggingen.

Forsinkelse gjør en markør på serversiden om til en timeout

En markør på serversiden ber databasen holde resultatet og hente det trinnvis, noe som gjør ett stort resultat om til mange små rundturer. På et LAN er det billig. Over en tunnel med titalls millisekunder ekstra forsinkelse kan den samme spørringen overskride kommandotimeouten uten å overføre særlig mye data.

Bytt til en markør på klientsiden, eller øk hentestørrelsen og batch radene, og antallet rundturer synker. Flaskehalsen er antallet utvekslinger, ikke den nominelle lenkehastigheten, så måling av gjennomstrømning vil villede deg, mens måling av rundturer ikke vil. Test med det største resultatsettet brukerne dine faktisk henter, ikke med en spørring på én rad som kommer tilbake umiddelbart. Hvis timeouten flytter seg men ikke forsvinner, øk kommandotimeouten og hentestørrelsen sammen og mål på nytt.

Den samme aritmetikken gjelder for snakkesalige ORM-er og for enhver klient som sender én setning per rad. Hvis spørringsplanen er god og overføringen liten, tell nettverksutvekslingene før du tuner databasen.

Sjekk porten, instansen og det lokale filteret

En navngitt instans lytter på en dynamisk port, så bekreft porten i stedet for å anta 1433. På en standardinstans kan verdien leses fra TcpPort-registerverdien under instansens SuperSocketNetLib-nøkkel. For Oracle, kontroller at verten i tnsnames.ora slås opp, at adressen svarer og at lytterporten er tillatt; 1521 er en vanlig standardverdi, ikke en garanti.

Utelukk deretter tunnelens egen tilgangsliste og til slutt et lokalt antivirusprogram eller en vertsbrannmur som blokkerer forbindelsen selv når klient og server er samme maskin. Fang stadiet som feiler før du endrer konfigurasjonen, fordi navneoppslag, TCP-tilgjengelighet og TLS eller pålogging hver feiler med en annen melding.

Skriv stadiet i saken. Ellers vil den neste personen gjenta den samme letingen etter tilkoblingsstrengen som startet alt.