Jo, një varg lidhjeje nuk mund të nisë tunelin tuaj VPN

Zhvilluesit vazhdojnë të kërkojnë vendin ku një varg lidhjeje, një URL JDBC ose një zë në tnsnames.ora zgjedh VPN-në. Një vend i tillë nuk ekziston. Tunelin e vendos sistemi operativ ose një klient i furnizorit që regjistron një përshtatës virtual, dhe çdo bibliotekë e bazës së të dhënave mbi të përdor shtresën e socket-it që rezulton. Një varg lidhjeje emërton një host, një port dhe një kredencial, dhe ky është i gjithë fjalori.

Miti: vargu i lidhjes mund të zgjedhë një tunel

Drejtuesi hap një socket TCP drejt një hosti dhe një porti. Nuk ka API për të ngritur një tunel, nuk ka fushë për një profil tuneli dhe nuk ka mënyrë për t'u vërtetuar në një portë VPN.

Prandaj mjetet sillen njësoj sapo ekziston një rrugë. SSMS, DBeaver, Eclipse Data Tools dhe një sqlcmd i thjeshtë veprojnë sikur serveri të ishte në rrjetin lokal, sepse nga këndvështrimi i socket-it është. Përshtatësi virtual e bëri nënrrjetin e bazës së të dhënave të arritshëm, dhe drejtuesi nuk e di kurrë se si.

Kjo shpjegon gjithashtu pse një varg lidhjeje nuk mund të riparojë një tunel të rënë. Kur lidhja vdes, drejtuesi raporton një skadim kohe ose një gabim të përgjithshëm rrjeti, dhe kodi i aplikacionit që e trajton këtë si problem kërkese përsërit përgjithmonë shtresën e gabuar.

Ngrini tunelin përpara se të ekzekutohet drejtuesi

Lidhni VPN-në në nivelin e sistemit operativ, duke ndjekur udhëzimet e ofruesit ose të ekipit të rrjetit, dhe vetëm pastaj hapni mjetin. Në praktikë kjo do të thotë se ekziston një rrugë drejt nënrrjetit të bazës së të dhënave përpara se drejtuesi të zgjidhë emrin e hostit.

Mbajeni mbikëqyrjen e tunelit jashtë aplikacionit. Një shërbim PHP ose Java që përpiqet të ngrejë vetë lidhjen kodon sjelljen e një ofruesi në kodin e biznesit, dhe çdo kalim dështimi bëhet një version i aplikacionit. Një mbikëqyrës që zotëron tunelin, e vëzhgon dhe e rinis është çështje e veçantë nga rruga e kërkesës.

Kontrolloni rrugën përpara se të fajësoni drejtuesin: nëse hosti nuk zgjidhet ose porti nuk përgjigjet nga shelli, asnjë varg lidhjeje nuk do ta ndryshojë atë.

Miti: një dështim vërtetimi i Windows do të thotë që rruga është thyer

Vërtetimi i Windows përmes një VPN shpesh dështon me një gabim që duket si defekt rrjeti, ndërsa rruga është në rregull. Kur llogaria i përket një domeni tjetër dhe laptopi nuk mund t'i bashkohet, nisni klientin me kredenciale të qarta në vend të identitetit të sesionit të desktopit.

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

Ndërprerësi /netonly i ruan ato kredenciale vetëm për vërtetim në distancë. Konfirmoni çfarë mori vërtet serveri me SELECT SUSER_SNAME() në vend që t'i besoni dialogut të lidhjes. Raportohet se ruajtja e kredencialit për adresën e serverit në Windows Credential Manager funksionon për SSMS, por jo gjithmonë për një shërbim që ekzekutohet nën një llogari tjetër, prandaj kontrolloni cilin identitet përdor procesi përpara se të ndryshoni hyrjen.

Vonesa e kthen një kursor në anën e serverit në skadim kohe

Një kursor në anën e serverit i kërkon bazës së të dhënave ta mbajë rezultatin dhe ta sjellë gradualisht, gjë që e kthen një rezultat të madh në shumë udhëtime të vogla vajtje-ardhje. Në një LAN kjo është e lirë. Përmes një tuneli me dhjetëra milisekonda vonesë shtesë, e njëjta kërkesë mund të kalojë skadimin e kohës së komandës pa transferuar pothuajse asgjë.

Kaloni në një kursor në anën e klientit, ose rrisni madhësinë e marrjes dhe gruponi rreshtat, dhe numri i udhëtimeve bie. Pengesa është numri i shkëmbimeve, jo shpejtësia nominale e lidhjes, prandaj matja e xhiros do t'ju mashtrojë, ndërsa matja e udhëtimeve nuk do të mashtrojë. Provoni me grupin më të madh të rezultateve që përdoruesit tuaj nxjerrin vërtet, jo me një kërkesë prej një rreshti që kthehet menjëherë. Nëse skadimi i kohës lëviz por nuk zhduket, rrisni së bashku skadimin e kohës së komandës dhe madhësinë e marrjes dhe matni përsëri.

E njëjta aritmetikë vlen për ORM-të llafazane dhe për çdo klient që lëshon një deklaratë për rresht. Nëse plani i kërkesës është i mirë dhe transferimi i vogël, numëroni shkëmbimet e rrjetit përpara se të akordoni bazën e të dhënave.

Kontrolloni portin, instancën dhe filtrin lokal

Një instancë e emërtuar dëgjon në një port dinamik, prandaj konfirmoni portin në vend që të supozoni 1433. Në një instancë të parazgjedhur vlera mund të lexohet nga vlera e regjistrit TcpPort nën çelësin SuperSocketNetLib të instancës. Për Oracle, verifikoni se hosti në tnsnames.ora zgjidhet, se adresa përgjigjet dhe se porti i dëgjuesit lejohet; 1521 është një parazgjedhje e zakonshme, jo një garanci.

Pastaj përjashtoni listën e aksesit të vetë tunelit dhe, së fundi, një antivirus lokal ose një firewall hosti që bllokon lidhjen edhe kur klienti dhe serveri janë i njëjti makinë. Regjistroni fazën që dështon përpara se të ndryshoni konfigurimin, sepse zgjidhja e emrave, arritshmëria TCP dhe TLS ose hyrja dështojnë secila me një mesazh të ndryshëm.

Shkruani fazën në tiketë. Përndryshe personi tjetër do të përsëritë të njëjtën kërkim të vargut të lidhjes me të cilin filloi gjithçka.