Połączenia i sieć

Połączenia i sieć to obszar konfiguracji obejmujący protokoły, porty i reguły zapory dla serwera bazodanowego.

Warstwa sieciowa połączenia z serwerem bazodanowym

Połączenia i sieć w kontekście serwera bazodanowego obejmują drogę, którą klient pokonuje od aplikacji lub narzędzia administracyjnego do procesu obsługującego bazę danych. W typowym modelu klient nawiązuje połączenie TCP z adresem IP serwera i portem nasłuchu przypisanym do konkretnego silnika. Sam fakt, że serwer odpowiada na ping, nie potwierdza poprawności połączenia z bazą, ponieważ ping korzysta z protokołu ICMP, a klient bazy korzysta zwykle z TCP.

Do zestawienia połączenia potrzebne są co najmniej: prawidłowa nazwa hosta albo adres IP, poprawny port, działający proces serwera bazodanowego, trasa sieciowa oraz reguły zapory pozwalające na ruch. Jeżeli używana jest nazwa DNS, musi ona wskazywać właściwy adres. Błąd rozwiązywania nazwy, połączenie z nieaktualnym adresem albo próba użycia niewłaściwego portu może wyglądać z perspektywy aplikacji jak niedostępność bazy, mimo że sam serwer działa.

Adres nasłuchu, port i reguły zapory

Proces bazodanowy może nasłuchiwać na konkretnym adresie interfejsu sieciowego, na wszystkich dostępnych interfejsach albo wyłącznie lokalnie. Nasłuch lokalny ogranicza połączenia do tego samego komputera i uniemożliwia dostęp z innych urządzeń. Z kolei nasłuch na wielu interfejsach wymaga sprawdzenia, czy każdy z nich powinien przyjmować ruch oraz czy zapora systemowa i zapora sieciowa mają zgodne reguły.

Port musi być otwarty w odpowiednim kierunku. Reguła dopuszczająca ruch wychodzący z komputera klienckiego nie wystarczy, jeżeli zapora na serwerze odrzuca połączenia przychodzące. Znaczenie ma również zakres źródłowych adresów IP, protokół oraz profil sieci. Otwieranie portu dla całego Internetu nie jest równoważne z udostępnieniem go wyłącznie w zaufanej sieci lokalnej. Przy diagnozie należy ustalić, z jakiego adresu rzeczywiście przychodzi klient, czy po drodze działa translacja adresów oraz czy połączenie nie jest filtrowane przez router, VPN lub zaporę firmową.

Szyfrowanie TLS i przebieg negocjacji

Po zestawieniu połączenia TCP klient i serwer mogą negocjować szyfrowanie TLS. W takim układzie sprawdzany jest certyfikat serwera, jego nazwa oraz okres ważności, a następnie uzgadniana jest wersja protokołu i zestaw algorytmów kryptograficznych obsługiwanych przez obie strony. Certyfikat wystawiony dla innej nazwy hosta może powodować błąd weryfikacji nawet wtedy, gdy adres IP prowadzi do właściwego serwera.

Problemy z TLS mogą wynikać z braku zaufania do urzędu certyfikacji, nieprawidłowego łańcucha certyfikatów, rozbieżności czasu systemowego, wyłączonych wersji protokołu albo różnic między biblioteką klienta i konfiguracją serwera. Warto rozdzielić błąd transportowy od błędu szyfrowania: brak odpowiedzi na porcie wskazuje zwykle na adres, trasę, usługę lub zaporę, natomiast komunikat o certyfikacie pojawia się dopiero po rozpoczęciu negocjacji zabezpieczonego kanału. W środowisku testowym wyłączenie sprawdzania certyfikatu może pomóc potwierdzić źródło problemu, ale nie powinno być traktowane jako docelowa konfiguracja.

Diagnostyka niedostępności połączenia

Diagnostykę należy prowadzić od najniższej warstwy do najwyższej. Najpierw sprawdza się, czy nazwa hosta rozwiązuje się do oczekiwanego adresu, następnie czy z urządzenia klienckiego można osiągnąć właściwy port TCP, a później czy serwer przyjmuje sesję i odpowiada protokołem właściwym dla używanego silnika. Dopiero po potwierdzeniu tych etapów analizuje się uwierzytelnianie, uprawnienia do konkretnej bazy, nazwę instancji oraz parametry aplikacji.

Przydatne są dane z kilku miejsc: komunikat klienta, log serwera bazodanowego, dziennik zapory, konfiguracja interfejsów sieciowych, tablica routingu oraz ustawienia DNS. „Connection refused” zwykle oznacza, że host jest osiągalny, ale na danym porcie nie ma usługi przyjmującej połączenia albo aktywna reguła odrzuca próbę. „Timeout” może wskazywać na filtrowanie pakietów, błędną trasę lub niedostępny host. Udane połączenie TCP nie gwarantuje jeszcze poprawnej sesji aplikacyjnej, ponieważ później mogą wystąpić błędy TLS, uwierzytelniania lub autoryzacji.

W przypadku laptopa lub komputera PC problemy z połączeniami mogą być związane także z lokalną zaporą, aktywnym klientem VPN, nieprawidłowym serwerem DNS, profilem sieci Wi-Fi albo ustawieniami proxy. Rzetelna naprawa wymaga zachowania istniejącej konfiguracji przed zmianami, ustalenia oczekiwanego topologicznie przepływu ruchu i sprawdzenia po każdej zmianie, czy poprawił się konkretny etap połączenia. Pozwala to odróżnić awarię sieci od błędnej konfiguracji klienta lub samej usługi bazodanowej.