Nie, parametry połączenia nie mogą uruchomić tunelu VPN

Programiści wciąż szukają miejsca, w którym parametry połączenia, adres JDBC lub wpis w tnsnames.ora wybiera VPN. Takiego miejsca nie ma. Tunel zestawia system operacyjny lub klient dostawcy, który rejestruje kartę wirtualną, a każda biblioteka bazy danych ponad nim używa wynikowej warstwy gniazd. Parametry połączenia nazywają host, port i poświadczenie, i to cały słownik.

Mit: parametry połączenia mogą wybrać tunel

Sterownik otwiera gniazdo TCP do hosta i portu. Nie ma API do podnoszenia tunelu, pola na profil tunelu ani sposobu uwierzytelnienia się w bramie VPN.

Dlatego narzędzia zachowują się identycznie, gdy istnieje trasa. SSMS, DBeaver, Eclipse Data Tools i zwykły sqlcmd działają tak, jakby serwer był w sieci lokalnej, bo z punktu widzenia gniazda jest. Karta wirtualna udostępniła podsieć bazy danych, a sterownik nigdy nie wie jak.

To wyjaśnia też, dlaczego parametry połączenia nie naprawią zerwanego tunelu. Gdy łącze umiera, sterownik zgłasza przekroczenie limitu czasu lub ogólny błąd sieci, a kod aplikacji, który traktuje to jako problem zapytania, w kółko powtarza niewłaściwą warstwę.

Postaw tunel, zanim uruchomi się sterownik

Połącz VPN na poziomie systemu operacyjnego, zgodnie z instrukcjami dostawcy lub zespołu sieciowego, i dopiero potem otwórz narzędzie. W praktyce oznacza to, że trasa do podsieci bazy danych istnieje, zanim sterownik rozwiąże nazwę hosta.

Trzymaj nadzór nad tunelem poza aplikacją. Usługa PHP lub Java, która sama próbuje podnieść łącze, wpisuje zachowanie jednego dostawcy w kod biznesowy, a każde przełączenie awaryjne staje się wydaniem aplikacji. Nadzorca, który posiada tunel, obserwuje go i restartuje, to osobna sprawa od ścieżki zapytania.

Sprawdź trasę, zanim obwinisz sterownik: jeśli host się nie rozwiązuje albo port nie odpowiada z powłoki, żadne parametry połączenia tego nie zmienią.

Mit: błąd uwierzytelniania Windows oznacza, że trasa jest zepsuta

Uwierzytelnianie Windows przez VPN często kończy się błędem wyglądającym jak awaria sieci, choć trasa jest w porządku. Gdy konto należy do innej domeny, a laptop nie może do niej dołączyć, uruchom klienta z jawnymi poświadczeniami zamiast tożsamości sesji pulpitu.

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

Przełącznik /netonly zachowuje te poświadczenia tylko do uwierzytelniania zdalnego. Sprawdź, co serwer faktycznie otrzymał, za pomocą SELECT SUSER_SNAME(), zamiast ufać oknu połączenia. Donoszono, że zapisanie poświadczenia dla adresu serwera w Windows Credential Manager działa w SSMS, ale nie zawsze w usłudze działającej na innym koncie, więc przed zmianą logowania sprawdź, jakiej tożsamości używa proces.

Opóźnienie zamienia kursor po stronie serwera w przekroczenie limitu czasu

Kursor po stronie serwera prosi bazę o utrzymanie wyniku i pobieranie go stopniowo, co zamienia jeden duży wynik w wiele małych rund. W sieci lokalnej to tanie. Przez tunel z dziesiątkami milisekund dodatkowego opóźnienia to samo zapytanie może przekroczyć limit czasu polecenia, nie przesyłając prawie żadnych danych.

Przejdź na kursor po stronie klienta albo zwiększ rozmiar pobierania i grupuj wiersze, a liczba rund spadnie. Wąskim gardłem jest liczba wymian, nie nominalna prędkość łącza, więc mierzenie przepustowości cię zmyli, a mierzenie rund nie. Testuj na największym zestawie wyników, jaki użytkownicy naprawdę pobierają, a nie zapytaniem o jeden wiersz, które wraca natychmiast. Jeśli limit czasu się przesuwa, ale nie znika, zwiększ jednocześnie limit czasu polecenia i rozmiar pobierania i zmierz ponownie.

Ta sama arytmetyka dotyczy gadatliwych ORM-ów i każdego klienta, który wysyła jedno polecenie na wiersz. Jeśli plan zapytania jest dobry, a transfer mały, policz wymiany sieciowe, zanim dostroisz bazę.

Sprawdź port, instancję i filtr lokalny

Nazwana instancja nasłuchuje na porcie dynamicznym, więc potwierdź port, zamiast zakładać 1433. W instancji domyślnej wartość można odczytać z wpisu rejestru TcpPort pod kluczem SuperSocketNetLib tej instancji. W przypadku Oracle sprawdź, czy host w tnsnames.ora się rozwiązuje, czy adres odpowiada i czy port nasłuchu jest dozwolony; 1521 to częsta wartość domyślna, nie gwarancja.

Następnie wyklucz własną listę dostępu tunelu i wreszcie lokalny program antywirusowy lub zaporę hosta, która blokuje połączenie nawet gdy klient i serwer to ta sama maszyna. Zapisz etap, który zawodzi, zanim zmienisz konfigurację, bo rozwiązywanie nazw, osiągalność TCP oraz TLS lub logowanie zawodzą każdy z innym komunikatem.

Zapisz etap w zgłoszeniu. Inaczej następna osoba powtórzy te same poszukiwania parametrów połączenia, od których wszystko się zaczęło.