Nej, en anslutningssträng kan inte starta din VPN-tunnel

Utvecklare letar fortfarande efter platsen där en anslutningssträng, en JDBC-URL eller en tnsnames.ora-post väljer VPN:en. Någon sådan plats finns inte. Tunneln upprättas av operativsystemet eller av en leverantörsklient som registrerar en virtuell adapter, och varje databasbibliotek ovanpå använder det socketlager som blir resultatet. En anslutningssträng namnger en värd, en port och en inloggningsuppgift, och det är hela vokabulären.

Myt: anslutningssträngen kan välja en tunnel

Drivrutinen öppnar en TCP-socket mot en värd och en port. Den har inget API för att resa en tunnel, inget fält för en tunnelprofil och inget sätt att autentisera mot en VPN-gateway.

Därför beter sig verktygen likadant när det väl finns en rutt. SSMS, DBeaver, Eclipse Data Tools och en vanlig sqlcmd beter sig som om servern låg på det lokala nätet, eftersom det ur socketens synvinkel gör det. Den virtuella adaptern gjorde databassubnätet nåbart, och drivrutinen vet aldrig hur.

Det förklarar också varför en anslutningssträng inte kan reparera en tappad tunnel. När länken dör rapporterar drivrutinen en timeout eller ett allmänt nätverksfel, och applikationskod som behandlar det som ett frågeproblem upprepar fel lager för alltid.

Res tunneln innan drivrutinen körs

Anslut VPN:en på operativsystemsnivå, enligt leverantörens eller nätverksteamets instruktioner, och öppna först därefter verktyget. I praktiken betyder det att det finns en rutt till databassubnätet innan drivrutinen löser upp värdnamnet.

Håll tillsynen över tunneln utanför applikationen. En PHP- eller Javatjänst som själv försöker resa länken kodar in en leverantörs beteende i affärskoden, och varje failover blir en applikationsutgåva. En övervakare som äger tunneln, bevakar den och startar om den är en separat sak från frågevägen.

Kontrollera rutten innan du skyller på drivrutinen: om värden inte löses upp eller porten inte svarar från skalet ändrar ingen anslutningssträng det.

Myt: ett Windows-autentiseringsfel betyder att rutten är trasig

Windows-autentisering över en VPN misslyckas ofta med ett fel som ser ut som ett nätverksfel, medan rutten är i ordning. När kontot tillhör en annan domän och laptopen inte kan ansluta till den, starta klienten med explicita uppgifter i stället för skrivbordssessionens identitet.

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

/netonly-växeln behåller dessa uppgifter endast för fjärrautentisering. Bekräfta vad servern faktiskt tog emot med SELECT SUSER_SNAME() i stället för att lita på anslutningsdialogen. Det rapporteras att lagring av inloggningsuppgiften för serveradressen i Windows Credential Manager fungerar för SSMS men inte alltid för en tjänst som körs under ett annat konto, så kontrollera vilken identitet processen använder innan du ändrar inloggningen.

Latens gör en markör på serversidan till en timeout

En markör på serversidan ber databasen hålla resultatet och hämta det stegvis, vilket gör ett stort resultat till många små rundturer. På ett LAN är det billigt. Över en tunnel med tiotals millisekunder extra latens kan samma fråga överskrida kommandots timeout utan att överföra särskilt mycket data.

Byt till en markör på klientsidan, eller höj hämtningsstorleken och gruppera raderna, och antalet rundturer sjunker. Flaskhalsen är antalet utbyten, inte länkens nominella hastighet, så mätning av genomströmning vilseleder dig medan mätning av rundturer inte gör det. Testa med den största resultatmängd som dina användare faktiskt hämtar, inte med en fråga på en rad som kommer tillbaka direkt. Om timeouten flyttar sig men inte försvinner, höj kommandots timeout och hämtningsstorleken tillsammans och mät igen.

Samma aritmetik gäller för pratsamma ORM:er och för varje klient som utfärdar ett statement per rad. Om frågeplanen är bra och överföringen liten, räkna nätverksutbytena innan du justerar databasen.

Kontrollera porten, instansen och det lokala filtret

En namngiven instans lyssnar på en dynamisk port, så bekräfta porten i stället för att anta 1433. På en standardinstans kan värdet läsas från TcpPort-registervärdet under instansens SuperSocketNetLib-nyckel. För Oracle, kontrollera att värden i tnsnames.ora löses upp, att adressen svarar och att lyssnarporten är tillåten; 1521 är en vanlig standard, inte en garanti.

Uteslut sedan tunnelns egen åtkomstlista och till sist ett lokalt antivirusprogram eller en värdbrandvägg som blockerar anslutningen även när klient och server är samma maskin. Fånga steget som misslyckas innan du ändrar konfigurationen, eftersom namnmatchning, TCP-nåbarhet och TLS eller inloggning misslyckas var och en med ett annat meddelande.

Skriv steget i ärendet. Annars upprepar nästa person samma sökning efter anslutningssträngen som startade allt.