Dlaczego panel administracyjny routera przestaje odpowiadać po zmianie VPN

Zmieniłeś trasę lub regułę zapory, aby przetestować tunel na routerze, i teraz strona administracyjna nie odpowiada z laptopa, który dziesięć minut wcześniej działał bez zarzutu. Odruchem jest obwinianie VPN. Najczęściej tunel jest zdrowy, a zepsuła się jedna z trzech innych rzeczy: brak trasy powrotnej do własnego adresu routera, polityka wejścia odrzuca żądanie albo usługa internetowa nie nasłuchuje na adresie, który wywołujesz. Wszystkie trzy wyglądają w przeglądarce tak samo, dlatego ludzie restartują tunel przez godzinę i niczego się nie uczą.

Oto mit, który warto zabić najpierw: działający tunel nie jest drogą powrotną do środka. To nowe przyłącze sieciowe z własnymi pytaniami o zaufanie i może po cichu usunąć starą ścieżkę zarządzania, otwierając jednocześnie nową, której nikt nie przejrzał.

Tunel nigdy nie był ścieżką zarządzania

Przekazywanie i wejście to różne zadania. „Czy klient może dotrzeć do NAS przez tunel?” to pytanie o przekazywanie dotyczące pakietów przechodzących przez router. „Czy mogę otworzyć port SSH routera?” to pytanie o wejście dotyczące pakietów adresowanych do samego routera. Reguła przepuszczania napisana dla ruchu przekazywanego nic nie robi dla drugiego pytania, i to jest najczęstszy powód, dla którego tunel doskonale przenoszący ruch nadal odrzuca twoją sesję administracyjną.

Odwrotny błąd to zaufanie nazwie interfejsu. Tunel jest szyfrowany do peera, a nie do każdej usługi za nim, a słowo VPN na etykiecie interfejsu nic nie mówi o tym, którym źródłom należy pozwolić się zalogować.

Warstwa pierwsza: czy istnieje trasa do własnego adresu routera?

Zacznij na kliencie i zapytaj jądro, dokąd pójdzie pakiet. W Linuksie ip route get 10.6.0.1 wypisuje wybraną trasę, interfejs wyjściowy i adres źródłowy. Jeśli zgłasza trasę domyślną w stronę dostawcy, pakiet nigdy nie wchodzi do tunelu i żadna reguła na routerze go nie uratuje.

Strona tunelu ma własną wersję pytania. WireGuard traktuje AllowedIPs jako tablicę routingu kluczy kryptograficznych: na każdym końcu deklaruje, jakich adresów źródłowych peer może używać i jakie cele są do niego wysyłane. Jeśli wpis klienta nie zawiera adresu tunelu routera, klient nie ma do niego trasy. Jeśli wpis serwera dla tego klienta nie obejmuje adresu tunelu klienta, serwer odrzuca pakiet, zanim spojrzy na jakąkolwiek regułę zapory.

Potwierdź dokładny adres, który chcesz osiągnąć, zanim zaczniesz debugować politykę. Nieaktualny rekord DNS lub zbuforowany wpis sąsiada sprzed zmiany prowadzi cię do adresu, którego router nigdy nie posiadał.

Warstwa druga: polityka wejścia, a nie polityka przekazywania

Zapory oceniają reguły na interfejsie, na którym pakiet przychodzi. W pfSense i OPNsense zakładka interfejsu i kolejność reguł decydują, czy ruch do usług samej zapory jest dozwolony; reguła, która wypuszcza klientów LAN do internetu, nie jest regułą, która pozwala peerowi tunelu otworzyć interfejs web. W OpenWrt z firewall4 każda strefa ma politykę wejścia, option input 'ACCEPT' lub 'REJECT', a interfejs tunelu w strefie z wejściem REJECT będzie odrzucał połączenia zarządzające, nadal przekazując ruch, jeśli przekazywanie jest dozwolone.

Nie wyłączaj reguły chroniącej przed zablokowaniem, aby nowa ścieżka zadziałała. Ta reguła nie pozwala złej regule zablokować adresu zarządzania LAN; chroni podsieć LAN, a nie podsieć tunelu, którą właśnie utworzyłeś. Dodaj jedną wąską regułę dla źródła administratora i zostaw siatkę bezpieczeństwa w spokoju. Dokumentacja pfSense dotycząca dostępu administratora wyjaśnia, gdzie są te mechanizmy.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Warstwa trzecia: czy coś nasłuchuje na tym adresie?

