Kill switch zablokuje server VPN skôr, než pretečie akákoľvek prevádzka
Ktorú fázu kill switch blokuje: hľadanie koncového bodu, vonkajšiu trasu, spiatočnú cestu a zastarané výnimky pre partnerov — s počítadlami namiesto dohadov.
Kill switche zlyhávajú v smere, ktorý ľudia neočakávajú: sú postavené tak, aby blokovali prevádzku, kým je tunel dole, a pakety, ktoré tunel stavajú, sú samy prevádzkou. V tom je celá chyba. Sada pravidiel, ktorá zahadzuje všetko, čo neodchádza tunelom, zahadzuje aj handshake, ktorý by ho mal zdvihnúť, takže klient skúša znova v slučke a chyba sa pripíše tej fáze, ktorá sa kontroluje prvá. Pred rozšírením firewallu zistite, ktorá z troch fáz sa odmieta: hľadanie mena, vonkajší paket k partnerovi alebo odpoveď, ktorá sa vracia.
Ako na sebe tunel a jeho vlastná doprava závisia
Čítajte VPN klienta ako dva sieťové stavy, ktoré zdieľajú jednu cestu socketu. Kým tunel neexistuje, klient otvorí socket na fyzickom adaptéri a posiela šifrované rámce na adresu a port partnera. Až keď táto výmena uspeje, vytvorí tunelové zariadenie a nainštaluje trasy. Kill switch je politika o druhom stave, napísaná tak široko, že platí pre oba.
Pravidlá založené na rozhraní sú obvyklá forma: prijmite to, čo odchádza cez tun0 alebo wg0, zvyšok výstupnej cesty zahoďte. Taká formulácia nedokáže vyňať vlastné spojenie klienta so serverom, takže správna implementácia túto výnimku pridáva výslovne, a vy tiež, keď píšete pravidlá ručne. Pravidlá pre jednotlivé aplikácie v Windows a macOS časť toho obchádzajú tým, že porovnávajú proces namiesto rozhrania, ale proces sa napriek tomu musí dostať von skôr, než tunel existuje.
Tri fázy v poradí, v akom nastávajú
Prvá fáza je rozlíšenie. Keď profil ukladá meno hostiteľa namiesto doslovnej adresy, klient potrebuje odpoveď DNS skôr, než čokoľvek odošle. Profil, ktorý smeruje DNS na resolver tunela, vytvára slepú uličku: resolver je dostupný len cez tunel, ktorý má hľadanie umožniť. Rozlíšenie mimo tunela alebo pripnutie koncového bodu k adrese túto dvojznačnosť odstraňuje.
Druhá fáza je vonkajší paket, ktorý musí prežiť najprv smerovanie a potom firewall, presne v tomto poradí. wireguard-tools zabezpečuje smerovaciu polovicu tohto pre WireGuard tým, že označí vlastné pakety a pridá pravidlo politiky, aby preskočili predvolenú trasu, ktorú práve nainštaloval; manuálová stránka wg-quick opisuje toto pravidlo a tabuľku, ktorú používa. Obnovte toto smerovanie ručne alebo nechajte druhý nástroj prepísať pravidlá, a označené pakety môžu byť poslané späť do tunela, ktorý majú vytvoriť.
Tretia fáza je spiatočná cesta. Handshake bez odpovede nie je dôkazom zahadzovania na výstupe; je rovnako zlučiteľný s prichádzajúcim pravidlom servera alebo zariadením NAT, ktoré zabudlo mapovanie. Oddeľte to, než sa dotknete 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 |
Klienti zaznamenávajú príznak, ktorý zistia, nie fázu, ktorá zlyhala, takže tabuľka je zvyčajne rýchlejšia ako log.
Počítadlá rozhodujú rýchlejšie ako logy
V Linuxe, nft list ruleset alebo iptables -vnL OUTPUT vypisuje počítadlo paketov pre každé pravidlo. Pripojte sa raz, nechajte to zlyhať a potom znova prečítajte počítadlá. Pravidlo, ktorého počítadlo sa pohlo, je pravidlo, do ktorého narazil handshake; ak sa nikde nič nepohlo, paket sa k firewallu nikdy nedostal. Videl som sadu pravidiel zahodiť jej vlastný handshake, a povedali to len počítadlá.
Aby ste odlíšili nikdy sa nedostal k firewallu od nikdy neopustil hostiteľa, sledujte samotné rozhranie. ip -s link show dev wlan0 hlási odoslané pakety a tcpdump -ni wlan0 udp port 51820 zobrazuje rámce. Ak zostane ploché, kým klient skúša znova, porucha je nad netfilter: chýbajúca trasa k partnerovi, pravidlo politiky mieri do zariadenia, ktoré ešte neexistuje, alebo chyba socketu, ktorú klient prehĺta.
Testujte výnimky na dokumentačných adresách ako 203.0.113.10, aby omyl nemohol sondovať cudzieho hostiteľa.
Zastaraná výnimka koncového bodu sa číta ako výpadok servera
Najzavádzajúcejšia verzia sa objaví po zmene adresy partnera: služba dynamických adries ju presunula, hostiteľ bol prestavaný alebo je výstupná adresa vašej siete iná. Výnimka stále uvádza starú adresu, takže pakety na novú padnú pod pravidlo zahadzovania. Rovnaká konfigurácia fungovala včera, a preto ľudia začínajú diagnostikou servera.
Meno hostiteľa v pravidle firewallu vás nezachráni. V nftables sa meno rozlíši pri načítaní sady pravidiel, takže pripne adresu, ktorá v tej chvíli existovala, a zostarne ako doslovná. Trvalým riešením je aktualizovať výnimku, keď sa koncový bod zmení, a držať ju úzku: jedna adresa partnera, jeden transportný port. Rozsah dostatočne široký na to, aby prežil zmenu adresy, je dosť široký aj na to, aby prepustil nesúvisiacu prevádzku.
Keď kill switch beží na hostiteľovi servera
Rovnaká závislosť existuje na druhom konci a tam sa prehliadne ľahšie. Ak stroj, ktorý slúži ako váš VPN server, tiež spúšťa desktopového klienta s kill switchom alebo profil firewallu skopírovaný z notebooku, jeho pravidlá zahadzovania platia na službu, ktorá tunely ukončuje. Odpovede na handshake klienta sa zahadzujú, takže každý klient sa nedokáže pripojiť, kým server vyzerá zdravo a jeho tunelové rozhranie zostáva nevyužité.
Tento hostiteľ potrebuje tri úzke povolenia pred zahadzovaním: port na počúvanie na fyzickom rozhraní, tunelové rozhranie pre dešifrovanú prevádzku a preposielanie z tunela k tomu, čo majú klienti dosiahnuť. Prečítajte nainštalovanú sadu pomocou nft list ruleset, iptables -S, alebo pfctl -sr , než čokoľvek zmeníte, a pamätajte, že uložená sada pravidiel prežije reštart, takže chyba tam prežije proces, ktorý ju urobil.
Poradie obnovy, ktoré udrží stroj zatvorený
Pracujte od profilu von. Prečítajte adresu a port partnera, ktoré klient používa, overte, že sa meno hostiteľa rozlíši bez tunela, a potom pridajte jednu výnimku pre túto adresu a port len na fyzickom adaptéri. Pripojte sa znova a sledujte počítadlo odosielania; dokončený handshake je signál, že druhá fáza je opravená.
Zvyšok politiky zahadzovania nechajte pri testovaní na mieste. Neškodná kontrola je skúsiť spojenie s nesúvisiacou dokumentačnou adresou a overiť, že stále vyprší, čo ukazuje, že kill switch funguje, a nie že je vypnutý. Keď sa tunel ustáli, výnimku utiahnite, a nenechávajte trvalé povolenie všetkého pre klientsky binárnik len preto, že je to pohodlné.
Ak tunel naskočí a aplikácia stále zlyháva, zostávajúce fázy nie sú táto: rozdelený DNS, MTU a smerovanie po aplikáciách každé dávajú pripojený tunel s pokazenou prevádzkou a každé má inú prvú kontrolu.