Wyłącznik awaryjny blokuje tylko IPv4: dlaczego IPv6 i tak wycieka

Tunel pada, wyłącznik awaryjny zgłasza, że zadziałał, a pobieranie trwa dalej. W regułach IPv4 nic nie jest zepsute. Aplikacja po prostu przeniosła się na ścieżkę, dla której tych reguł nigdy nie napisano.

Urządzenia z podwójnym stosem mają dwa niezależne wyjścia. Zablokowanie jednego z nich to połowa blokady.

Dwa zestawy reguł, dwa ustawienia domyślne

W Linuxie iptables i ip6tables to osobne tabele z osobnymi politykami. Ustawienie łańcuchów INPUT i OUTPUT tabeli IPv4 na DROP niczego nie zmienia w tabeli IPv6, gdzie domyślnie zwykle jest ACCEPT. Ten sam podział istnieje w nftables, gdzie można sprawdzić jedną rodzinę i odkryć, że tylko jedna z nich niesie twoje reguły. Ta asymetria jest normalna i na tym polega cały problem.

Dlatego wyłącznik awaryjny może wyglądać dokładnie, a działać częściowo. Skrypt, który zapisał reguły IPv4, wykonał się, liczniki rosną, linia logu się pojawia, a pakiet IPv6 opuszcza fizyczny interfejs całkowicie nietknięty.

Czytaj, co twój klient faktycznie instaluje, a nie co obiecuje strona marketingowa. Niektórzy klienci kierują IPv6 do tunelu, inni celowo je blokują, a jeszcze inni zostawiają je w spokoju, podczas gdy blokada na poziomie platformy egzekwuje inną regułę. Dokumentacja dostawcy jest tu jedynym źródłem, któremu warto zaufać.

Co mówi ci konfiguracja interfejsu

Strona podręcznika wg-quick zawiera reguły IPv6 w przykładowej konfiguracji, a powodem jest dokładnie ta luka. Przykład nie jest ozdobą. Istnieje, ponieważ same reguły IPv4 pozostawiłyby drugą rodzinę otwartą.

Skopiowanie połowy przykładu daje połowę polityki. To najczęstsze źródło tego wycieku. Wpis na blogu skrócił przykład ze względu na długość. Skrócona wersja stała się potem szablonem, którego wszyscy ponownie użyli.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Jeśli drugie polecenie wypisuje politykę zezwalającą, a pierwsze wypisuje DROP, znalazłeś odpowiedź nie dotykając klienta. Ta asymetria jest błędem.

Dlaczego jedno zapytanie to nie cała historia

Jedna nazwa może zwrócić zarówno rekord A, jak i rekord AAAA, a aplikacje nie wszystkie wybierają tak samo. Przeglądarka może preferować IPv6, gdy sieć go oferuje, i wycofać się przy błędzie, podczas gdy synchronizacja w tle lub aktualizator używa własnego resolvera i własnej preferencji. Jeden udany test przez IPv4 dowodzi więc jednej ścieżki, a nie polityki.

Przejścia sieciowe również zmieniają odpowiedź. Dołączenie do innej sieci Wi-Fi, wybudzenie ze snu lub przejście na sieć komórkową może dać urządzeniu nowy prefiks IPv6, a polityka, która wyglądała wystarczająco w biurowej sieci LAN, może go nie obejmować.

Przetestuj stan, w którym tunel jest wyłączony

Testowanie podczas połączenia mówi, że tunel działa. Ciekawym testem jest stan niedostępności, bo wtedy wyłącznik awaryjny powinien wytrzymać. Zatrzymaj tunel celowo, a potem wypróbuj ważne cele z aplikacji, którą chronisz.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Obie rodziny powinny zawieść zamknięte. Jeśli żądanie IPv4 wygaśnie, a żądanie IPv6 zwróci kod statusu, polityka jest niekompletna i żadna ilość ponownego testowania tunelu tego nie zmieni.

Zachowaj też udokumentowane wyjątki w tym teście. Wykrywanie sieci lokalnej, odnowienie DHCP lub ścieżka rozruchu do punktu końcowego VPN mogą wymagać pozostania osiągalnymi, a te wyjątki powinny być nazwane w polityce, zamiast być odkrywane podczas awarii. Test wycieku, który zawodzi, bo tunel nie może wrócić, nie jest ustaleniem bezpieczeństwa, to ustalenie łączności.