Nazwana instancja SQL Server przez VPN: wykrywanie, a nie port 1433

Większość ludzi traktuje nazwę hosta SQL Server jako pełny adres, a VPN jako coś, co jest albo dozwolone, albo nie. W praktyce nazwana instancja zmusza klienta do wykonania drugiego zapytania po DNS, i właśnie to zapytanie tunel najczęściej psuje. Jawny punkt końcowy to omija, dlatego tcp:host,port może działać, podczas gdy host\INSTANCE kończy się przekroczeniem czasu. Różnica leży między znalezieniem usługi a uzyskaniem pozwolenia na jej użycie.

Mit: jedna nazwa hosta oznacza jeden port

Nazwa hosta jest rozwiązywana na adres i tam kończy się jej zadanie. Nazwana instancja dodaje nazwę instancji, którą serwer musi przetłumaczyć na port TCP, a klient nie może jej odgadnąć. Port 1433 jest domyślny dla instancji domyślnej, a nie właściwością każdej instancji na maszynie. Traktowanie obu jako tego samego daje klasyczny objaw: ping działa, DNS działa, skan 1433 nic nie pokazuje, a wniosek jest taki, że sieć blokuje SQL.

Drugie założenie zawodzi tak samo: że otwarcie TCP 1433 wystarczy. Jeśli instancja nasłuchuje gdzie indziej, otwarty 1433 dowodzi tylko, że jest tam coś innego. Port musi pasować do nasłuchującego, a że nasłuchujący to szczegół konfiguracji po stronie serwera o to trzeba zapytać, a nie zgadywać.

Co klient naprawdę robi z nazwaną instancją

Po rozwiązaniu hosta klient wysyła żądanie wykrywania do SQL Server Browser przez UDP 1434 i pyta, którego portu używa nazwana instancja. Usługa przeglądarki odpowiada z rejestru samego serwera, a następnie klient otwiera połączenie TCP do tego portu. Dwa protokoły i dwa porty są zaangażowane, zanim w ogóle zostanie podjęta próba logowania.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Dlatego blokada tylko UDP daje przekroczenie czasu, które wygląda jak martwy host. Jeśli usługa przeglądarki jest zatrzymana lub wyłączona, żądanie wykrywania pozostaje bez odpowiedzi, mimo że silnik bazy danych działa i jego port TCP jest otwarty. Jeśli instancja jest skonfigurowana ze statycznym portem, klient nadal pyta, chyba że podano mu punkt końcowy bezpośrednio. Każdy z tych błędów wygląda w komunikacie błędu aplikacji tak samo, a wymagają różnych poprawek.

Usługa przeglądarki to udogodnienie wykrywania, nie baza danych. Jej zatrzymanie nie zatrzymuje silnika, a jej uruchomienie nie otwiera portu TCP instancji.

Dlaczego jawny punkt końcowy działa, gdy nazwa nie działa

Jawny punkt końcowy usuwa zapytanie z sekwencji: klient łączy się bezpośrednio z podanym adresem i portem. To najpierw diagnostyka, a nie automatycznie trwałe rozwiązanie, ponieważ port może się zmienić, jeśli instancja zostanie później przekonfigurowana na dynamiczny. Porównaj obie formy z tym samym klientem i tym samym kontem, zanim wyciągniesz wnioski.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Jeśli forma jawna się udaje, a nazwana zawodzi, luką jest wykrywanie i możesz wybrać, jak ją zamknąć: zezwolić na UDP 1434 przez tunel albo poprosić administratora o przypięcie statycznego portu i udokumentowanie punktu końcowego. Oba są świadomymi decyzjami o różnych kosztach utrzymania. Otwieranie każdego portu w zakresie nie jest żadną z nich i to jest opcja, którą zwykle proponuje się pod koniec długiego dnia. Zapisz wybór tam, gdzie żyją ciągi połączeń.

Jeśli żadna forma nie działa, problem leży powyżej wykrywania. Sprawdź nasłuchującego, trasę i regułę dostępu dla portu, którego instancja faktycznie używa, zanim obwinisz usługę przeglądarki.

Po wykryciu: uwierzytelnianie i tożsamość są oddzielne

Niepowodzenie logowania to inne zdarzenie niż przekroczenie czasu, a tożsamość VPN nie staje się loginem SQL z powodu tunelu. Gdy klient dotrze do właściwego portu, silnik bazy danych stosuje własne uwierzytelnianie i uprawnienia. Mieszanie obu etapów w jednym zgłoszeniu to sposób, w jaki problem wykrywania trafia do niewłaściwego zespołu. Przeczytaj numer błędu, zanim cokolwiek zmienisz.

Zachowaj udokumentowaną nazwę hosta, jeśli sterownik weryfikuje certyfikat serwera, ponieważ łączenie przez adres numeryczny może zmienić to sprawdzenie zamiast rozwiązać pierwotny problem. Nowsze sterowniki Microsoftu szyfrują domyślnie, więc niezgodność nazwy pojawia się jako błąd certyfikatu po udanym połączeniu TCP. To postęp, a nie nowa awaria.

Mit, który trzeba porzucić, to przekonanie, że nazwa hosta SQL Server jest pełnym adresem. To host plus, dla nazwanej instancji, zapytanie, którego tunel może nie przenieść. Nazwij port, nazwij ścieżkę wykrywania, a następna awaria powie ci, którą warstwę naprawić.