Nu, un șir de conexiune nu poate porni tunelul VPN

Dezvoltatorii caută în continuare locul în care un șir de conexiune, un URL JDBC sau o intrare în tnsnames.ora selectează VPN-ul. Acel loc nu există. Tunelul este stabilit de sistemul de operare sau de un client al furnizorului care înregistrează un adaptor virtual, iar fiecare bibliotecă de baze de date de deasupra folosește stratul de socket rezultat. Un șir de conexiune numește un host, un port și o credențială, și acesta este tot vocabularul.

Mit: șirul de conexiune poate selecta un tunel

Driverul deschide un socket TCP către un host și un port. Nu are API pentru ridicarea unui tunel, nici câmp pentru un profil de tunel și nicio modalitate de a se autentifica la un gateway VPN.

De aceea instrumentele se comportă identic odată ce există o rută. SSMS, DBeaver, Eclipse Data Tools și un sqlcmd simplu acționează ca și cum serverul ar fi în rețeaua locală, pentru că din perspectiva socketului chiar este. Adaptorul virtual a făcut subrețeaua bazei de date accesibilă, iar driverul nu știe niciodată cum.

Aceasta explică și de ce un șir de conexiune nu poate repara un tunel căzut. Când legătura moare, driverul raportează un timeout sau o eroare generală de rețea, iar codul aplicației care tratează asta ca pe o problemă de interogare repetă la nesfârșit stratul greșit.

Ridică tunelul înainte ca driverul să ruleze

Conectează VPN-ul la nivel de sistem de operare, urmând instrucțiunile furnizorului sau ale echipei de rețea, și abia apoi deschide instrumentul. În practică, asta înseamnă că există o rută către subrețeaua bazei de date înainte ca driverul să rezolve numele hostului.

Ține supravegherea tunelului în afara aplicației. Un serviciu PHP sau Java care încearcă să ridice singur legătura codifică comportamentul unui furnizor în codul de business, iar fiecare comutare pe eroare devine o versiune a aplicației. Un supraveghetor care deține tunelul, îl urmărește și îl repornește este o chestiune separată de calea interogării.

Verifică ruta înainte de a da vina pe driver: dacă hostul nu se rezolvă sau portul nu răspunde din shell, niciun șir de conexiune nu va schimba asta.

Mit: o eroare de autentificare Windows înseamnă că ruta este stricată

Autentificarea Windows printr-un VPN eșuează adesea cu o eroare care pare o pană de rețea, iar ruta este în regulă. Când contul aparține altui domeniu și laptopul nu se poate alătura acestuia, pornește clientul cu credențiale explicite în locul identității sesiunii de desktop.

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

Comutatorul /netonly păstrează acele credențiale doar pentru autentificarea la distanță. Confirmă ce a primit de fapt serverul cu SELECT SUSER_SNAME() în loc să te bazezi pe dialogul de conexiune. Se raportează că stocarea credențialei pentru adresa serverului în Windows Credential Manager funcționează pentru SSMS, dar nu întotdeauna pentru un serviciu care rulează sub alt cont, așa că verifică ce identitate folosește procesul înainte de a schimba autentificarea.

Latența transformă un cursor pe partea serverului într-un timeout

Un cursor pe partea serverului cere bazei de date să păstreze rezultatul și să îl aducă incremental, ceea ce transformă un rezultat mare în multe dus-întorsuri mici. Într-o rețea locală este ieftin. Printr-un tunel cu zeci de milisecunde de latență suplimentară, aceeași interogare poate depăși timeoutul comenzii fără să transfere aproape nimic.

Treci la un cursor pe partea clientului, sau mărește dimensiunea de preluare și grupează rândurile, iar numărul de dus-întorsuri scade. Gâtul de sticlă este numărul de schimburi, nu viteza nominală a legăturii, așa că măsurarea debitului te va induce în eroare, în timp ce măsurarea dus-întorsurilor nu. Testează cu cel mai mare set de rezultate pe care utilizatorii tăi chiar îl extrag, nu cu o interogare de un rând care se întoarce instantaneu. Dacă timeoutul se mută dar nu dispare, mărește împreună timeoutul comenzii și dimensiunea de preluare și măsoară din nou.

Aceeași aritmetică se aplică și ORM-urilor vorbărețe și oricărui client care emite o instrucțiune pe rând. Dacă planul interogării este bun și transferul mic, numără schimburile de rețea înainte de a regla baza de date.

Verifică portul, instanța și filtrul local

O instanță numită ascultă pe un port dinamic, așa că confirmă portul în loc să presupui 1433. Pe o instanță implicită valoarea poate fi citită din valoarea de registru TcpPort sub cheia SuperSocketNetLib a instanței. Pentru Oracle, verifică dacă hostul din tnsnames.ora se rezolvă, dacă adresa răspunde și dacă portul listenerului este permis; 1521 este o valoare implicită obișnuită, nu o garanție.

Apoi exclude lista de acces a tunelului însuși și, în final, un antivirus local sau un firewall de host care blochează conexiunea chiar și când clientul și serverul sunt aceeași mașină. Notează etapa care eșuează înainte de a schimba configurația, pentru că rezolvarea numelor, accesibilitatea TCP și TLS sau autentificarea eșuează fiecare cu alt mesaj.

Scrie etapa în tichet. Altfel următoarea persoană va repeta aceeași căutare a șirului de conexiune cu care a început totul.