Trasa blackhole a kill switch VPN: co robi każdy z nich

Pakiet opuszcza laptop, nigdy nie dociera do bramy VPN, a żaden licznik zapory nie drgnie. Tablica routingu już zdecydowała o losie pakietu: wpis blackhole pasował do niego, a jądro odrzuciło go, zanim zobaczył go jakikolwiek interfejs. Takie zachowanie jest przydatne, gdy cel ma zawieść w sposób zamknięty, ale to działanie routingu o wąskim zasięgu. Traktowanie go jako pełnego kill switcha to miejsce, w którym projekty się mylą.

Co tak naprawdę obejmuje akcja odrzucania

Wyszukiwanie trasy wybiera tablicę, a następnie najdłuższy pasujący prefiks w niej. Trasa blackhole to zwykły wpis, którego akcją jest odrzucanie, więc wpływa tylko na pakiety, które wybrałyby ten wpis po całej decyzji. Zmień tablicę regułą polityki albo dodaj bardziej szczegółowy prefiks, a odrzucanie przestanie obowiązywać.

Dlatego zasięg blackhole jest precyzyjny i łatwy do opisania: obejmuje prefiks, w tablicy, dla tej rodziny adresów. Nie obejmuje celu, który wygrałaby inna tablica, i nie obejmuje IPv6 tylko dlatego, że prefiks IPv4 jest odrzucany.

ip route get pokazuje decyzję przed wdrożeniem czegokolwiek, wraz z tablicą i typem trasy. Czytanie tego wyniku jest szybsze niż wnioskowanie z nieudanego żądania, która reguła lub prefiks zadziałały.

Blackhole nie jest tym samym co unreachable ani prohibit

Linux oferuje trzy typy tras podobne do odrzucania i różnią się tym, co obserwuje nadawca. Blackhole odrzuca pakiet bez odpowiedzi, więc klient widzi przekroczenie czasu. Trasa unreachable zwraca komunikat ICMP unreachable, więc połączenie szybko zawodzi z błędem hosta lub sieci. Trasa prohibit zwraca błąd zakazu administracyjnego, bliższy świadomej odmowie polityki.

Wybierz zachowanie, które ma zobaczyć aplikacja. Ciche odrzucanie jest właściwe, gdy nie chcesz ujawniać polityki, a natychmiastowy błąd jest lepszy, gdy użytkownicy muszą zrozumieć, dlaczego cel jest niedostępny. Mieszanie typów w sieci tworzy zgłoszenia do pomocy technicznej, które opisują tę samą politykę jako trzy różne awarie.

Nie zakładaj, że każdy wpis odrzucania jest wymienny podczas diagnozowania połączenia. Tekst błędu, czas i przechwycenie pakietów się różnią, a typ trasy w tablicy mówi, na który patrzysz. podręcznik ip-route wymienia typy i ich zachowanie przy błędzie.

Jak wypada w porównaniu z kill switchem

Kill switch to filtrowanie pakietów: reguła zapory, która odrzuca ruch wychodzący, który opuściłby tunel. Trasa blackhole to decyzja o przekazywaniu podjęta wcześniej w stosie. Oba mogą zatrzymać ruch, ale widzą różne rzeczy i pomijają różne przypadki.

Zasięg jest tym, co ma znaczenie w porównaniu. Zapora może dopasować właściciela, port lub interfejs i zablokować aplikację, pozostawiając punkt końcowy osiągalny; trasa tego nie potrafi. Odwrotnie, trasa może wysłać cały prefiks do odrzucania bez załadowania jakiegokolwiek filtra pakietów, co jest przydatne w minimalnym systemie.

AllowedIPs w WireGuard to routing kluczem kryptograficznym, nie zapora. Decyduje, które prefiksy celów są akceptowane w interfejsie, a profil wymieniający tylko podsieć tunelu po prostu zostawia inne cele zwykłej trasie domyślnej. Dlatego profile pełnego tunelu używają 0.0.0.0/0 i dlatego wg-quick instaluje też reguły zapory, gdy może.

Trzymaj punkt końcowy tunelu poza odrzucaniem

Zewnętrzny adres punktu końcowego musi pozostać osiągalny przez interfejs fizyczny. Odrzucanie, które przechwytuje też ten adres, uniemożliwia wyjście uzgadniania, a tunel nigdy nie wstaje, co wygląda jak awaria VPN, a nie polityka routingu. Sprawdź trasę do punktu końcowego przed zmianą i po niej.

Dostęp administracyjny należy do tego samego przeglądu. Jeśli jedyną drogą do routera lub klienta jest tunel, zbyt szerokie odrzucanie może odciąć cię od maszyny, która pozwoliłaby je usunąć. Utrzymuj udokumentowaną trasę pozapasmową, konsolę lub zaplanowane wycofanie.

IPv6 potrzebuje własnego wpisu i własnego przeglądu. Projekt, który odrzuca IPv4 do blackhole, a IPv6 zostawia na trasie domyślnej, wycieka dokładnie ten ruch, który polityka miała zatrzymać, a błąd jest niewidoczny w teście tylko z IPv4.

Wprowadzaj to etapami z timerem i wycofaniem

Zastosuj trasę z krótkim automatycznym usunięciem, aby błąd nie przetrwał restartu. Poniższe polecenia używają zakresu dokumentacyjnego; zastąp go prefiksem, który twój projekt naprawdę odrzuca:

sudo ip route replace blackhole 10.0.0.0/8
ip route get 10.1.2.3
sudo systemd-run --on-active=60 /sbin/ip route del blackhole 10.0.0.0/8

Drugie polecenie powinno zgłosić trasę blackhole i tablicę, z której pochodzi. Trzecie planuje usunięcie za minutę, co wystarcza na potwierdzenie polityki i jest dość krótkie, by odzyskać po błędzie na zdalnym hoście. Po potwierdzeniu zachowania uczyń wpis trwałym przez to samo zarządzanie konfiguracją, które posiada inne trasy.

Zamknij zmianę, zapisując prefiks, tablicę, rodzinę adresów i metodę wycofania. Odrzucanie jest świadomym wyjątkiem w projekcie routingu, a następny inżynier musi wiedzieć, jaki ruch miało zatrzymać, zanim zdecyduje, czy nadal tam pasuje.