Ei, ühendusstring ei saa teie VPN-tunnelit käivitada
VPN kuulub operatsioonisüsteemile või kliendile, mitte kunagi draiverile. Tõstke esmalt tunnel, edastage domeeni mandaadid netonly abil ja kontrollige seejärel kursori edasi-tagasi käike.
Arendajad otsivad ikka veel kohta, kus ühendusstring, JDBC URL või tnsnames.ora kirje valib VPN-i. Sellist kohta ei ole. Tunneli loob operatsioonisüsteem või tarnija klient, mis registreerib virtuaalse adapteri, ja iga andmebaasiteek selle kohal kasutab sellest tulenevat soketi kihti. Ühendusstring nimetab hosti, porti ja mandaati, ja see ongi kogu sõnavara.
Müüt: ühendusstring saab tunneli valida
Draiver avab TCP-soketi hosti ja pordi suunas. Tal pole API-t tunneli tõstmiseks, pole välja tunneli profiili jaoks ja pole võimalust VPN-lüüsile autentida.
Seetõttu käituvad tööriistad ühtemoodi, kui marsruut on olemas. SSMS, DBeaver, Eclipse Data Tools ja tavaline sqlcmd käituvad nii, nagu oleks server kohalikus võrgus, sest soketi vaatepunktist ongi. Virtuaalne adapter tegi andmebaasi alavõrgu kättesaadavaks ja draiver ei tea kunagi, kuidas.
See selgitab ka, miks ühendusstring ei saa katkenud tunnelit parandada. Kui link sureb, teatab draiver ajutõusust või üldisest võrguveast, ja rakenduse kood, mis käsitleb seda päringu probleemina, kordab igavesti vale kihti.
Tõstke tunnel enne, kui draiver käivitub
Ühendage VPN operatsioonisüsteemi tasandil, järgides teenusepakkuja või võrgumeeskonna juhiseid, ja alles siis avage tööriist. Praktikas tähendab see, et marsruut andmebaasi alavõrku on olemas enne, kui draiver hostinime lahendab.
Hoidke tunneli järelevalve rakendusest väljas. PHP või Java teenus, mis üritab lingi ise tõsta, kodeerib ühe pakkuja käitumise äriloogikasse ja igast ümberlülitusest saab rakenduse väljaanne. Supervisor, mis tunnelit omab, seda jälgib ja taaskäivitab, on päringu teest eraldi küsimus.
Kontrollige marsruuti enne, kui draiverit süüdistate: kui host ei lahene või port ei vasta kestast, ei muuda seda ükski ühendusstring.
Müüt: Windowsi autentimise viga tähendab, et marsruut on katki
Windowsi autentimine VPN-i kaudu ebaõnnestub sageli veaga, mis näeb välja nagu võrgu rike, kuigi marsruut on korras. Kui konto kuulub teise domeeni ja sülearvuti ei saa sellega liituda, käivitage klient selgete mandaatidega, mitte töölaua sessiooni identiteediga.
runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"/netonly lüliti hoiab neid mandaate ainult kaugautentimise jaoks. Kontrollige SELECT SUSER_SNAME() abil, mida server tegelikult sai, selle asemel et usaldada ühenduse dialoogi. Väidetakse, et serveri aadressi mandaadi hoidmine Windows Credential Manageris töötab SSMS-i puhul, kuid mitte alati teise konto all töötava teenuse puhul, seega kontrollige enne sisselogimise muutmist, millist identiteeti protsess kasutab.
Latentsus muudab serveripoolse kursori ajutõusuks
Serveripoolne kursori palub andmebaasil tulemust hoida ja seda järk-järgult tuua, mis muudab ühe suure tulemuse paljudeks väikesteks edasi-tagasi käikudeks. Kohtvõrgus on see odav. Tunnelist, millel on kümneid millisekundeid lisalatentsust, võib sama päring ületada käsu ajutõusu, ilma et andmeid peaaegu üldse liigutataks.
Lülituge kliendipoolsele kursori peale või suurendage toomise suurust ja rühmitage read, ja edasi-tagasi käikude arv langeb. Kitsaskoht on vahetuste arv, mitte lingi nominaalne kiirus, nii et läbilaskevõime mõõtmine eksitab teid, edasi-tagasi käikude mõõtmine mitte. Testige suurima tulemusehulgaga, mida teie kasutajad tegelikult tõmbavad, mitte üherealise päringuga, mis naaseb kohe. Kui ajutõus liigub, kuid ei kao, suurendage korraga käsu ajutõusu ja toomise suurust ning mõõtke uuesti.
Sama aritmeetika kehtib jutukate ORM-ide ja iga kliendi kohta, mis väljastab ühe lause rea kohta. Kui päringu plaan on korras ja ülekanne väike, loendage võrguvahetused enne andmebaasi häälestamist.
Kontrollige porti, eksemplari ja kohalikku filtrit
Nimega eksemplar kuulab dünaamilisel pordil, seega kinnitage port, mitte ärge eeldage 1433. Vaikeeksemplari puhul saab väärtuse lugeda TcpPort registriväärtusest eksemplari SuperSocketNetLib võtme all. Oracle'i puhul kontrollige, et tnsnames.ora host laheneb, et aadress vastab ja et kuulaja port on lubatud; 1521 on tavaline vaikeväärtus, mitte garantii.
Seejärel välistage tunneli enda juurdepääsuloend ja lõpuks kohalik viirusetõrje või hosti tulemüür, mis blokeerib ühenduse ka siis, kui klient ja server on samas masinas. Jäädvustage nurjuv etapp enne konfiguratsiooni muutmist, sest nime lahendamine, TCP kättesaadavus ning TLS või sisselogimine ebaõnnestuvad igaüks erineva sõnumiga.
Kirjutage etapp piletisse. Muidu kordab järgmine inimene sama ühendusstringi otsingut, millega kõik algas.