Port 1194 jest już używany: do kogo należy to gniazdo OpenVPN?

Uruchom ten sam profil serwera dwukrotnie, a drugi proces zakończy się błędem, że adres jest już używany dla portu 1194. W typowym przypadku konflikt utworzyło uruchomienie diagnostyczne, a pierwotna instancja nadal doskonale obsługuje klientów. Ta historia wyjaśnia dużą część takich zgłoszeń i warto ją rozpoznać, zanim cokolwiek zostanie uruchomione ponownie. To także najtańszy wariant rozwiązania.

Błąd opisuje lokalne powiązanie i nic poza tym. Nie jest dowodem, że dostawca blokuje port, że klient wysłał błędne hasło albo że łańcuch certyfikatów jest uszkodzony.

Przeczytaj dokładny błąd powiązania

Dwa błędy z tej rodziny znaczą różne rzeczy, a ich pomieszanie kieruje cię na niewłaściwą warstwę. „Adres jest już używany” mówi, że inne gniazdo zajmuje żądany punkt końcowy. „Adres jest niedostępny” mówi, że żądany adres jeszcze nie istnieje na tym hoście, co jest problemem gotowości, a nie duplikatem.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Skopiuj tekst błędu, zanim cokolwiek zmienisz, wraz z podanym adresem i portem. Usługa, która czeka na pojawienie się interfejsu, będzie wielokrotnie rejestrować drugi błąd, a następnie pomyślnie się powiąże, gdy adres będzie istniał; usługa, która rejestruje pierwszy błąd, nigdy nie odniesie sukcesu, dopóki duplikat nie zostanie rozwiązany. Zapisanie, który z nich widziałeś, nic nie kosztuje i oszczędza zmarnowane polowanie na interfejs.

Zinwentaryzuj gniazdo, nie port

Numer portu to niepełny spis. Punkt końcowy to transport, rodzina adresów, adres lokalny i port, wszystko w jednej przestrzeni nazw sieci. Odbiornik UDP i odbiornik TCP na tym samym numerze to różne gniazda, a dwa procesy na tym samym numerze w różnych przestrzeniach nazw nigdy się nie spotykają.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Najpierw uruchom transport, którego profil faktycznie używa. Potem spójrz na kolumnę adresu lokalnego, a nie tylko na numer: powiązanie wieloznaczne obejmuje każdy adres lokalny, więc drugi proces proszący o jeden konkretny adres może z nim kolidować, nawet jeśli drukowane ciągi się różnią. Opcje ponownego użycia gniazda i reguły platformy decydują o dokładnym wyniku, dlatego powinno to być obserwacją, a nie regułą stosowaną do każdego wdrożenia.

Ustal, który proces jest jego właścicielem

Numeryczne punkty końcowe wraz z informacjami o procesie identyfikują właściciela, gdy pozwalają na to twoje uprawnienia, a właściciel jest tym, czego potrzebujesz, a nie nazwa programu. Dwa procesy OpenVPN mogą uruchamiać różne profile, a ten, który trzyma odbiornik, może być najmniej oczekiwany.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Porównaj to, co znajdziesz, z menedżerem usług, środowiskiem uruchomieniowym kontenerów lub procesem terminala pozostałym po wcześniejszym teście. Brak szczegółów procesu nie jest dowodem, że gniazdo nie ma właściciela; zwykle oznacza, że zapytanie wykonano bez wystarczających uprawnień. Podobnie lista tylko TCP nie usuwa konfliktu UDP, więc sprawdź transport wymieniony w błędzie. Sama nazwa procesu nigdy nie mówi, który profil został wczytany, a to profil decyduje o punkcie końcowym.

Jeden właściciel albo dwie zaprojektowane instancje

Jeśli wdrożenie przewiduje jeden serwer, utrzymuj jednego właściciela cyklu życia i czytaj dziennik tej instancji lub skonfigurowany log, zamiast uruchamiać drugą kopię, aby ją obserwować. Gdy kontrolowane uruchomienie na pierwszym planie jest naprawdę konieczne, celowo zatrzymaj zarządzaną instancję i przedtem uwzględnij klientów, którym służy.

Jeśli przewidziano dwie instancje, daj im odrębne odbiorniki i odrębne wszystko inne: pule adresów, interfejsy wirtualne, politykę trasowania i własność konfiguracji. Sam inny port oddziela tylko gniazdo, a oba serwery nadal będą walczyć o tę samą pulę i te same trasy.

Trzy skróty zasługują na nazwanie, bo pojawiają się w każdym wątku o tym błędzie. Nie zabijaj dowolnego PID-u, który wygląda jak winowajca. Nie włączaj współdzielenia gniazda, aby uciszyć komunikat. Nie przełączaj profilu serwera na niepowiązaną konfigurację w stylu klienta, bo to sprawia, że błąd powiązania znika; serwer staje się nieosiągalny w sposób trudniejszy do zdiagnozowania niż pierwotny konflikt.

Zmiana portu jest uzasadnioną odpowiedzią tylko wtedy, gdy nowy odbiornik jest częścią zatwierdzonego projektu, który obejmuje regułę przekazywania i punkt końcowy klienta. Jeśli nie zostały zaktualizowane, przeniosłeś konflikt w miejsce, w którym nikt go nie znajdzie.

Zweryfikuj powiązanie przede wszystkim innym

Po ograniczonej poprawce potwierdź, że zamierzona instancja jest aktywna, że jej odbiornik pojawia się na oczekiwanym transporcie i że klient może się połączyć. Udane powiązanie kończy tylko etap lokalnego gniazda; nie potwierdza niczego o uwierzytelnianiu ani o ruchu po podniesieniu tunelu.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Jeśli gniazdo istnieje, a klient nadal zawodzi, pozostały problem jest poniżej i błąd powiązania jest już historią. Właśnie ta separacja jest całą istotą czytania najpierw dokładnego komunikatu: jeden błąd, jedna warstwa, jeden właściciel. Czytaj tak, a następny objaw zacznie się od znanego stanu, nie od domysłu.