Nej, en forbindelsesstreng kan ikke starte din VPN-tunnel

Udviklere bliver ved med at lede efter det sted, hvor en forbindelsesstreng, en JDBC-URL eller en tnsnames.ora-post vælger VPN'en. Der findes ikke et sådant sted. Tunnelen oprettes af styresystemet eller en klient fra en leverandør, som registrerer en virtuel adapter, og hvert databasbibliotek ovenover bruger det socketlag, der følger. En forbindelsesstreng angiver et værtsnavn, en port og en legitimationsoplysning, og det er hele ordforrådet.

Myte: forbindelsesstrengen kan vælge en tunnel

Driveren åbner en TCP-socket til et værtsnavn og en port. Den har ingen API til at rejse en tunnel, intet felt til en tunnelprofil og ingen måde at godkende over for en VPN-gateway.

Derfor opfører værktøjerne sig ens, når der først findes en rute. SSMS, DBeaver, Eclipse Data Tools og en almindelig sqlcmd opfører sig, som om serveren er på det lokale netværk, fordi det set fra socketens side er den. Den virtuelle adapter gjorde databasesubnettet tilgængeligt, og driveren ved aldrig hvordan.

Det forklarer også, hvorfor en forbindelsesstreng ikke kan reparere en tabt tunnel. Når forbindelsen dør, rapporterer driveren en timeout eller en generel netværksfejl, og applikationskode, der behandler det som et forespørgselsproblem, gentager det forkerte lag for evigt.

Rejs tunnelen, før driveren kører

Tilslut VPN'en på styresystemniveau efter udbyderens eller netværksteamets instruktioner, og åbn først derefter værktøjet. I praksis betyder det, at der findes en rute til databasesubnettet, før driveren slår værtsnavnet op.

Hold tilsynet med tunnelen uden for applikationen. En PHP- eller Java-tjeneste, der selv forsøger at rejse forbindelsen, indkoder én udbyders adfærd i forretningskode, og hvert failover bliver en applikationsudgivelse. En supervisor, der ejer tunnelen, overvåger den og genstarter den, er en separat sag fra forespørgselsvejen.

Kontroller ruten, før du bebrejder driveren: hvis værtsnavnet ikke slås op, eller porten ikke svarer fra shellen, ændrer ingen forbindelsesstreng det.

Myte: en Windows-godkendelsesfejl betyder, at ruten er brudt

Windows-godkendelse over en VPN fejler ofte med en fejl, der ligner en netværksfejl, mens ruten er fin. Når kontoen tilhører et andet domæne, og laptop'en ikke kan tilsluttes det, skal du starte klienten med eksplicitte legitimationsoplysninger i stedet for skrivebordssessionens identitet.

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

/netonly-skifteren beholder disse oplysninger kun til fjern godkendelse. Bekræft, hvad serveren faktisk modtog, med SELECT SUSER_SNAME() i stedet for at stole på forbindelsesdialogen. Det siges, at lagring af legitimationsoplysningen til serveradressen i Windows Credential Manager virker til SSMS, men ikke altid til en tjeneste, der kører under en anden konto, så kontroller, hvilken identitet processen bruger, før du ændrer login.

Latenz gør en server-side markør til en timeout

En server-side markør beder databasen holde resultatet og hente det trinvist, hvilket gør ét stort resultat til mange små rundture. På et LAN er det billigt. Over en tunnel med tier af millisekunder ekstra latenstid kan den samme forespørgsel overskride kommandotimeouten uden at overføre ret meget data.

Skift til en klient-side markør, eller øg fetch-størrelsen og batch rækkerne, og antallet af rundture falder. Flaskehalsen er antallet af udvekslinger, ikke den nominelle linkhastighed, så måling af gennemstrømning vil vildlede dig, mens måling af rundture ikke vil. Test med det største resultatsæt, dine brugere faktisk trækker, ikke med en forespørgsel på én række, der vender tilbage med det samme. Hvis timeouten flytter sig men ikke forsvinder, så øg kommandotimeouten og fetch-størrelsen sammen og mål igen.

Den samme aritmetik gælder for snaksomme ORM'er og for enhver klient, der udsteder én sætning per række. Hvis forespørgselsplanen er fin, og overførslen er lille, så tæl netværksudvekslingerne, før du tuner databasen.

Kontroller porten, instansen og det lokale filter

En navngivet instans lytter på en dynamisk port, så bekræft porten i stedet for at antage 1433. På en standardinstans kan værdien læses fra TcpPort-registreringsværdien under instansens SuperSocketNetLib-nøgle. For Oracle skal du kontrollere, at værten i tnsnames.ora slås op, at adressen svarer, og at listener-porten er tilladt; 1521 er en almindelig standard, ikke en garanti.

Udeluk derefter tunnelens egen adgangsliste og til sidst et lokalt antivirusprogram eller en værtsfirewall, der blokerer forbindelsen, selv når klient og server er den samme maskine. Fang det fejlende trin, før du ændrer konfigurationen, fordi navneopslag, TCP-rækkevidde og TLS eller login hver især fejler med en forskellig meddelelse.

Skriv trinnet i billetten. Ellers gentager den næste person den samme søgning efter forbindelsesstrengen, som startede det hele.