VPN połączony, ale zapora nadal blokuje: jak ustalić, która strona

Tunel działa, a jeden port nadal zawodzi. Przeczytaj ścieżkę, potem politykę na każdej warstwie, i zmień najwęższą regułę zamiast wyłączać jedną z dwóch kontroli.

Klient mówi, że jest połączony, zasób nadal odmawia, a zwykłym następnym krokiem jest wyłączenie czegoś. Obie kontrole w tym zdaniu robią różne rzeczy: VPN buduje ścieżkę dla objętego ruchu, a zapora decyduje dla każdego połączenia, czy ruch może przejść. Działający tunel z polityką odmawiającą wygląda z krzesła użytkownika dokładnie jak zepsuty tunel, więc zadaniem jest ustalenie, która warstwa odpowiada. Oto kolejność, której się trzymam, wraz z odczytem, który mówi, kiedy przestać.

Oddziel ścieżkę od polityki

Zacznij od kształtu awarii, bo to darmowa informacja. Upuszczenie pakietu daje przekroczenie czasu: klient ponawia, nic nie wraca, a polecenie wisi, aż się podda. Odmowa daje odrzucenie lub reset: coś odpowiedziało i powiedziało nie. Usługa, która nie nasłuchuje, odmawia na samym hoście, bez żadnej zapory.

Te trzy wyniki wskazują na różne warstwy. Przekroczenie czasu oznacza, że gdzieś polityka po cichu odrzuca, albo ścieżka nigdy nie opuszcza maszyny. Odmowa oznacza, że dotarłeś do hosta i jego stos albo lokalna zapora powiedziały nie. Zupełna cisza, przy interfejsie tunelu w górę i bez trasy do celu, oznacza, że ścieżka jest błędna i żadna reguła zapory tego nie naprawi.

Przeczytaj ścieżkę za jednym przejściem

Potwierdź, że tunel obejmuje cel, zanim spojrzysz na choćby jedną regułę. Tunel dzielony, który niesie tylko podsieć biura, nie skieruje żądania do innego zakresu, a wtedy awaria wygląda jak blokada zapory, którą nie jest:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Wyjście trasy wskazuje interfejs, którym pakiet opuści maszynę, i adres źródłowy, który będzie niósł. Jeśli tym interfejsem jest twoja fizyczna karta sieciowa, a nie tunel, problem leży w routingu albo w dozwolonych zakresach tunelu, i należy do konfiguracji VPN, a nie do zapory.

Jedna pułapka specyficzna dla VPN zasługuje na osobną kontrolę. W WireGuardzie AllowedIPs peera jest jednocześnie trasą i filtrem kryptograficznym: pakiet, którego adres źródłowy nie należy do dozwolonego zbioru peera, jest odrzucany, zanim zostanie sprawdzona jakakolwiek reguła zapory. Dlatego całkowicie poprawna zapora hosta może stać za cichym odrzuceniem, które wygląda jak polityka, a poprawką jest wiersz konfiguracji klucza, nie reguła.

Przeczytaj politykę w warstwie, która odpowiada

Gdy ścieżka jest poprawna, przejdź politykę od hosta na zewnątrz i wypatruj tej jednej warstwy, której liczniki się ruszają:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Gniazdo nasłuchujące odpowiada na inne pytanie niż reguły. Jeśli nic nie nasłuchuje na porcie, jądro odmawia połączenia i żadna reguła wejściowa nie ma znaczenia. Jeśli gniazdo istnieje, a połączenie od zdalnego klienta wygasa, gdzieś na ścieżce dochodzi do odrzucenia, a liczniki reguł mówią, czy dzieje się to tutaj.

Włącz rejestrowanie dla profilu lub łańcucha, który podejrzewasz, zamiast zgadywać z zewnątrz. Jedno zarejestrowane odrzucenie, które nazywa źródło, cel i port, identyfikuje warstwę i regułę, a także dowodzi, że pakiet dotarł, czego nie ustali żaden test po stronie klienta.

Przeczytaj decyzję bramy, gdy tunel tam się kończy

Na bramie site-to-site lub dostępu zdalnego VPN uwierzytelnia użytkownika, a polityka autoryzuje zasób, i to są odrębne nadania. Użytkownik wpuszczony do tunelu nie jest automatycznie wpuszczony na każdego hosta wewnętrznego, a odmowa często pochodzi z reguły przekazywania, podczas gdy sam tunel jest zdrowy. To samo rozdzielenie występuje w IPsec, gdzie polityka bezpieczeństwa wybierająca ruch różni się od filtra, który go wpuszcza, i dlatego oba są opisane jako różne mechanizmy w RFC 4301.

Sprawdź drogę powrotną tak samo starannie jak wychodzącą. Filtrowanie stanowe musi widzieć odpowiedź, więc asymetryczny routing przez tunel w jedną stronę i wokół niego w drugą daje odrzucenia, które wyglądają losowo i powtarzają się tylko u niektórych klientów. Jeśli ruch dotrze do bramy i się zatrzyma, przeczytaj regułę przekazywania i drogę powrotną razem, zanim cokolwiek poszerzysz.

Brama to także miejsce, gdzie reguła NAT lub maskowania może ukryć prawdziwe źródło. Jeśli wewnętrzne hosty widzą adres bramy zamiast klienta, ich reguły zapory hosta, które mają pasować do puli klientów, nigdy nie będą pasować, a poprawka należy do bramy, nie do każdego serwera.

Zmień najwęższą warstwę, potem zweryfikuj

Oprzyj się szerokiej naprawie. Wyłączenie zapory hosta, dodanie reguły pozwalającej na wszystko albo wpędzenie każdego interfejsu do zaufanego profilu usuwa za każdym razem kontrolę, która robiła swoje, a zmiana przeżyje incydent. Reguła ograniczona do zakresu źródłowego i danego portu jest łatwiejsza do przejrzenia, łatwiejsza do usunięcia i zostawia resztę polityki maszyny nietkniętą.

Zweryfikuj tym samym testem, który zawiódł, z tego samego klienta, a potem jeszcze raz po ponownym połączeniu, bo reguła, która pasowała przed ponownym negocjowaniem tunelu, może przestać pasować po nim:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Zanim to zamkniesz:

  • Trasa do celu wychodzi przez interfejs tunelu, a adres źródłowy zgadza się z tym, czego oczekuje polityka.
  • Coś nasłuchuje na porcie, a odmowa lub przekroczenie czasu jest przypisana nazwanej regule, a nie założona.
  • Brama przekazuje w obu kierunkach, a cel widzi źródło, dla którego napisano twoje reguły.
  • Żadna kontrola nie została wyłączona, aby test przeszedł, a twoja zmiana nazywa jeden zakres źródłowy i jeden port.

Powiązane artykuły