Diagnostyka zdalnych połączeń

Diagnostyka zdalnych połączeń to proces weryfikacji przyczyn problemów z dostępem do bazy danych spoza sieci lokalnej.

Zakres diagnostyki dostępu do bazy spoza sieci lokalnej

Diagnostyka zdalnych połączeń polega na ustaleniu, na którym odcinku komunikacji powstaje problem z dostępem do bazy danych. Analiza obejmuje komputer kliencki, lokalną sieć, router, translację adresów NAT, zaporę sieciową, trasę do hosta oraz usługę nasłuchującą po stronie serwera. Sam fakt, że serwer działa poprawnie w sieci lokalnej, nie potwierdza jeszcze możliwości połączenia z zewnątrz. Połączenie zdalne może być blokowane przez konfigurację adresu, filtrowanie ruchu, błędne rozwiązywanie nazwy albo nieprawidłowe dane uwierzytelniające.

Pierwszym krokiem jest precyzyjne określenie punktu docelowego: nazwy hosta lub adresu IP, numeru portu TCP oraz używanego klienta bazodanowego. Należy rozdzielić problem z osiągalnością hosta od problemu z samą sesją bazodanową. Brak odpowiedzi na zapytanie DNS oznacza inną przyczynę niż odrzucenie połączenia przez port, a przekroczenie limitu czasu wskazuje zwykle na filtrowanie lub brak trasy. Komunikat o nieudanym logowaniu pojawia się dopiero wtedy, gdy komunikacja sieciowa z usługą została już nawiązana.

Rozdzielenie DNS, routingu i portu TCP

Rozwiązywanie nazwy DNS należy sprawdzić przed testowaniem aplikacji. Nazwa używana wewnątrz sieci może wskazywać prywatny adres IP, który nie jest dostępny przez Internet, natomiast klient zdalny może otrzymywać inny rekord albo nie otrzymywać go wcale. Przydatne jest porównanie wyniku zapytania DNS z adresem, który powinien być osiągalny z danej lokalizacji. Trzeba również uwzględnić rekordy IPv4 i IPv6, ponieważ komputer może preferować adres IPv6, mimo że trasa lub zapora obsługuje wyłącznie IPv4.

Po potwierdzeniu adresu bada się trasę oraz możliwość zestawienia połączenia TCP na właściwym porcie. Polecenie tracert w systemie Windows lub traceroute w systemach uniksowych pomaga wskazać miejsce, w którym pakiety przestają docierać, ale nie jest dowodem działania konkretnej usługi. Do sprawdzenia portu można użyć polecenia PowerShell Test-NetConnection z parametrami -ComputerName i -Port. Wynik pozytywny potwierdza możliwość nawiązania TCP, lecz nie potwierdza poprawnej autoryzacji ani zgodności protokołu aplikacyjnego.

Zapora, NAT i szyfrowanie sesji

Zdalny dostęp często zależy od kilku niezależnych reguł zapory. Ruch może być filtrowany na komputerze klienta, na routerze, w zaporze serwera albo przez urządzenie pośrednie należące do operatora sieci. W przypadku NAT połączenie przychodzące musi zostać skierowane do właściwego hosta wewnętrznego, a przekierowanie portu nie może wskazywać nieaktualnego adresu przydzielanego dynamicznie przez DHCP. Należy też sprawdzić, czy usługa nasłuchuje na adresie dostępnym z zewnątrz, a nie wyłącznie na interfejsie pętli zwrotnej lub prywatnym interfejsie sieciowym.

Jeżeli połączenie korzysta z TLS, diagnostyka obejmuje certyfikat, nazwę hosta, okres ważności oraz zaufany łańcuch certyfikacji. Certyfikat wystawiony dla innej nazwy może zostać odrzucony, nawet gdy port TCP jest osiągalny. Błąd może również wynikać z niezgodnych wersji protokołu szyfrowania lub niedopasowanych algorytmów, ale jego interpretacja wymaga odczytania pełnego komunikatu klienta. Nie należy wyłączać weryfikacji certyfikatu jako stałego rozwiązania, ponieważ usuwa ona kontrolę tożsamości punktu docelowego.

Uwierzytelnianie i uporządkowanie wyników testów

Po potwierdzeniu warstwy sieciowej trzeba zweryfikować konfigurację samego klienta bazodanowego. Znaczenie mają dokładna nazwa hosta, port, nazwa bazy lub instancji, metoda uwierzytelniania oraz uprawnienia przypisane do konta. Konto może mieć możliwość logowania tylko z określonego adresu źródłowego albo wymagać dodatkowego mechanizmu uwierzytelnienia. Błędne hasło, wygasłe poświadczenie i odmowa dostępu do konkretnej bazy są problemami logicznymi usługi, a nie dowodem awarii sieci.

Wyniki warto zapisywać w kolejności: rozpoznanie nazwy, wybrany adres IP, test trasy, test portu TCP, negocjacja szyfrowania, uwierzytelnienie oraz wykonanie prostego zapytania. Taki zapis pozwala odtworzyć przebieg połączenia i odróżnić usterkę stałą od okresowej. Jeżeli dostęp działa z jednego łącza, a nie działa z innego, należy porównać adresy źródłowe, serwery DNS, reguły filtrowania i trasę. Jeżeli połączenie lokalne działa, lecz zdalne nie, najbardziej prawdopodobne są różnice w routingu, NAT, zaporze albo konfiguracji nasłuchiwania, a nie uszkodzenie samej bazy danych.