Kill switch na routerze obejmujący FORWARD, OUTPUT i IPv6

Logujesz się do routera, wklejasz zestaw reguł kill switch z postu na forum, i LAN przestaje przeglądać w chwili, gdy tunel pada. Dwa dni później router wciąż aktualizuje swój dynamiczny rekord DNS przez zwykły WAN, a laptop gościa wciąż dociera do stron IPv6. Oba zachowania są normalne, bo wklejone reguły obejmowały jeden łańcuch i jedną rodzinę adresów, a żadne z nich nie jest całym routerem. Przejście ścieżek pakietów po kolei pokazuje dokładnie, co zostało pominięte.

Zacznij od routera, nie od laptopa

Polityka na poziomie routera jest atrakcyjna dla małego biura, bo każde urządzenie za nim dziedziczy to samo zachowanie i nikt nie może zapomnieć włączyć przełącznika w kliencie. Daje też jedno miejsce do testowania po każdej aktualizacji firmware’u. Czego nie daje, to automatyczne objęcie własnego ruchu routera ani drugiej rodziny adresów, i to są dwie luki stojące za większością nieudanych wdrożeń.

Zanim cokolwiek zmienisz, zapisz na papierze trzy fakty: nazwę interfejsu WAN, nazwę mostu LAN oraz adres i port punktu końcowego VPN. Wszystkie trzy będą potrzebne w regułach, a zgadywanie nazw interfejsów to najczęstszy powód, dla którego poprawnie wyglądający zestaw reguł nic nie robi.

Przejdź trzy ścieżki, które może pokonać pakiet

Ruch z laptopa do internetu jest przekazywany dalej, więc przechodzi przez łańcuch FORWARD. Ruch generowany przez sam router, taki jak przekazywanie DNS, zapytania NTP, aktualizacje DDNS i kanał sterowania VPN, przechodzi przez OUTPUT. Ruch zarządzający adresowany do routera przychodzi przez INPUT.

Kill switch zbudowany tylko w FORWARD chroni więc klientów i nic więcej. Tabela pokazuje, dlaczego wyciek z początkowej sceny jest przewidywalny, a nie tajemniczy.

W większości projektów nie potrzebujesz kill switcha na INPUT, ale musisz utrzymać działający dostęp zarządzający, gdy tunel jest wyłączony. Inaczej przy pierwszej awarii VPN jedziesz do biura z kablem konsolowym.

Uporządkuj reguły, aby tunel nadal mógł się podnieść

Działający kill switch to lista zezwoleń zakończona odrzuceniem, a to kolejność czyni go kill switchem, a nie cegłą. Najpierw zezwól na loopback, punkt końcowy VPN, odpowiedzi dla ustanowionych przepływów i interfejs tunelu; resztę odrzuć na końcu.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Punkt końcowy musi być w tym miejscu adresem, a nie nazwą hosta. Gdy końcowe odrzucenie zablokuje DNS, reguła wskazująca nazwę hosta dostawcy nie może już zostać rozwiązana, i tunel nigdy nie wystartuje ponownie po restarcie. Jeśli dostawca zmienia punkty końcowe, rozwiąż nazwę przed zastosowaniem polityki i odświeżaj tę regułę z tego samego skryptu.

Odbij ten sam kształt w FORWARD dla ruchu klientów i umieść jawną regułę zarządzania nad odrzuceniem. Trzymaj tę regułę zarządzania wąską, ale osiągalną, i potwierdź ją, otwierając drugą sesję SSH przed zamknięciem pierwszej. Zablokowanie sobie dostępu podczas zmiany kill switcha jest dość częste, by to zaplanować. Na routerze z WireGuardem allowed-ips peera decyduje, co wchodzi do tunelu, a te reguły decydują, co może wyjść bez niego.

IPv6 potrzebuje własnych drzwi

Wszystko powyżej to IPv4. Jeśli twoja LAN ma działający IPv6, a tunel przenosi tylko IPv4, każde objęte urządzenie nadal ma bezpośrednią trasę do internetu, której nowe reguły nigdy nie widzą. Laptop z dual-stackiem chętnie ją wybierze, a kill switch będzie wyglądał na zepsuty tylko temu, kto testuje z IPv4.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Tu też liczy się kolejność: zezwolenie na loopback musi poprzedzać odrzucenie WAN, inaczej lokalne usługi na routerze zaczną dziwnie zawodzić. Jeśli sieć w ogóle nie używa IPv6, wyłączenie go na WAN i LAN jest prostsze i nie zostawia nic do zapomnienia.

Niektóre klienty VPN instalują trasę domyślną tylko dla IPv4 i zostawiają istniejącą trasę domyślną IPv6 nietkniętą. Sprawdź tablicę routingu po podłączeniu tunelu, zamiast zakładać, że klient to załatwił.

Udowodnij to przy wyłączonym tunelu

Zatrzymaj tunel z routera i testuj z trzech miejsc w tej kolejności:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Wyszukiwanie trasy mówi ci, dokąd trafiłby pakiet, a liczniki mówią, czy twoje reguły kiedykolwiek zadziałały. Reguła z zerem pakietów po nieudanym teście niczego nie chroni, a zwykłą przyczyną jest nazwa interfejsu inna niż wpisana. Testuj jawnie ruch generowany przez router, bo test od strony LAN nie może uruchomić OUTPUT.

Zdecyduj o trybie awarii, zanim go potrzebujesz. Fail-closed trzyma klientów offline, dopóki tunel nie wróci; fail-open przywraca zwykły dostęp WAN i niweczy cel dla ruchu, na którym ci zależało. Trasa blackhole do puli VPN z wysoką metryką to przydatna druga warstwa dla projektów fail-closed, bo przetrwa, gdy trasa tunelu zniknie, zamiast wracać do domyślnej.

Zaakceptuj konfigurację tylko wtedy, gdy klient LAN, żądanie generowane przez router i żądanie IPv6 wszystkie zawiodą przy wyłączonym tunelu, a wszystkie trzy znów działają, gdy tunel wstanie.