Kill switch blokuje serwer VPN, zanim popłynie jakikolwiek ruch
Który etap blokuje kill switch: wyszukiwanie punktu końcowego, trasę zewnętrzną, drogę powrotną i nieaktualne wyjątki dla partnerów — z licznikami zamiast domysłów.
Kill switche zawodzą w kierunku, którego ludzie się nie spodziewają: są zbudowane tak, by blokować ruch, gdy tunel jest wyłączony, a pakiety budujące tunel same są ruchem. To cały błąd. Zestaw reguł, który odrzuca wszystko, co nie wychodzi przez tunel, odrzuca też uścisk dłoni, który miał go podnieść, więc klient ponawia próbę w pętli, a błąd przypisuje się temu etapowi, który jest sprawdzany pierwszy. Zanim poszerzysz zaporę, ustal, który z trzech etapów jest odrzucany: wyszukiwanie nazwy, pakiet zewnętrzny do partnera czy odpowiedź, która wraca.
Jak tunel i jego własny transport zależą od siebie
Czytaj klienta VPN jako dwa stany sieci, które dzielą jedną ścieżkę gniazda. Zanim tunel istnieje, klient otwiera gniazdo na fizycznym adapterze i wysyła zaszyfrowane ramki na adres i port partnera. Dopiero gdy ta wymiana się powiedzie, tworzy urządzenie tunelowe i instaluje trasy. Kill switch to polityka dotycząca drugiego stanu, napisana tak szeroko, że dotyczy obu.
Reguły oparte na interfejsie to zwykła forma: akceptuj to, co wychodzi przez tun0 lub wg0, odrzuć resztę ścieżki wyjściowej. To sformułowanie nie potrafi wyłączyć własnego połączenia klienta z serwerem, więc poprawna implementacja dodaje ten wyjątek jawnie, i ty też, gdy piszesz reguły ręcznie. Reguły dla poszczególnych aplikacji w Windows i macOS omijają część tego, dopasowując proces zamiast interfejsu, ale proces i tak musi wyjść, zanim tunel powstanie.
Trzy etapy, w kolejności, w jakiej następują
Pierwszy etap to rozwiązywanie. Gdy profil przechowuje nazwę hosta zamiast dosłownego adresu, klient potrzebuje odpowiedzi DNS, zanim cokolwiek wyśle. Profil, który kieruje DNS do resolvera tunelu, tworzy impas: resolver jest osiągalny tylko przez tunel, który wyszukiwanie miało umożliwić. Rozwiązywanie poza tunelem albo przypięcie punktu końcowego do adresu usuwa tę niejednoznaczność.
Drugi etap to pakiet zewnętrzny, który musi przetrwać najpierw trasowanie, a potem zaporę, w tej kolejności. wireguard-tools zajmuje się trasowaniem w przypadku WireGuard, oznaczając własne pakiety i dodając regułę polityki, aby omijały domyślną trasę, którą właśnie zainstalował; strona podręcznika wg-quick opisuje tę regułę i tabelę, której używa. Odbuduj to trasowanie ręcznie albo pozwól drugiemu narzędziu przepisać reguły, a oznaczone pakiety mogą zostać odesłane do tunelu, który miały utworzyć.
Trzeci etap to droga powrotna. Uścisk dłoni bez odpowiedzi nie jest dowodem odrzucenia na wyjściu; równie dobrze pasuje do reguły wejściowej serwera albo urządzenia NAT, które zapomniało mapowania. Oddziel to, zanim dotkniesz klienta.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Klienci zapisują objaw, który wykryją, a nie etap, który zawiódł, więc tabela jest zwykle szybsza niż log.
Liczniki decydują szybciej niż logi
W Linuxie, nft list ruleset lub iptables -vnL OUTPUT wypisuje licznik pakietów na regułę. Połącz się raz, pozwól mu zawieść, a potem ponownie odczytaj liczniki. Reguła, której licznik się przesunął, to reguła trafiona przez uścisk dłoni; jeśli nigdzie nic się nie przesunęło, pakiet nigdy nie dotarł do zapory. Widziałem zestaw reguł, który odrzucił własny uścisk dłoni, i powiedziały o tym tylko liczniki.
Aby odróżnić nigdy nie dotarł do zapory od nigdy nie opuścił hosta, obserwuj sam interfejs. ip -s link show dev wlan0 raportuje wysłane pakiety, a tcpdump -ni wlan0 udp port 51820 pokazuje ramki. Jeśli pozostaje płaski, gdy klient ponawia, usterka jest powyżej netfilter: brakuje trasy do partnera, reguła polityki wskazuje urządzenie, którego jeszcze nie ma, albo błąd gniazda, który klient połyka.
Testuj wyjątki na adresach dokumentacyjnych, takich jak 203.0.113.10, aby przeoczenie nie mogło sondować hosta kogoś innego.
Nieaktualny wyjątek punktu końcowego czyta się jak awaria serwera
Najbardziej myląca wersja pojawia się po zmianie adresu partnera: usługa adresów dynamicznych go przeniosła, host został przebudowany albo adres wyjściowy twojej sieci jest inny. Wyjątek nadal wymienia stary adres, więc pakiety do nowego trafiają na regułę odrzucania. Ta sama konfiguracja działała wczoraj, i dlatego ludzie zaczynają od diagnozy serwera.
Nazwa hosta wewnątrz reguły zapory cię nie uratuje. W nftables nazwa jest rozwiązywana przy ładowaniu zestawu reguł, więc przypina adres, który istniał w tej chwili, i starzeje się jak adres dosłowny. Trwałym rozwiązaniem jest aktualizowanie wyjątku, gdy zmienia się punkt końcowy, i trzymanie go wąsko: jeden adres partnera, jeden port transportowy. Zakres wystarczająco szeroki, by przetrwać zmianę adresu, jest też wystarczająco szeroki, by wypuścić niepowiązany ruch.
Gdy kill switch działa na hoście serwera
Ta sama zależność istnieje po drugiej stronie, i tam łatwiej ją przeoczyć. Jeśli maszyna pełniąca rolę twojego serwera VPN uruchamia też klienta pulpitowego z kill switchem albo profil zapory skopiowany z laptopa, jego reguły odrzucania dotyczą usługi, która kończy tunele. Odpowiedzi na uścisk dłoni klienta są odrzucane, więc każdy klient nie może się połączyć, podczas gdy serwer wygląda zdrowo, a jego interfejs tunelu stoi nieużywany.
Ten host potrzebuje trzech wąskich zgód przed odrzucaniem: portu nasłuchu na interfejsie fizycznym, interfejsu tunelu dla odszyfrowanego ruchu i przekazywania z tunelu do tego, co klienci mają osiągnąć. Odczytaj zainstalowany zestaw za pomocą nft list ruleset, iptables -S, albo pfctl -sr , zanim cokolwiek zmienisz, i pamiętaj, że zapisany zestaw reguł przeżywa restart, więc błąd tam przeżywa proces, który go stworzył.
Kolejność naprawy, która trzyma maszynę zamkniętą
Pracuj od profilu na zewnątrz. Odczytaj adres i port partnera, których używa klient, potwierdź, że nazwa hosta rozwiązuje się bez tunelu, a następnie dodaj jeden wyjątek dla tego adresu i portu tylko na fizycznym adapterze. Połącz się ponownie i obserwuj licznik wysyłania; ukończony uścisk dłoni to sygnał, że drugi etap jest naprawiony.
Zostaw resztę polityki odrzucania na miejscu podczas testów. Nieszkodliwym sprawdzeniem jest próba połączenia z niepowiązanym adresem dokumentacyjnym i potwierdzenie, że nadal kończy się przekroczeniem czasu, co pokazuje, że kill switch działa, a nie że jest wyłączony. Dociśnij wyjątek, gdy tunel będzie stabilny, i nie zostawiaj trwałego pozwolenia na wszystko dla programu klienta tylko dlatego, że jest wygodne.
Jeśli tunel wstanie, a aplikacja nadal zawodzi, pozostałe etapy to nie ten: podzielony DNS, MTU i trasowanie dla poszczególnych aplikacji każde daje połączony tunel z zepsutym ruchem, a każde ma inne pierwsze sprawdzenie.