Diagnostyka połączenia

Diagnostyka połączenia to proces weryfikacji przyczyn niepowodzeń nawiązania sesji z serwerem bazodanowym.

Ustalenie miejsca przerwania połączenia

Diagnostyka połączenia z serwerem bazodanowym polega na rozdzieleniu problemu na kolejne etapy: rozpoznanie nazwy hosta, uzyskanie adresu IP, zestawienie połączenia sieciowego, nawiązanie sesji protokołu używanego przez silnik bazy danych oraz uwierzytelnienie użytkownika. Taki podział pozwala odróżnić awarię sieci od błędnego portu, niedostępnej usługi, nieprawidłowych danych logowania albo ograniczeń konfiguracyjnych serwera. Sam komunikat o braku połączenia często nie wskazuje dokładnego źródła problemu, dlatego należy analizować również kod błędu, czas jego wystąpienia i logi klienta oraz serwera.

Pierwszym krokiem jest sprawdzenie, czy komputer kliencki korzysta z właściwej nazwy hosta i portu. Polecenie nslookup nazwa-hosta pozwala zweryfikować, jaki adres zwraca DNS, natomiast ping może potwierdzić podstawową osiągalność adresu, ale nie sprawdza działania konkretnej usługi bazodanowej. Do testu portu TCP w systemie Windows można użyć polecenia Test-NetConnection nazwa-hosta -Port numer-portu. Wynik z nieudanym testem TCP wskazuje na problem z trasą, zaporą, nasłuchem usługi albo podanym portem; poprawne zestawienie TCP oznacza natomiast tylko, że host przyjął połączenie na tym porcie, a nie że logowanie do bazy zakończy się powodzeniem.

Adres, port i stan usługi bazodanowej

Serwer bazy danych może nasłuchiwać wyłącznie na adresie lokalnym, na konkretnym interfejsie sieciowym albo na wszystkich skonfigurowanych interfejsach. Jeżeli klient łączy się z innym adresem niż ten, na którym usługa prowadzi nasłuch, połączenie nie zostanie przyjęte. Weryfikacja po stronie serwera powinna obejmować stan procesu lub usługi, konfigurację adresów nasłuchu oraz rzeczywisty numer portu TCP. Numer portu nie wynika automatycznie z samej obecności silnika bazy danych, ponieważ administrator może zmienić ustawienie lub uruchomić kilka instancji korzystających z różnych portów.

W systemie Windows stan nasłuchu można sprawdzić poleceniem Get-NetTCPConnection -State Listen, a powiązany proces ustalić przez identyfikator procesu i narzędzia systemowe. W systemach Linux użyteczne jest polecenie ss -ltnp, które pokazuje nasłuchujące gniazda TCP i procesy. Jeżeli usługa działa, ale port nie jest dostępny z sieci, należy sprawdzić reguły zapory na serwerze, zaporę sieciową oraz ewentualne reguły na urządzeniach pośredniczących. Błąd typu „connection refused” zwykle oznacza aktywny host, który odrzucił połączenie na danym porcie, natomiast przekroczenie limitu czasu może wskazywać na filtrowanie pakietów, błędną trasę albo brak odpowiedzi serwera.

Uwierzytelnienie, szyfrowanie i parametry sesji

Po udanym połączeniu TCP klient musi przejść procedurę właściwą dla używanego silnika bazodanowego. Na tym etapie znaczenie mają nazwa użytkownika, hasło, metoda uwierzytelniania, wskazana baza lub instancja, wymaganie szyfrowania oraz zgodność parametrów sesji. Błędne hasło nie jest tym samym co niedostępny serwer: w pierwszym przypadku serwer odpowiada komunikatem związanym z autoryzacją, a w drugim klient nie dochodzi do etapu logowania. Warto sprawdzić, czy aplikacja nie korzysta z innego pliku konfiguracyjnego niż ten, który został zmieniony, oraz czy zmienne środowiskowe nie nadpisują wartości zapisanych w konfiguracji.

Problemy z szyfrowaniem mogą wystąpić, gdy klient wymaga TLS, a serwer nie obsługuje oczekiwanego wariantu, albo gdy certyfikat serwera ma niezgodną nazwę, jest nieważny lub nie pochodzi z zaufanego łańcucha. Należy również uwzględnić różnicę między nazwą hosta używaną w certyfikacie a adresem IP wpisanym w konfiguracji. W diagnostyce trzeba zachować pełny komunikat błędu, ale nie ujawniać haseł ani całych ciągów połączeń zawierających sekrety. Jeżeli połączenie jest zrywane dopiero po bezczynności, przyczyną może być limit czasu w kliencie, serwerze, zaporze albo urządzeniu pośredniczącym. Jeżeli zrywanie następuje podczas długiego zapytania, trzeba osobno sprawdzić limity czasu operacji i stabilność trasy sieciowej.

Próba kontrolna i dokumentowanie wyniku

Rzetelna diagnostyka wymaga wykonania kontrolnej próby z tego samego komputera, konta systemowego i środowiska, z którego korzysta aplikacja. Narzędzie administracyjne uruchomione ręcznie może działać poprawnie, gdy aplikacja używa innego hosta, portu, użytkownika lub magazynu certyfikatów. Należy porównać parametry obu prób, a następnie ustalić, czy problem występuje stale, tylko w określonych godzinach, po zmianie adresu sieciowego albo po restarcie usługi. Przydatne są znaczniki czasu, adres klienta, adres serwera, numer portu, etap zakończenia próby oraz dokładny kod błędu.

W przypadku laptopa lub komputera PC diagnostyka może obejmować także kartę sieciową, sterownik, połączenie Wi-Fi lub Ethernet, konfigurację DNS i lokalne reguły zapory. Wymiana kabla albo przejście z Wi-Fi na Ethernet ma wartość diagnostyczną tylko wtedy, gdy wynik zostanie porównany z wcześniejszą próbą i innymi urządzeniami. Jeżeli kilka klientów traci dostęp jednocześnie, bardziej prawdopodobna jest awaria serwera, sieci lub usługi wspólnej; jeżeli problem dotyczy jednego komputera, należy skupić się na jego konfiguracji i ścieżce dostępu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz podzespołów, a w ramach diagnozy sprzętu może również sprawdzić elementy lokalnego połączenia sieciowego wpływające na dostęp do usług.