Nie, pripájací reťazec nemôže spustiť váš VPN tunel
VPN vlastní operačný systém alebo klient, nikdy nie ovládač. Najprv zdvihnite tunel, odovzdajte doménové prihlasovacie údaje cez netonly a potom skontrolujte obrátky kurzora.
Vývojári stále hľadajú miesto, kde pripájací reťazec, JDBC URL alebo záznam v tnsnames.ora vyberá VPN. Také miesto neexistuje. Tunel vytvára operačný systém alebo klientsky softvér dodávateľa, ktorý zaregistruje virtuálny adaptér, a každá databázová knižnica nad ním používa výslednú vrstvu socketov. Pripájací reťazec pomenúva hostiteľa, port a prihlasovací údaj, a to je celý slovník.
Mýtus: pripájací reťazec môže vybrať tunel
Ovládač otvorí TCP socket k hostiteľovi a portu. Nemá API na zdvihnutie tunela, nemá pole pre profil tunela a nemá spôsob, ako sa autentifikovať voči VPN bráne.
Preto sa nástroje správajú rovnako, len čo trasa existuje. SSMS, DBeaver, Eclipse Data Tools aj obyčajný sqlcmd sa chovajú, akoby server bol v lokálnej sieti, pretože z pohľadu socketu je. Virtuálny adaptér sprístupnil databázovú podsieť a ovládač nikdy nevie ako.
To tiež vysvetľuje, prečo pripájací reťazec nedokáže opraviť spadnutý tunel. Keď spojenie zomrie, ovládač hlási timeout alebo všeobecnú sieťovú chybu, a kód aplikácie, ktorý to považuje za problém dopytu, donekonečna opakuje nesprávnu vrstvu.
Zdvihnite tunel skôr, než sa spustí ovládač
Pripojte VPN na úrovni operačného systému podľa pokynov poskytovateľa alebo sieťového tímu a až potom otvorte nástroj. V praxi to znamená, že trasa do databázovej podsiete existuje skôr, než ovládač preloží názov hostiteľa.
Udržujte dohľad nad tunelom mimo aplikácie. Služba v PHP alebo Jave, ktorá sa sama snaží zdvihnúť spojenie, zapisuje správanie jedného poskytovateľa do biznis kódu a každé prepnutie pri zlyhaní sa stáva vydaním aplikácie. Dohľad, ktorý tunel vlastní, sleduje ho a reštartuje, je oddelená záležitosť od cesty dopytu.
Skontrolujte trasu, skôr než obviníte ovládač: ak sa hostiteľ nepreloží alebo port zo shellu neodpovedá, žiadny pripájací reťazec to nezmení.
Mýtus: zlyhanie overovania Windows znamená, že trasa je pokazená
Overovanie Windows cez VPN často zlyháva s chybou, ktorá vyzerá ako sieťová porucha, a trasa je v poriadku. Keď účet patrí inej doméne a notebook sa k nej nemôže pripojiť, spustite klienta s explicitnými prihlasovacími údajmi namiesto identity relácie na ploche.
runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"Prepínač /netonly uchováva tieto údaje iba pre vzdialené overovanie. Overte, čo server skutočne dostal, pomocou SELECT SUSER_SNAME(), namiesto toho, aby ste dôverovali dialógu pripojenia. Uvádza sa, že uloženie údajov pre adresu servera v Windows Credential Manager funguje pre SSMS, ale nie vždy pre službu bežiacu pod iným účtom, preto pred zmenou prihlásenia skontrolujte, akú identitu proces používa.
Latencia premení serverový kurzor na timeout
Serverový kurzor žiada databázu, aby výsledok držala a vydávala ho postupne, čo jeden veľký výsledok mení na mnoho malých obrátok. V lokálnej sieti je to lacné. Cez tunel s desiatkami milisekúnd pridanej latencie môže ten istý dopyt prekročiť timeout príkazu bez toho, aby preniesol takmer žiadne dáta.
Prejdite na klientský kurzor alebo zvýšte veľkosť načítania a dávkujte riadky, a počet obrátok klesne. Úzke hrdlo je počet výmen, nie nominálna rýchlosť spoja, takže meranie priepustnosti vás pomýli, kým meranie obrátok nie. Testujte s najväčšou sadou výsledkov, ktorú používatelia skutočne ťahajú, nie s dopytom na jeden riadok, ktorý sa vráti okamžite. Ak sa timeout posúva, ale nemizne, zvýšte súčasne timeout príkazu aj veľkosť načítania a merajte znova.
Rovnaká aritmetika platí pre ukecané ORM a pre každého klienta, ktorý vydáva jeden príkaz na riadok. Ak je plán dopytu dobrý a prenos malý, spočítajte sieťové výmeny, skôr než začnete ladiť databázu.
Skontrolujte port, inštanciu a lokálny filter
Pomenovaná inštancia počúva na dynamickom porte, preto port overte, namiesto toho, aby ste predpokladali 1433. Pri predvolenej inštancii sa hodnota dá prečítať z registračnej hodnoty TcpPort pod kľúčom SuperSocketNetLib danej inštancie. Pri Oracle overte, že sa hostiteľ v tnsnames.ora preloží, že adresa odpovedá a že port listenera je povolený; 1521 je bežná predvolená hodnota, nie záruka.
Potom vylúčte vlastný zoznam prístupu tunela a nakoniec lokálny antivírus alebo hostiteľský firewall, ktorý spojenie blokuje, aj keď sú klient a server na tom istom stroji. Zachyťte zlyhávajúcu fázu, skôr než zmeníte konfiguráciu, pretože preklad názvov, dostupnosť TCP a TLS alebo prihlásenie zlyhávajú každé s inou správou.
Zapíšte fázu do tiketu. Inak ďalší človek zopakuje to isté hľadanie pripájacieho reťazca, ktorým sa všetko začalo.