Kill switch blokkerer VPN-serveren før noen trafikk flyter
Hvilken fase en kill switch blokkerer: endepunktoppslag, ytre rute, returvei og utdaterte peer-unntak — med tellere i stedet for gjetninger.
Kill switcher feiler i en retning folk ikke forventer: de er bygget for å blokkere trafikk mens tunnelen er nede, og pakkene som bygger tunnelen er selv trafikk. Det er hele feilen. Et regelsett som dropper alt som ikke går ut gjennom tunnelen, dropper også håndtrykket som skulle reise den, så klienten prøver på nytt i en løkke, og feilen tilhører den fasen som sjekkes først. Før du utvider en brannmur, finn ut hvilken av tre faser som avvises: navneoppslaget, den ytre pakken til peeren eller svaret som kommer tilbake.
Hvordan tunnelen og dens egen transport avhenger av hverandre
Les en VPN-klient som to nettverkstilstander som deler én sokkelbane. Før tunnelen finnes, åpner klienten en sokkel på den fysiske adapteren og sender krypterte rammer til peerens adresse og port. Først når den utvekslingen lykkes, oppretter den tunellenheten og installerer ruter. En kill switch er en policy om den andre tilstanden, skrevet så bredt at den gjelder begge.
Interfacebaserte regler er den vanlige formen: godta det som går ut gjennom tun0 eller wg0, dropp resten av utgangsbanen. Den formuleringen kan ikke unnta klientens egen forbindelse til serveren, så en korrekt implementasjon legger til det unntaket eksplisitt, og det gjør du også når du skriver regler for hånd. Regler per applikasjon på Windows og macOS unngår en del av dette ved å matche en prosess i stedet for et interface, men prosessen må fortsatt ut før tunnelen finnes.
Tre faser, i den rekkefølgen de skjer
Den første fasen er oppslag. Når profilen lagrer et vertsnavn i stedet for en bokstavelig adresse, trenger klienten et DNS-svar før den kan sende noe. En profil som peker DNS mot tunnelens oppløser, lager en blindgate: oppløseren er bare tilgjengelig gjennom tunnelen som oppslaget skulle muliggjøre. Å slå opp utenfor tunnelen, eller å feste endepunktet til en adresse, fjerner uklarheten.
Den andre fasen er den ytre pakken, som må overleve først ruting og deretter brannmur, i den rekkefølgen. wireguard-tools tar seg av rutingshalvdelen av dette for WireGuard ved å merke sine egne pakker og legge til en policyregel slik at de hopper over standardruten den nettopp installerte; manualsiden for wg-quick beskriver den regelen og tabellen den bruker. Bygg den rutingen på nytt for hånd, eller la et annet verktøy skrive om reglene, og de merkede pakkene kan bli sendt tilbake i tunnelen de skal opprette.
Den tredje fasen er returveien. Et håndtrykk uten svar er ikke bevis for et utgående dropp; det er like forenlig med en inngående serverregel eller en NAT-enhet som glemte mappingen. Skill det 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 symptomet de oppdager, ikke fasen som feilet, så tabellen er vanligvis raskere enn loggen.
Tellere avgjør raskere enn logger
På Linux, nft list ruleset eller iptables -vnL OUTPUT skriver ut en pakketeller per regel. Koble til én gang, la det feile, og les deretter tellerne igjen. En regel der telleren har flyttet seg, er en regel håndtrykket traff; hvis ingenting har flyttet seg noe sted, nådde pakken aldri brannmuren. Jeg har sett et regelsett droppe sitt eget håndtrykk, og bare tellerne sa det.
For å skille aldri nådde brannmuren fra aldri forlot verten, følg med på interfacet selv. ip -s link show dev wlan0 rapporterer sendte pakker, og tcpdump -ni wlan0 udp port 51820 viser rammene. Hvis den står flatt mens klienten prøver på nytt, ligger feilen over netfilter: en manglende peer-rute, en policyregel som peker på en enhet som ikke finnes ennå, eller en sokkel-feil som klienten svelger.
Test unntak mot dokumentasjonsadresser som 203.0.113.10, slik at en feil ikke kan undersøke noen andres vert.
Et utdatert endepunktunntak leses som et serverutfall
Den mest villedende versjonen dukker opp etter at peerens adresse er endret: en tjeneste for dynamiske adresser har flyttet den, verten er bygget på nytt, eller nettverkets utgangsadresse er en annen. Unntaket nevner fortsatt den gamle adressen, så pakker til den nye treffer droppregelen. Den samme konfigurasjonen virket i går, og derfor begynner folk med feilsøking av serveren.
Et vertsnavn inne i en brannmurregel redder deg ikke. I nftables løses navnet når regelsettet lastes, så det fester den adressen som fantes i det øyeblikket og blir utdatert som en bokstavelig. Den varige løsningen er å oppdatere unntaket når endepunktet endres, og holde det smalt: én peer-adresse, én transportport. Et område som er bredt nok til å overleve en adresseendring, er også bredt nok til å slippe ut uvedkommende trafikk.
Når kill switchen kjører på serververten
Den samme avhengigheten finnes i den andre enden, og der er den lettere å overse. Hvis maskinen som tjener som VPN-serveren din også kjører en skrivebordsklient med kill switch, eller en brannmurprofil kopiert fra en bærbar, gjelder droppreglene dens for tjenesten som avslutter tunnelene. Svar på et klienthåndtrykk blir droppet, så hver klient feiler med å koble til mens serveren ser sunn ut og tunnelinterfacet står ubrukt.
Den verten trenger tre smale godtakelser før droppet: lyttporten på det fysiske interfacet, tunnelinterfacet for dekryptert trafikk og videresending fra tunnelen mot det klientene skal kunne nå. Les det installerte settet med nft list ruleset, iptables -S, eller pfctl -sr , før du endrer noe, og husk at et lagret regelsett overlever omstart, så en feil der overlever prosessen som lagde den.
Gjenopprettingsrekkefølge som holder maskinen lukket
Arbeid utover fra profilen. Les peerens adresse og port som klienten bruker, bekreft at vertsnavnet løses uten tunnelen, og legg så til ett unntak for den adressen og porten bare på den fysiske adapteren. Koble til igjen og følg med på sendetelleren; et fullført håndtrykk er signalet om at fase to er reparert.
La resten av droppolitikken stå på plass mens du tester. En ufarlig kontroll er å forsøke en forbindelse til en uvedkommen dokumentasjonsadresse og bekrefte at den fortsatt timer ut, noe som viser at kill switchen virker og ikke er slått av. Stram unntaket når tunnelen er stabil, og ikke la en permanent tillat-alt-regel for klientprogrammet bli liggende bare fordi det er praktisk.
Hvis tunnelen kommer opp og applikasjonen fortsatt feiler, er de resterende fasene ikke denne: delt DNS, MTU og ruting per applikasjon gir hver en tilkoblet tunnel med ødelagt trafikk, og hver har en annen første sjekk.