Ne, prisijungimo eilutė negali paleisti jūsų VPN tunelio

Kūrėjai vis dar ieško vietos, kurioje prisijungimo eilutė, JDBC URL arba tnsnames.ora įrašas pasirenka VPN. Tokios vietos nėra. Tunelį sukuria operacinė sistema arba tiekėjo klientas, kuris užregistruoja virtualų adapterį, o kiekviena duomenų bazės biblioteka virš jo naudoja atsiradusį lizdo sluoksnį. Prisijungimo eilutė įvardija mazgą, prievadą ir prisijungimo duomenis, ir tai yra visas žodynas.

Mitas: prisijungimo eilutė gali pasirinkti tunelį

Tvarkyklė atidaro TCP lizdą į mazgą ir prievadą. Ji neturi API tuneliui pakelti, neturi lauko tunelio profiliui ir neturi būdo autentifikuotis VPN tinklų sietuvui.

Štai kodėl įrankiai elgiasi vienodai, kai maršrutas egzistuoja. SSMS, DBeaver, Eclipse Data Tools ir paprastas sqlcmd elgiasi taip, tarsi serveris būtų vietiniame tinkle, nes lizdo požiūriu taip ir yra. Virtualus adapteris padarė duomenų bazės potinklį pasiekiamą, o tvarkyklė niekada nežino kaip.

Tai paaiškina ir kodėl prisijungimo eilutė negali sutaisyti nutrūkusio tunelio. Kai ryšys miršta, tvarkyklė praneša apie laukimo pabaigą arba bendrą tinklo klaidą, o programos kodas, kuris tai laiko užklausos problema, amžinai kartoja ne tą sluoksnį.

Pakelkite tunelį prieš paleisdami tvarkyklę

Prisijunkite prie VPN operacinės sistemos lygmeniu, vadovaudamiesi tiekėjo arba tinklo komandos nurodymais, ir tik tada atidarykite įrankį. Praktiškai tai reiškia, kad maršrutas į duomenų bazės potinklį egzistuoja prieš tvarkyklei išsprendžiant mazgo vardą.

Laikykite tunelio priežiūrą už programos ribų. PHP arba Java paslauga, kuri pati bando pakelti ryšį, į verslo kodą įrašo vieno tiekėjo elgseną, ir kiekvienas perjungimas gedimo atveju tampa programos leidimu. Prižiūrėtojas, kuris valdo tunelį, jį stebi ir paleidžia iš naujo, yra atskiras klausimas nuo užklausos kelio.

Patikrinkite maršrutą prieš kaltindami tvarkyklę: jei mazgas neišsprendžiamas arba prievadas neatsako iš apvalkalo, jokia prisijungimo eilutė to nepakeis.

Mitas: Windows autentifikavimo klaida reiškia, kad maršrutas sulaužytas

Windows autentifikavimas per VPN dažnai nepavyksta su klaida, kuri atrodo kaip tinklo gedimas, o maršrutas yra tvarkingas. Kai paskyra priklauso kitam domenui ir nešiojamasis kompiuteris negali prie jo prisijungti, paleiskite klientą su aiškiais prisijungimo duomenimis, o ne su darbalaukio sesijos tapatybe.

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

/netonly jungiklis saugo tuos duomenis tik nuotoliniam autentifikavimui. Patikrinkite, ką serveris iš tikrųjų gavo, naudodami SELECT SUSER_SNAME(), o ne pasitikėdami prisijungimo dialogu. Pranešama, kad serverio adreso prisijungimo duomenų saugojimas Windows Credential Manager veikia SSMS, bet ne visada paslaugai, veikiančiai pagal kitą paskyrą, todėl prieš keisdami prisijungimą patikrinkite, kokią tapatybę naudoja procesas.

Vėlinimas paverčia serverio pusės žymeklį laukimo pabaiga

Serverio pusės žymeklis prašo duomenų bazės laikyti rezultatą ir jį palaipsniui atsisiųsti, o tai vieną didelį rezultatą paverčia daugybe mažų kelionių pirmyn ir atgal. Vietiniame tinkle tai pigu. Per tunelį su dešimtimis milisekundžių papildomo vėlinimo ta pati užklausa gali viršyti komandos laukimo ribą beveik neperdavusi duomenų.

Pereikite prie kliento pusės žymeklio arba padidinkite gavimo dydį ir sugrupuokite eilutes, ir kelionių pirmyn ir atgal skaičius sumažės. Siaura vieta yra apsikeitimų skaičius, o ne nominalus ryšio greitis, todėl pralaidumo matavimas jus suklaidins, o kelionių matavimas ne. Testuokite su didžiausiu rezultatų rinkiniu, kurį jūsų naudotojai tikrai traukia, o ne su vienos eilutės užklausa, kuri grįžta akimirksniu. Jei laukimo riba pasislenka, bet neišnyksta, padidinkite komandos laukimo ribą ir gavimo dydį kartu ir matuokite dar kartą.

Ta pati aritmetika galioja kalbiems ORM ir bet kuriam klientui, kuris išduoda vieną sakinį vienai eilutei. Jei užklausos planas geras, o perdavimas mažas, suskaičiuokite tinklo apsikeitimus prieš derindami duomenų bazę.

Patikrinkite prievadą, egzempliorių ir vietinį filtrą

Pavadintas egzempliorius klausosi dinaminio prievado, todėl patvirtinkite prievadą, o ne manykite 1433. Numatytojo egzemplioriaus atveju reikšmę galima perskaityti iš TcpPort registro reikšmės po egzemplioriaus SuperSocketNetLib raktu. Oracle atveju patikrinkite, ar tnsnames.ora mazgas išsprendžiamas, ar adresas atsako ir ar klausytojo prievadas leidžiamas; 1521 yra įprasta numatytoji reikšmė, o ne garantija.

Tada atmeskite paties tunelio prieigos sąrašą ir galiausiai vietinį antivirusą arba mazgo užkardą, kuri blokuoja ryšį net kai klientas ir serveris yra tame pačiame kompiuteryje. Užfiksuokite nepavykstantį etapą prieš keisdami konfigūraciją, nes vardų sprendimas, TCP pasiekiamumas ir TLS arba prisijungimas kiekvienas nepavyksta su skirtingu pranešimu.

Įrašykite etapą į bilietą. Priešingu atveju kitas žmogus pakartos tą pačią prisijungimo eilutės paiešką, nuo kurios viskas prasidėjo.