Dlaczego kill switch ucina ruch przy zmianie serwera

Wybierasz serwer, który wygląda na bliższy, klikasz połącz, a przeglądarka przestaje wczytywać, zanim nowy tunel wstanie. Ikona przechodzi w stan łączenia i tkwi tam, aż każda karta przekroczy limit czasu. Ta pauza to zwykle kill switch działający zgodnie z projektem: ruch jest blokowany, dopóki klient nie ma tunelu, przez który mógłby go wysłać. To, czy pauza jest do przyjęcia, zależy od tego, co klient robi w tych sekundach, i od tego, czy blokada zostaje zdjęta, gdy twierdzi, że tak się stało.

Co klient robi między dwoma serwerami

Zmiana punktu końcowego to kilka kroków, a nie jeden przełącznik. Klient rozbiera bieżący tunel, aktualizuje swoje reguły blokowania, rozwiązuje i osiąga nowy punkt końcowy poza tunelem, a następnie instaluje nowe trasy i zdejmuje blokadę. Luka, którą odczuwasz, leży między pierwszym a ostatnim krokiem.

Kolejność jest tu ważniejsza niż szybkość. Jeśli reguły blokowania wejdą przed wyjątkiem dla nowego punktu końcowego, klient nie może dokończyć uzgadniania i pozostaje na łączeniu do przekroczenia limitu czasu. Jeśli wyjątek jest kopią adresu starego serwera, nowe uzgadnianie wygląda jak każdy inny pakiet wychodzący i zostaje odrzucone. Oba przypadki wyglądają w przeglądarce identycznie, dlatego zmiana, która wraca do normy po sześciu sekundach, i ta, która nie wraca nigdy, mogą mieć tę samą przyczynę.

Nowy punkt końcowy potrzebuje dziury w blokadzie

Aby zbudować tunel, klient musi wysyłać pakiety na adres i port nowego serwera przez interfejs fizyczny, na przykład UDP 51820 dla typowego profilu WireGuard albo 1194 i 443 dla OpenVPN, cokolwiek określa twój profil. Ten ruch nie znajduje się wewnątrz tunelu, który dopiero powstanie, więc blokada dla całego urządzenia go połyka, chyba że istnieje pasująca reguła zezwolenia.

Profile oparte na nazwie hosta dodają drugi warunek: samo wyszukiwanie. Jeśli klient rozwiąże punkt końcowy, zanim blokada się podniesie, może użyć adresu z pamięci podręcznej, ale gdy profil zmieni adresy albo wpis w pamięci podręcznej się zestarzeje, uzgadnianie trafia na adres, którego reguła zezwolenia nie obejmuje. IPv6 to ujawnia, bo punkt końcowy z dwoma stosami może publikować zarówno rekord A, jak i AAAA, a reguła zezwolenia obejmująca tylko adres v4 zostawia klienta ponawiającego próby wobec zablokowanego adresu v6.

Nazwy opcji i wartości domyślne różnią się w zależności od klienta i wersji, więc przeczytaj udokumentowaną listę dla swojego, zamiast zgadywać ze zrzutów ekranu. Dokumentacja ustawień OpenVPN Connect pod adresem openvpn.net/connect-docs/app-settings-windows jest jednym z przykładów tego, jak klient opisuje swoje opcje blokady i tunelu dzielonego.

Fail-closed to maszyna stanów, nie przełącznik

Większość klientów wyraża blokadę jako politykę zapory w trzech stanach: tunel w górze, ruch idzie przez tunel i blokady nie ma; tunel w dole, blokada jest aktywna; oraz przejście, gdy blokada jest aktywna plus tymczasowe wyjątki dla punktu końcowego. Właśnie w trzecim stanie żyją błędy, bo musi się on zmienić dwa razy w ciągu kilku sekund, a brak wyjścia z niego wygląda dokładnie jak trwała blokada.

Mechanizm różni się w zależności od platformy, a awaria także. Filtry Windows Filtering Platform mają wagi, więc filtr blokujący, który przewyższa twoje zezwolenie, nadal odrzuca pakiety, mimo że zezwolenie istnieje, a filtry pozostawione przez zabity proces klienta mogą utrzymywać maszynę offline po zniknięciu aplikacji. Klienci macOS zwykle zapisują reguły pf do kotwicy, gdzie kolejność reguł i szybkie decyzje decydują, która reguła obowiązuje. Klienci Linuksa zwykle zarządzają łańcuchem nftables lub iptables z polityką drop i jawnymi zezwoleniami dla punktu końcowego, interfejsu tunelu i loopback. Tryb always-on VPN w Androidzie z opcją blokowania połączeń bez VPN jest najostrzejszy w grupie, bo system stosuje blokadę do całego urządzenia, a nie do poszczególnych aplikacji.

WireGuard zasługuje na własną uwagę, bo AllowedIPs to selektor tras, a nie bloker. Decyduje, które cele wchodzą do tunelu; nie robi nic, by powstrzymać pakiet bez tunelu przed wyjściem przez Wi-Fi. W konfiguracji tylko z WireGuardem i bez reguły zapory kill switch jest w rzeczywistości brakiem trasy, a po odrzuconym uzgadnianiu przez interfejs fizyczny może wyjść prawdziwy pakiet.

Mierz lukę, zamiast patrzeć na ikonę

Obserwuj pakiety, a nie lampkę stanu. W Linuksie uruchom w jednym terminalu powolny ping do publicznego adresu, a w drugim przechwyć port transportowy tunelu na interfejsie fizycznym:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Przełącz serwer w kliencie, gdy oba działają. Trzy rzeczy są ważne: jak długo pingi się zatrzymują, czy przechwycenie pokazuje uzgadnianie docierające do nowego punktu końcowego i czy ruch wraca przed czy po zmianie stanu klienta na połączony. Jeśli luka w pingach kończy się pierwsza, to albo blokada została zdjęta za wcześnie, albo tunel stoi, zanim wskaźnik to przyzna. Jeśli luka kończy się później, wskaźnik jest zbyt optymistyczny.

W Windows netsh wfp show state zapisuje zrzut, w którym można szukać filtrów blokujących wciąż obecnych, gdy klient twierdzi, że jest rozłączony. W macOS sudo pfctl -sr wymienia wczytane reguły i ich kolejność. Połącz którykolwiek zrzut z własnym logiem klienta; os czasu z twojego pinga mówi, czy blokada skończyła się późno, czy nigdy.

Normalne zaciemnienie a zawieszona blokada

Pewne przerwanie jest sensem tej funkcji, więc najpierw dokonaj triage'u, zanim zmienisz jakiekolwiek ustawienie:

Jeśli trafisz w drugi lub piąty wiersz, nie wyłączaj kill switcha do testu, bo to zamienia błąd routingu w wyciek. Uruchom ponownie usługę klienta albo zrestartuj maszynę tam, gdzie filtry przeżywają zabicie procesu, i sprawdź, czy blokada znika. Jeśli znika, wina leży w sprzątaniu podczas przełączenia, a nie w samej blokadzie.

Przed kolejnym przełączeniem potwierdź cztery rzeczy: zezwolenie dla punktu końcowego obejmuje każdą rodzinę adresów, którą rozwiązuje twój profil, log klienta pokazuje ukończone przejście, twój test ping mierzy lukę, a nie ikonę, i zamknięcie klienta przywraca normalną łączność. Kill switch, który trzyma podczas przełączenia i puszcza po nim, robi swoje. Ten, który puszcza wcześnie albo nigdy, jest wart debugowania.