Konflikty portów między usługami

Konflikty portów między usługami to sytuacja, w której komponenty serwera próbują zająć ten sam numer portu sieciowego.

Na czym polega konflikt numerów portów

Konflikt portów między usługami powstaje wtedy, gdy dwa procesy próbują nasłuchiwać na tym samym adresie IP, numerze portu i protokole transportowym. Port jest liczbowym identyfikatorem używanym przez protokoły TCP lub UDP do kierowania ruchu do właściwego procesu. Sam numer nie oznacza jeszcze konkretnej usługi, ponieważ różne programy mogą korzystać z dowolnych portów, jeżeli ich konfiguracja na to pozwala. Problem pojawia się przy próbie utworzenia gniazda nasłuchującego, czyli takiego, które oczekuje na połączenia przychodzące.

W typowym przypadku pierwsza usługa poprawnie wiąże gniazdo z określonym portem, a druga otrzymuje błąd informujący o zajęciu adresu lub portu. W systemach uniksowych często pojawia się komunikat „Address already in use”, natomiast w systemach Windows może zostać zwrócony błąd związany z niemożnością użycia żądanego adresu. Konflikt nie musi oznaczać awarii samej aplikacji. Często wynika z uruchomienia drugiej instancji programu, pozostałego procesu po wcześniejszym zamknięciu usługi albo niezgodnej konfiguracji dwóch niezależnych komponentów.

TCP, UDP i zakres wiązania usługi

Ocena konfliktu wymaga rozróżnienia protokołu. Proces nasłuchujący na TCP nie zajmuje automatycznie tego samego punktu komunikacyjnego UDP, ponieważ TCP i UDP mają odrębne przestrzenie portów. Dwie usługi mogą więc używać tego samego numeru, na przykład jednej wartości portu TCP i tej samej wartości portu UDP, bez bezpośredniego konfliktu. Nie oznacza to jednak, że aplikacja będzie działała prawidłowo, ponieważ klient musi korzystać z właściwego protokołu i zgodnego formatu komunikatów.

Znaczenie ma również adres lokalny, z którym proces próbuje związać gniazdo. Usługa nasłuchująca wyłącznie na konkretnym adresie interfejsu może współistnieć z innym procesem związanym z innym adresem. Odmienna sytuacja występuje, gdy proces używa adresu oznaczającego wszystkie lokalne interfejsy, na przykład 0.0.0.0 dla IPv4 albo :: dla IPv6. Takie wiązanie może objąć również adres, na którym druga usługa chciałaby rozpocząć nasłuch. W niektórych konfiguracjach dodatkową rolę odgrywa opcja SO_REUSEADDR, a w systemach obsługujących ją odpowiednio także SO_REUSEPORT. Ich działanie zależy od systemu operacyjnego i sposobu użycia, dlatego nie należy zakładać, że automatycznie rozwiązują każdy konflikt.

Ustalenie procesu zajmującego port

Pierwszym etapem diagnostyki jest sprawdzenie, który proces posiada gniazdo nasłuchujące. W systemach Linux można użyć polecenia ss -ltnp dla nasłuchujących gniazd TCP wraz z informacją o procesie, a dla UDP odpowiedniego zestawienia ss -lunp. Narzędzie lsof może wskazać procesy używające konkretnego portu, na przykład przez filtr dla numeru portu. W systemie Windows podobną informację można uzyskać poleceniem netstat -ano, a identyfikator PID procesu można następnie powiązać z nazwą programu za pomocą tasklist. Wynik trzeba interpretować z uwzględnieniem adresu lokalnego, protokołu oraz stanu połączenia.

Samo znalezienie procesu nie wystarcza do bezpiecznego usunięcia problemu. Należy ustalić, czy jest to właściwa instancja usługi, proces uruchomiony ręcznie, pozostały proces po błędnym zamknięciu albo program, który został ponownie uruchomiony przez menedżer usług. Warto sprawdzić parametry startowe, plik konfiguracyjny, zależności oraz logi z chwili uruchamiania. Jeżeli proces został zakończony, port może przez pewien czas pozostawać związany z poprzednim połączeniem TCP w stanie przejściowym, lecz nie należy traktować tego jako uniwersalnego wyjaśnienia. Dla TCP stan TIME_WAIT dotyczy zakończonych połączeń, a nie zawsze oznacza, że aktywna usługa nadal nasłuchuje na porcie.

Zmiana konfiguracji i sprawdzenie skutku

Naprawa konfliktu polega na doprowadzeniu do jednoznacznego przypisania portu. Jeżeli działają dwie instancje tej samej usługi, można pozostawić jedną z nich i skorygować sposób uruchamiania drugiej. Gdy oba komponenty są potrzebne, jeden z nich powinien otrzymać inny, wolny port zgodny z konfiguracją klientów, regułami zapory oraz dokumentacją konkretnego programu. Zmiana numeru wyłącznie w konfiguracji serwera nie wystarczy, jeśli aplikacje klienckie nadal próbują łączyć się ze starą wartością. Po modyfikacji trzeba zweryfikować pliki konfiguracyjne, parametry uruchomieniowe i ewentualne zmienne środowiskowe, ponieważ ustawienie z jednego źródła może nadpisywać wartość z innego.

Po ponownym uruchomieniu usługi należy potwierdzić, że proces nasłuchuje na oczekiwanym adresie i protokole oraz że pozostałe komponenty mogą nawiązać połączenie. Pomocne jest sprawdzenie logu startowego, ponowne użycie narzędzia pokazującego gniazda nasłuchujące i wykonanie kontrolnego połączenia z właściwego hosta. Jeżeli port jest dostępny lokalnie, ale połączenie z innego urządzenia nie działa, przyczyną może być zapora sieciowa, błędny adres nasłuchu, filtr sieciowy albo niezgodność IPv4 i IPv6, a nie sam konflikt portów. Diagnostyka powinna więc obejmować cały łańcuch: proces, gniazdo, adres, protokół, konfigurację klienta i reguły dostępu.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z konfiguracją usług sieciowych i konfliktami portów.