Usługa może działać i mimo to być nieosiągalna, bo związała się z jednym adresem. uhttpd w OpenWrt trzyma jawne wpisy nasłuchu w /etc/config/uhttpd, na przykład list listen_http '0.0.0.0:80'; kompilacja, która wiąże się tylko z adresem LAN, nie przyjmuje niczego na adresie tunelu, a produkty udostępniające ustawienie interfejsu nasłuchu zachowują się tak samo. Powyższe polecenia nasłuchu odpowiadają na to bezpośrednio.

Potem oddziel odmowę od ciszy. nc -vz 10.6.0.1 443 zwracające odrzucone połączenie oznacza, że pakiet dotarł do routera i coś go odrzuciło, albo zamknięty port, albo jawna reguła odrzucenia. Zawieszenie do limitu czasu oznacza, że pakiet został porzucony lub nigdy nie był routowany. Ta różnica mówi, którą warstwę sprawdzić dalej, i kosztuje pięć sekund.

Interfejs VPN to granica, nie droga odzyskiwania

Szyfrowanie chroni przewód; nie mówi nic o tym, kto może otworzyć stronę administracyjną. Gdy tunel działa, oprzyj się pokusie rozwiązania dostępności przez zezwolenie na wszystko na interfejsie tunelu. Daj administratorom regułę powiązaną z ich własnym adresem tunelu albo osobny tunel tylko dla administratorów, a zwykłych użytkowników, NAS, kamery i rodzinne laptopy trzymaj z dala od portu zarządzania. Peer, który potrzebuje udostępniania plików, nie powinien być o jedną regułę od logowania do routera.

Rola routera zmienia odpowiedź. Router kończący tunel może zgodnie z prawem przyjmować z niego administratorów, natomiast router używający tunelu tylko jako wyjścia do internetu zwykle nie powinien. W obu przypadkach zezwolenie podsieci nie jest logowaniem, więc zostaw włączone uwierzytelnianie konta i bezpieczeństwo transportu.

Kompensacyjny ruch, który ludzie wykonują po zablokowaniu, jest gorszy: włączenie administracji przez WAN albo przekierowanie portu na interfejs web. To zamienia krótką awarię w trwałe wystawienie, a strona logowania staje się dostępna dla każdego skanera w internecie. Testuj także stronę odrzuconą, nie tylko dozwoloną, aby peer, który nie powinien mieć dostępu administratora, dostał limit czasu lub odmowę zamiast prośby o zalogowanie.

Testuj też świeżym połączeniem. Zapora stanowa trzyma istniejące przepływy w swojej tablicy stanów, więc już otwarta sesja SSH może przetrwać zmianę, która blokuje każde nowe połączenie. Tak właśnie blokada pozostaje niewidoczna do następnego restartu lub następnego uśpienia laptopa.

Przygotuj drogę powrotną, zanim dotkniesz polityki

Zapisz cztery rzeczy przed pierwszą zmianą: jak dotrzesz do urządzenia, jeśli tunel umrze, na przykład konsola szeregowa, konsola dostawcy albo maszyna w sieci LAN; dokąd eksportowana jest bieżąca konfiguracja; którą jedną regułę lub trasę zamierzasz zmienić; i jak dokładnie cofniesz ten element. W OpenWrt sysupgrade -b /tmp/backup.tar.gz przechwytuje konfigurację, a zmiany pozostają w zawieszeniu do uci commit, co daje tanie cofnięcie, jeśli zauważysz na czas. pfSense prowadzi historię konfiguracji, a AutoConfigBackup pomaga tylko wtedy, gdy był już włączony. Jeśli router stosuje zestaw reguł fail-closed, potwierdź, że planowana ścieżka konserwacji nie leży w ruchu blokowanym przez tę regułę, i pamiętaj, że restart ponownie stosuje trwałe reguły, zamiast je usuwać.

Zmieniaj jedną granicę na próbę, potem testuj z nowego połączenia, a nie z powłoki, którą trzymasz otwartą. Jeśli test się nie uda, cofnij tę jedną zmianę, zanim dotkniesz następnej warstwy. Tunel może być cały czas podniesiony, ale jego zielona ikona stanu nie jest dowodem, że nadal możesz wejść.

Szybka kontrola przed wyjściem:

• Czy docierasz do routera ze źródła, które nie zależy od właśnie edytowanej reguły?
• Czy polityka wejścia na interfejsie tunelu pozwala tylko źródłu administratora?
• Czy usługa zarządzania jest związana z adresem, który istnieje na tunelu?
• Czy przetestowałeś jednego odrzuconego peera i jedną świeżą sesję?
• Czy powierzchnia administracji przez WAN jest nadal zamknięta?