Kill switch blokkerer VPN-tenaren før nokon trafikk flyt
Kva fase ein kill switch blokkerer: endepunktoppslag, ytre rute, returveg og utdaterte peer-unntak — med teljarar i staden for gjettingar.
Kill switchar feilar i ei retning folk ikkje ventar: dei er bygde for å blokkere trafikk medan tunnelen er nede, og pakkane som byggjer tunnelen er sjølve trafikk. Det er heile feilen. Eit regelsett som droppar alt som ikkje går ut gjennom tunnelen, droppar òg handtrykket som skulle reise han, så klienten prøver på nytt i ei løkke, og feilen høyrer til den fasen som blir sjekka først. Før du utvidar ein brannmur, finn ut kva av tre fasar som blir avvist: namneoppslaget, den ytre pakka til peeren eller svaret som kjem tilbake.
Korleis tunnelen og den eigne transporten hans er avhengige av kvarandre
Les ein VPN-klient som to nettverkstilstandar som deler éin sokkelbane. Før tunnelen finst, opnar klienten ein sokkel på den fysiske adapteren og sender krypterte rammer til adressa og porten til peeren. Først når den utvekslinga lukkast, opprettar han tunneleininga og installerer ruter. Ein kill switch er ein policy om den andre tilstanden, skriven så breitt at han gjeld begge.
Interfacebaserte reglar er den vanlege forma: godta det som går ut gjennom tun0 eller wg0, dropp resten av utgangsbanen. Den formuleringa kan ikkje unnta den eigne sambandet til klienten med tenaren, så ein korrekt implementasjon legg til det unntaket eksplisitt, og det gjer du òg når du skriv reglar for hand. Reglar per applikasjon på Windows og macOS unngår ein del av dette ved å matche ein prosess i staden for eit interface, men prosessen må framleis ut før tunnelen finst.
Tre fasar, i den rekkjefølgja dei skjer
Den første fasen er oppslag. Når profilen lagrar eit vertsnamn i staden for ei bokstaveleg adresse, treng klienten eit DNS-svar før han kan sende noko. Ein profil som peikar DNS mot oppløysaren til tunnelen, lagar ein blindgate: oppløysaren er berre tilgjengeleg gjennom tunnelen som oppslaget skulle gjere mogeleg. Å slå opp utanfor tunnelen, eller å feste endepunktet til ei adresse, fjernar uklarleiken.
Den andre fasen er den ytre pakka, som må overleve først ruting og deretter brannmur, i den rekkjefølgja. wireguard-tools tek seg av rutingshalvdelen av dette for WireGuard ved å merke sine eigne pakkar og leggje til ein policyregel slik at dei hoppar over standardruta han nettopp installerte; manualsida for wg-quick skildrar den regelen og tabellen han brukar. Bygg den rutinga på nytt for hand, eller lat eit anna verktøy skrive om reglane, og dei merkte pakkane kan bli sende tilbake i tunnelen dei skal opprette.
Den tredje fasen er returvegen. Eit handtrykk utan svar er ikkje prov for eit utgåande dropp; det er like foreinleg med ein inngåande tenarregel eller ei NAT-eining som gløymde mappinga. Skil 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 |
Klientar loggar symptomet dei oppdagar, ikkje fasen som feila, så tabellen er vanlegvis raskare enn loggen.
Teljarar avgjer raskare enn loggar
På Linux, nft list ruleset eller iptables -vnL OUTPUT skriv ut ein pakketeljar per regel. Kople til éin gong, lat det feile, og les deretter teljarane igjen. Ein regel der teljaren har flytta seg, er ein regel handtrykket trefte; om ingenting har flytta seg nokon stad, nådde pakka aldri brannmuren. Eg har sett eit regelsett droppe sitt eige handtrykk, og berre teljarane sa det.
For å skilje aldri nådde brannmuren frå aldri forlét verten, fylg med på interfacet sjølv. ip -s link show dev wlan0 rapporterer sende pakkar, og tcpdump -ni wlan0 udp port 51820 viser rammene. Om han står flatt medan klienten prøver på nytt, ligg feilen over netfilter: ei manglande peer-rute, ein policyregel som peikar på ei eining som ikkje finst enno, eller ein sokkel-feil som klienten svelgjer.
Test unntak mot dokumentasjonsadresser som 203.0.113.10, slik at ein feil ikkje kan undersøkje verten til nokon annan.
Eit utdatert endepunktunntak blir lese som eit tenarutfall
Den mest villeiande versjonen dukkar opp etter at adressa til peeren er endra: ein teneste for dynamiske adresser har flytta henne, verten er bygd på nytt, eller utgangsadressa til nettverket ditt er ei anna. Unntaket nemner framleis den gamle adressa, så pakkar til den nye treffer droppregelen. Den same konfigurasjonen virka i går, og derfor byrjar folk med feilsøking av tenaren.
Eit vertsnamn inne i ein brannmurregel reddar deg ikkje. I nftables blir namnet løyst når regelsettet blir lasta, så det festar den adressa som fanst i det augneblinken og blir utdatert som ei bokstaveleg. Den varige løysinga er å oppdatere unntaket når endepunktet endrar seg, og halde det smalt: éi peer-adresse, éin transportport. Eit område som er breitt nok til å overleve ei adresseendring, er òg breitt nok til å sleppe ut uvedkommande trafikk.
Når kill switchen køyrer på tenarverten
Den same avhengigheita finst i den andre enden, og der er ho lettare å oversjå. Om maskina som tener som VPN-tenaren din òg køyrer ein skrivebordsklient med kill switch, eller ein brannmurprofil kopiert frå ein berbar, gjeld droppreglane hennar for tenesta som avsluttar tunnelane. Svar på eit klienthandtrykk blir droppa, så kvar klient feilar med å kople til medan tenaren ser sunn ut og tunnelinterfacet står ubrukt.
Den verten treng tre smale godtakingar før droppet: lyttporten på det fysiske interfacet, tunnelinterfacet for dekryptert trafikk og videresending frå tunnelen mot det klientane skal kunne nå. Les det installerte settet med nft list ruleset, iptables -S, eller pfctl -sr , før du endrar noko, og hugs at eit lagra regelsett overlever omstart, så ein feil der overlever prosessen som laga han.
Gjenopprettingsrekkjefølgje som held maskina lukka
Arbeid utover frå profilen. Les adressa og porten til peeren som klienten brukar, stadfest at vertsnamnet blir løyst utan tunnelen, og legg så til eitt unntak for den adressa og porten berre på den fysiske adapteren. Kople til igjen og fylg med på sendeteljaren; eit fullført handtrykk er signalet om at fase to er reparert.
Lat resten av droppolitikken stå på plass medan du testar. Ein ufarleg kontroll er å prøve ei tilkopling til ei uvedkomande dokumentasjonsadresse og stadfeste at ho framleis timar ut, noko som viser at kill switchen verkar og ikkje er slått av. Stram unntaket når tunnelen er stabil, og lat ikkje ein permanent tillat-alt-regel for klientprogrammet bli liggjande berre fordi det er praktisk.
Om tunnelen kjem opp og applikasjonen framleis feilar, er dei resterande fasane ikkje denne: delt DNS, MTU og ruting per applikasjon gir kvar ein tilkopla tunnel med øydelagd trafikk, og kvar har ein annan første sjekk.