Nee, een verbindingsreeks kan je VPN-tunnel niet starten

Ontwikkelaars blijven zoeken naar de plek waar een verbindingsreeks, een JDBC-URL of een tnsnames.ora-regel de VPN kiest. Die plek bestaat niet. De tunnel wordt opgezet door het besturingssysteem of door een client van een leverancier die een virtuele adapter registreert, en elke databaselibrary daarboven gebruikt de socketlaag die daaruit volgt. Een verbindingsreeks noemt een host, een poort en een referentie, en dat is de hele woordenschat.

Mythe: de verbindingsreeks kan een tunnel kiezen

De driver opent een TCP-socket naar een host en poort. Hij heeft geen API om een tunnel op te zetten, geen veld voor een tunnelprofiel en geen manier om zich bij een VPN-gateway te authenticeren.

Daarom gedragen de gereedschappen zich identiek zodra er een route bestaat. SSMS, DBeaver, Eclipse Data Tools en een gewone sqlcmd doen alsof de server op het lokale netwerk staat, want vanuit de socket gezien is dat zo. De virtuele adapter maakte het databasesubnet bereikbaar, en de driver weet nooit hoe.

Dat verklaart ook waarom een verbindingsreeks een weggevallen tunnel niet kan repareren. Als de verbinding sterft, meldt de driver een time-out of een algemene netwerkfout, en applicatiecode die dat als een queryprobleem ziet, herhaalt voor altijd de verkeerde laag.

Breng de tunnel omhoog voordat de driver draait

Verbind de VPN op het niveau van het besturingssysteem, volgens de instructies van de provider of het netwerkteam, en open pas daarna het gereedschap. In de praktijk betekent dat er een route naar het databasesubnet bestaat voordat de driver de hostnaam omzet.

Houd het toezicht op de tunnel buiten de applicatie. Een PHP- of Javadiens die zelf de verbinding probeert op te zetten, codeert het gedrag van één provider in bedrijfscode, en elke failover wordt een applicatierelease. Een supervisor die de tunnel bezit, hem bewaakt en hem herstart, is een aparte zaak van het querypad.

Controleer de route voordat je de driver de schuld geeft: als de host niet omzet of de poort niet antwoordt vanuit de shell, verandert geen enkele verbindingsreeks dat.

Mythe: een Windows-authenticatiefout betekent dat de route kapot is

Windows-authenticatie over een VPN mislukt vaak met een fout die op een netwerkstoring lijkt, terwijl de route in orde is. Wanneer het account bij een ander domein hoort en de laptop zich daarbij niet kan aansluiten, start de client dan met expliciete referenties in plaats van de identiteit van de desktopsessie.

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

De schakelaar /netonly bewaart die referenties alleen voor authenticatie op afstand. Controleer met SELECT SUSER_SNAME() wat de server werkelijk heeft ontvangen in plaats van de verbindingsdialoog te vertrouwen. Er wordt gemeld dat het opslaan van de referentie voor het serveradres in Windows Credential Manager voor SSMS werkt, maar niet altijd voor een dienst die onder een ander account draait, dus controleer welke identiteit het proces gebruikt voordat je de login wijzigt.

Latentie maakt van een cursor aan de serverkant een time-out

Een cursor aan de serverkant vraagt de database het resultaat vast te houden en het stapsgewijs op te halen, wat één groot resultaat omzet in veel kleine retouren. Op een LAN is dat goedkoop. Over een tunnel met tientallen milliseconden extra latentie kan dezelfde query de time-out van het commando overschrijden zonder veel data over te dragen.

Schakel over op een cursor aan de clientkant, of verhoog de fetchgrootte en batch de rijen, en het aantal retouren daalt. De bottleneck is het aantal uitwisselingen, niet de nominale linksnelheid, dus het meten van doorvoer zal je misleiden terwijl het meten van retouren dat niet doet. Test met de grootste resultatenset die je gebruikers echt ophalen, niet met een query van één rij die meteen terugkomt. Als de time-out verschuift maar niet verdwijnt, verhoog dan de time-out van het commando en de fetchgrootte samen en meet opnieuw.

Dezelfde rekenkunde geldt voor praatgrage ORM's en voor elke client die één statement per rij uitstuurt. Als het queryplan goed is en de overdracht klein, tel dan de netwerkuitwisselingen voordat je de database afstelt.

Controleer de poort, de instantie en het lokale filter

Een benoemde instantie luistert op een dynamische poort, dus bevestig de poort in plaats van 1433 aan te nemen. Op een standaardinstantie kan de waarde worden gelezen uit de TcpPort-registerwaarde onder de SuperSocketNetLib-sleutel van de instantie. Controleer voor Oracle dat de host in tnsnames.ora omzet, dat het adres antwoordt en dat de listenerpoort is toegestaan; 1521 is een gangbare standaard, geen garantie.

Sluit dan de eigen toegangslijst van de tunnel uit en ten slotte een lokale antivirus of hostfirewall die de verbinding blokkeert, zelfs wanneer client en server dezelfde machine zijn. Leg de stap vast die faalt voordat je de configuratie wijzigt, want naamresolutie, TCP-bereikbaarheid en TLS of login falen elk met een andere melding.

Schrijf de stap in het ticket. Anders herhaalt de volgende persoon dezelfde zoektocht naar de verbindingsreeks waarmee alles begon.