Ne, připojovací řetězec váš VPN tunel nespustí

Vývojáři pořád hledají místo, kde připojovací řetězec, JDBC URL nebo záznam v tnsnames.ora vybírá VPN. Takové místo neexistuje. Tunel vytváří operační systém nebo klientský software dodavatele, který zaregistruje virtuální adaptér, a každá databázová knihovna nad ním používá výslednou vrstvu socketů. Připojovací řetězec pojmenovává hostitele, port a přihlašovací údaj, a to je celý slovník.

Mýtus: připojovací řetězec může vybrat tunel

Ovladač otevře TCP socket k hostiteli a portu. Nemá API pro zvednutí tunelu, nemá pole pro profil tunelu a nemá způsob, jak se autentizovat vůči VPN bráně.

Proto se nástroje chovají stejně, jakmile trasa existuje. SSMS, DBeaver, Eclipse Data Tools i obyčejný sqlcmd se chovají, jako by server byl v lokální síti, protože z pohledu socketu je. Virtuální adaptér zpřístupnil databázovou podsíť a ovladač nikdy neví jak.

To také vysvětluje, proč připojovací řetězec nedokáže opravit spadlý tunel. Když spojení zemře, ovladač hlásí timeout nebo obecnou síťovou chybu, a kód aplikace, který to považuje za problém dotazu, donekonečna opakuje špatnou vrstvu.

Zvedněte tunel dřív, než se spustí ovladač

Připojte VPN na úrovni operačního systému podle pokynů poskytovatele nebo síťového týmu a teprve potom otevřete nástroj. V praxi to znamená, že trasa do databázové podsítě existuje dřív, než ovladač přeloží jméno hostitele.

Udržujte dohled nad tunelem mimo aplikaci. Služba v PHP nebo Javě, která se sama snaží zvednout spojení, zapisuje chování jednoho poskytovatele do byznys kódu a každý failover se stává vydáním aplikace. Dohled, který tunel vlastní, sleduje ho a restartuje, je oddělená záležitost od cesty dotazu.

Zkontrolujte trasu, než obviníte ovladač: pokud se hostitel nepřeloží nebo port z shellu neodpovídá, žádný připojovací řetězec to nezmění.

Mýtus: selhání ověřování Windows znamená rozbitou trasu

Ověřování Windows přes VPN často selhává s chybou, která vypadá jako síťová závada, a trasa je v pořádku. Když účet patří jiné doméně a notebook se k ní nemůže připojit, spusťte klienta s explicitními přihlašovacími údaji místo identity relace na ploše.

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

Přepínač /netonly uchovává tyto údaje pouze pro vzdálené ověřování. Ověřte, co server skutečně dostal, pomocí SELECT SUSER_SNAME(), místo abyste věřili dialogu připojení. Uvádí se, že uložení údajů pro adresu serveru ve Windows Credential Manager funguje pro SSMS, ale ne vždy pro službu běžící pod jiným účtem, proto před změnou přihlášení zkontrolujte, jakou identitu proces používá.

Latence promění serverový kurzor v timeout

Serverový kurzor žádá databázi, aby výsledek držela a vydávala ho postupně, což jeden velký výsledek mění na mnoho malých obrátek. V lokální síti je to levné. Přes tunel s desítkami milisekund přidané latence může stejný dotaz překročit timeout příkazu, aniž by přenesl téměř žádná data.

Přejděte na klientský kurzor, nebo zvyšte velikost načítání a dávkujte řádky, a počet obrátek klesne. Úzké hrdlo je počet výměn, ne nominální rychlost spoje, takže měření propustnosti vás zmýlí, zatímco měření obrátek ne. Testujte s největší sadou výsledků, kterou uživatelé skutečně táhnou, ne s dotazem na jeden řádek, který se vrátí okamžitě. Pokud se timeout posouvá, ale nemizí, zvyšte timeout příkazu i velikost načítání současně a měřte znovu.

Stejná aritmetika platí pro upovídané ORM a pro každého klienta, který vydává jeden příkaz na řádek. Pokud je plán dotazu dobrý a přenos malý, spočítejte síťové výměny, než začnete ladit databázi.

Zkontrolujte port, instanci a místní filtr

Pojmenovaná instance naslouchá na dynamickém portu, takže port ověřte, místo abyste předpokládali 1433. U výchozí instance lze hodnotu přečíst z registru TcpPort pod klíčem SuperSocketNetLib dané instance. U Oracle ověřte, že se hostitel v tnsnames.ora přeloží, že adresa odpovídá a že port listeneru je povolen; 1521 je běžný výchozí údaj, ne záruka.

Potom vylučte vlastní přístupový seznam tunelu a nakonec místní antivirus nebo hostitelský firewall, který spojení blokuje, i když klient a server jsou na stejném stroji. Zachyťte selhávající fázi, než změníte konfiguraci, protože překlad jmen, dostupnost TCP a TLS nebo přihlášení selhávají každé jinou zprávou.

Zapište fázi do tiketu. Jinak další člověk zopakuje stejné hledání připojovacího řetězce, kterým to všechno začalo.