Na których portach OpenVPN Access Server rzeczywiście nasłuchuje?
Przejrzyj listę gniazd na hoście Access Server: rozpoznaj domyślnych nasłuchujących, odróżnij loopback od portów publikowanych i sprawdź przekazywanie, zanim zamkniesz port.
Uruchamiasz ss -lntup na hoście Access Server i otrzymujesz listę dwukrotnie dłuższą, niż oczekiwano. Połowa wpisów to porty w kształcie demonów, o których nikt nie wspomniał podczas instalacji. Odruchem jest zamknięcie wszystkiego, co nie jest 443 ani 1194, i tak ludzie psują własny portal klienta.
Access Server nie jest jednym nasłuchującym. To usługa VPN, usługa webowa i uczestnik klastra, a w zależności od liczby skonfigurowanych demonów TCP może generować dodatkowe porty specyficzne dla demonów i przekierowania firewalla.
Przejrzyj inwentarz po kolei: odczytaj gniazda, zmapuj znane, sklasyfikuj resztę według właściciela i powiązania, a następnie sprawdź, co je faktycznie publikuje.
Zacznij od jednego polecenia tylko do odczytu
sudo ss -lntup daje transport, adres lokalny, port i proces właściciela dla każdego nasłuchującego gniazda. Flagi mają znaczenie: -l nasłuchiwanie, -n numerycznie, -t TCP, -u UDP, -p proces. Bez roota otrzymujesz gniazda, ale nie nazwy procesów, a to dokładnie ta kolumna, której potrzebujesz do klasyfikacji.
Zapisz cztery pola na wiersz, zanim wyrobisz sobie opinię: protokół, adres powiązania, port i polecenie. Trzymaj wersję Access Server i skonfigurowaną liczbę demonów obok tej listy, bo oba zmieniają to, czego należy się spodziewać.
Dwa wiersze, które wyglądają identycznie, nie są identyczne. TCP i UDP na tym samym numerze to osobne gniazda z osobną ekspozycją, a 0.0.0.0 i :: to osobne powiązania dla osobnych rodzin adresów. Usługa powiązana tylko z 127.0.0.1 nie jest bezpośrednio osiągalna z innego hosta, choć lokalne przekierowanie wciąż może ją opublikować.
Nasłuchujący, których powinieneś rozpoznać
Te wartości domyślne obejmują większość wdrożeń i dają punkt odniesienia do porównań. To wartości domyślne, a nie pełna lista dozwolonych.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Wszystko poza tym wymaga wyjaśnienia, a nie założenia. Często zobaczysz nasłuchujące tylko lokalnie, należące do komponentów, które produkt instaluje dla siebie. Potwierdź je przez PID i konfigurację usługi, a nie przez zapamiętany numer portu, i nie traktuj nieznanego portu jako wrogiego tylko dlatego, że jest nieznany.
Gniazdo poza znaną parą też nie jest automatycznie pozostałością. Gdy skonfigurowano kilka demonów TCP, Access Server tworzy nasłuchujące dla każdego demona i przekierowuje do nich ruch, więc ich liczba i wartości portów wynikają z tej konfiguracji.
Sklasyfikuj, zanim cokolwiek zamkniesz
Dla każdego niepewnego wiersza odpowiedz na trzy pytania w tej kolejności.
- Właściciel i cel. Dopasuj PID do jednostki lub procesu i odczytaj konfigurację tej usługi. Jeśli nie potrafisz wskazać właściciela, nie jesteś gotowy, by cokolwiek decydować o gnieździe.
- Zakres powiązania. Loopback jest lokalny dla przestrzeni nazw. Powiązanie wildcard jest osiągalne tylko wtedy, gdy pozwalają na to routing, filtrowanie hosta i ewentualne reguły na poziomie chmury, więc adres powiązania jest konieczny, ale niewystarczający. Sprawdź IPv4 i IPv6 jako osobne decyzje.
- Opublikowana ścieżka. Szukaj przekazywania usługi, przekierowań specyficznych dla demonów, zewnętrznego proxy i faktycznej polityki firewalla. To jest krok, który ludzie pomijają, i to on zamienia niewinnie wyglądający port backendu w osiągalną ścieżkę administracyjną.
To samo pytanie czyta się inaczej spoza hosta. Port bez reguły firewalla hosta nadal może zostać zamknięty przez grupę zabezpieczeń w chmurze, a port z permisywną regułą hosta może być nieosiągalny, bo nic do niego nie routuje. Spójrz na oba końce, zanim napiszesz wniosek inwentarza.
Gdzie opublikowana ścieżka różni się od listy gniazd
Własna dokumentacja Access Server omawia przypadek, który powoduje najwięcej zamieszania: gdy działa kilka demonów TCP, port przedni przekazuje do portów specyficznych dla demonów, a widoczny układ przestaje odpowiadać liście gniazd. samouczek dotyczący filtrowania interfejsu webowego opisuje te reguły i dlaczego filtr napisany tylko dla oczywistego portu może całkowicie pominąć przekierowaną ścieżkę.
Kontrola klastra to drugie miejsce, w którym wersja ma znaczenie. Od 3.0 dzieli 943; starsze konfiguracje klastra używały 945. Otwarcie lub zablokowanie jednego z nich bez sprawdzenia wersji daje uporządkowany z wyglądu i błędny inwentarz.
Więc widoczna z zewnątrz powierzchnia to suma trzech rzeczy: nasłuchujących gniazd, reguł przekazywania, które publikują je ponownie, oraz kontroli sieciowych przed hostem. Każdy inwentarz, który zapisuje tylko pierwsze, jest niepełny, a każda zmiana, która bierze pod uwagę tylko pierwsze, albo zostawi ścieżkę otwartą, albo odetnie usługę.
Zweryfikuj po każdej zmianie
Zmieniaj ustawienia nasłuchujących przez obsługiwanego właściciela konfiguracji i trzymaj otwartą konsolę odzyskiwania, gdy to robisz. Utrata dostępu administracyjnego do interfejsu webowego na zdalnym hoście nie jest odzyskiwalna przez VPN, który właśnie wyłączyłeś.
Następnie zweryfikuj cztery rzeczy, których wdrożenie zwykle potrzebuje: klient VPN się łączy, portal klienta się ładuje, dostęp administracyjny działa i komunikacja klastra nadal działa, jeśli uruchamiasz więcej niż jeden węzeł. Test wyłącznie VPN przechodzi wygodnie, gdy portal jest zepsuty.
Zakończ, zapisując dozwoloną ścieżkę dla każdej usługi: które gniazdo, które powiązanie, która reguła przekazywania, która kontrola sieci. Ten dokument jest użytecznym wynikiem bezpieczeństwa. Minimalna liczba gniazd nie jest, podobnie jak masowy reset, który zamyka nasłuchujące, których nikt nie zdążył zidentyfikować.