Kill switch blokerer VPN-serveren, før der flyder trafik
Hvilken fase en kill switch blokerer: opslag af endepunkt, ydre rute, returvej og forældede peer-undtagelser — med tællere i stedet for gæt.
Kill switches fejler i en retning, folk ikke forventer: de er bygget til at blokere trafik, mens tunnelen er nede, og de pakker, der bygger tunnelen, er selv trafik. Det er hele fejlen. Et regelsæt, der dropper alt, som ikke forlader gennem tunnelen, dropper også det håndtryk, der skulle rejse den, så klienten prøver igen i en løkke, og fejlen tilhører den fase, der tjekkes først. Før du udvider en firewall, find ud af, hvilken af tre faser der afvises: navneopslaget, den ydre pakke til peeren eller svaret, der kommer tilbage.
Hvordan tunnelen og dens egen transport afhænger af hinanden
Læs en VPN-klient som to netværkstilstande, der deler én sokkelsti. Før tunnelen findes, åbner klienten en sokkel på den fysiske adapter og sender krypterede rammer til peerens adresse og port. Først når den udveksling lykkes, opretter den tunneleenheden og installerer ruter. En kill switch er en politik om den anden tilstand, skrevet så bredt, at den gælder for begge.
Interfacebaserede regler er den sædvanlige form: accepter det, der forlader gennem tun0 eller wg0, drop resten af udgangsstien. Den formulering kan ikke fritage klientens egen forbindelse til serveren, så en korrekt implementering tilføjer den undtagelse eksplicit, og det gør du også, når du skriver regler i hånden. Per-applikationsregler på Windows og macOS omgår en del af dette ved at matche en proces i stedet for et interface, men processen skal stadig ud, før tunnelen findes.
Tre faser, i den rækkefølge de sker
Den første fase er opslag. Når profilen gemmer et værtsnavn i stedet for en bogstavelig adresse, har klienten brug for et DNS-svar, før den kan sende noget. En profil, der peger DNS mod tunnelens resolver, skaber en blindgyde: resolveren kan kun nås gennem den tunnel, som opslaget skulle muliggøre. At slå op uden for tunnelen eller fastlåse endepunktet til en adresse fjerner uklarheden.
Den anden fase er den ydre pakke, som skal overleve routing og derefter firewall, i den rækkefølge. wireguard-tools klarer routinghalvdelen af dette for WireGuard ved at markere sine egne pakker og tilføje en politikregel, så de springer den standardrute over, den netop har installeret; manualsiden for wg-quick beskriver den regel og den tabel, den bruger. Genopbyg den routing i hånden, eller lad et andet værktøj omskrive reglerne, og de markerede pakker kan blive sendt tilbage i den tunnel, de skal oprette.
Den tredje fase er returvejen. Et håndtryk uden svar er ikke bevis for et udgående drop; det er lige så foreneligt med en indgående serverregel eller en NAT-enhed, der har glemt mappingen. Skil det ad, før du rører klienten.
| 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 |
Klienter logger det symptom, de opdager, ikke den fase, der fejlede, så tabellen er normalt hurtigere end loggen.
Tællere afgør hurtigere end logs
På Linux, nft list ruleset eller iptables -vnL OUTPUT udskriver en pakketæller for hver regel. Forbind én gang, lad det fejle, og læs derefter tællerne igen. En regel, hvis tæller har flyttet sig, er en regel, som håndtrykket ramte; hvis intet har flyttet sig nogen steder, nåede pakken aldrig firefallen. Jeg har set et regelsæt droppe sit eget håndtryk, og kun tællerne sagde det.
For at skelne aldrig nåede firefallen fra aldrig forlod værten, hold øje med interfacet selv. ip -s link show dev wlan0 rapporterer sendte pakker, og tcpdump -ni wlan0 udp port 51820 viser rammerne. Hvis den står fladt, mens klienten prøver igen, er fejlen opstrøms for netfilter: en manglende peer-rute, en politikregel der peger ind i en enhed, der ikke findes endnu, eller en sokkel-fejl, som klienten sluger.
Test undtagelser mod dokumentationsadresser som 203.0.113.10, så en fejl ikke kan undersøge en andens vært.
En forældet endepunktundtagelse læses som et servernedbrud
Den mest vildledende version dukker op, efter at peerens adresse ændres: en tjeneste med dynamiske adresser har flyttet den, værten er genopbygget, eller dit netværks udgangsadresse er en anden. Undtagelsen nævner stadig den gamle adresse, så pakker til den nye rammer drop-reglen. Den samme konfiguration virkede i går, og derfor begynder folk med at fejlfinde serveren.
Et værtsnavn inde i en firewallregel redder dig ikke. I nftables slås navnet op, når regelsættet indlæses, så det fastlåser den adresse, der fandtes i det øjeblik, og bliver forældet som en bogstavelig. Den holdbare løsning er at opdatere undtagelsen, når endepunktet ændres, og holde den smal: én peer-adresse, én transportport. Et interval, der er bredt nok til at overleve en adresseændring, er også bredt nok til at slippe uvedkommende trafik ud.
Når kill switchen kører på serverværten
Den samme afhængighed findes i den anden ende, og der er den lettere at overse. Hvis maskinen, der fungerer som din VPN-server, også kører en desktopklient med kill switch eller en firewallprofil kopieret fra en bærbar, gælder dens drop-regler for den tjeneste, der afslutter tunnelerne. Svar på et klienthåndtryk bliver droppet, så hver klient fejler med at forbinde, mens serveren ser sund ud, og dens tunnelinterface står ubrugt.
Den vært har brug for tre smalle accepts foran droppet: lytteporten på det fysiske interface, tunnelinterfacet til dekrypteret trafik og videresendelse fra tunnelen mod det, klienterne skal kunne nå. Læs det installerede sæt med nft list ruleset, iptables -S, eller pfctl -sr , før du ændrer noget, og husk, at et gemt regelsæt overlever genstart, så en fejl der overlever den proces, der lavede den.
Gendannelsesrækkefølge, der holder maskinen lukket
Arbejd udad fra profilen. Læs peerens adresse og port, som klienten bruger, bekræft, at værtsnavnet slås op uden tunnelen, og tilføj så én undtagelse for den adresse og port kun på den fysiske adapter. Forbind igen, og hold øje med sendetælleren; et fuldført håndtryk er signalet om, at fase to er rettet.
Lad resten af drop-politikken blive på plads under testen. En uskyldig kontrol er at forsøge en forbindelse til en uvedkommende dokumentationsadresse og bekræfte, at den stadig timer ud, hvilket viser, at kill switchen virker, snarere end at den er slået fra. Stram undtagelsen, når tunnelen er stabil, og lad ikke en permanent tillad-alt for klientprogrammet blive liggende, fordi det er bekvemt.
Hvis tunnelen kommer op, og applikationen stadig fejler, er de resterende faser ikke denne: opdelt DNS, MTU og per-applikations-routing giver hver en tilsluttet tunnel med brudt trafik, og hver har et forskelligt første tjek.