Kill switch blockerar VPN-servern innan någon trafik flyter
Vilken fas en kill switch blockerar: endpunktsuppslag, yttre rutt, returväg och föråldrade peer-undantag — med räknare i stället för gissningar.
Kill switchar misslyckas i en riktning folk inte förväntar sig: de är byggda för att blockera trafik medan tunneln är nere, och paketen som bygger tunneln är själva trafik. Det är hela felet. En regeluppsättning som släpper allt som inte går ut genom tunneln släpper också handskakningen som skulle resa den, så klienten försöker igen i en loop och felet tillskrivs den fas som kontrolleras först. Innan du vidgar en brandvägg, ta reda på vilken av tre faser som nekas: namnsökningen, det yttre paketet till peeren eller svaret som kommer tillbaka.
Hur tunneln och dess egen transport beror av varandra
Läs en VPN-klient som två nätverkstillstånd som delar en enda socketbana. Innan tunneln finns öppnar klienten en socket på den fysiska adaptern och skickar krypterade ramar till peerens adress och port. Först när det utbytet lyckas skapar den tunnelenheten och installerar rutter. En kill switch är en policy om det andra tillståndet, skriven så brett att den gäller båda.
Interfacebaserade regler är den vanliga formen: acceptera det som går ut genom tun0 eller wg0, släpp resten av utvägen. Den formuleringen kan inte undanta klientens egen anslutning till servern, så en korrekt implementering lägger till undantaget uttryckligen, och det gör du också när du skriver regler för hand. Regler per program på Windows och macOS undviker en del av detta genom att matcha en process i stället för ett interface, men processen måste ändå ut innan tunneln finns.
Tre faser, i den ordning de inträffar
Den första fasen är uppslagning. När profilen lagrar ett värdnamn i stället för en bokstavlig adress behöver klienten ett DNS-svar innan den kan skicka något. En profil som pekar DNS mot tunnelns upplösare skapar en återvändsgränd: upplösaren går bara att nå genom tunneln som sökningen skulle möjliggöra. Att lösa upp utanför tunneln, eller att fästa endpunkten vid en adress, tar bort oklarheten.
Den andra fasen är det yttre paketet, som måste överleva först routning och sedan brandväggen, i den ordningen. wireguard-tools sköter routningshalvan av detta för WireGuard genom att märka sina egna paket och lägga till en policyregel så att de hoppar över standardrutten den just installerade; manualsidan för wg-quick beskriver den regeln och tabellen den använder. Bygg om den routningen för hand, eller låt ett andra verktyg skriva om reglerna, och de märkta paketen kan skickas tillbaka in i tunneln de ska skapa.
Den tredje fasen är returvägen. En handskakning utan svar är inte bevis på ett utgående dropp; den passar lika bra med en inkommande serverregel eller en NAT-enhet som glömde mappningen. Skilj på det innan du rör 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 loggar symptomet de upptäcker, inte fasen som misslyckades, så tabellen är oftast snabbare än loggen.
Räknare avgör snabbare än loggar
På Linux, nft list ruleset eller iptables -vnL OUTPUT skriver ut en paketräknare per regel. Anslut en gång, låt det misslyckas och läs sedan räknarna igen. En regel vars räknare har flyttats är en regel som handskakningen träffade; om ingenting har flyttats någonstans nådde paketet aldrig brandväggen. Jag har sett en regeluppsättning släppa sin egen handskakning, och bara räknarna sa det.
För att skilja aldrig nådde brandväggen från aldrig lämnade värden, håll koll på själva interfacet. ip -s link show dev wlan0 rapporterar skickade paket, och tcpdump -ni wlan0 udp port 51820 visar ramarna. Om den står platt medan klienten försöker igen ligger felet ovanför netfilter: en saknad peer-rutt, en policyregel som pekar på en enhet som inte finns ännu, eller ett socketfel som klienten sväljer.
Testa undantag mot dokumentationsadresser som 203.0.113.10, så att ett misstag inte kan sondera någon annans värd.
Ett föråldrat endpunktsundantag läses som ett serveravbrott
Den mest vilseledande versionen dyker upp efter att peerens adress ändrats: en tjänst för dynamiska adresser har flyttat den, värden har byggts om, eller nätverkets utgångsadress är en annan. Undantaget nämner fortfarande den gamla adressen, så paket till den nya träffar droppregeln. Samma konfiguration fungerade i går, och därför börjar folk med felsökning av servern.
Ett värdnamn inne i en brandväggsregel räddar dig inte. I nftables löses namnet när regeluppsättningen laddas, så det fäster den adress som fanns i det ögonblicket och blir föråldrat som en bokstavlig. Den varaktiga lösningen är att uppdatera undantaget när endpunkten ändras och hålla det smalt: en peer-adress, en transportport. Ett intervall som är brett nog att överleva en adressändring är också brett nog att släppa ut orelaterad trafik.
När kill switchen kör på servervärden
Samma beroende finns i andra änden, och där är det lättare att missa. Om maskinen som fungerar som din VPN-server också kör en skrivbordsklient med kill switch, eller en brandväggsprofil kopierad från en bärbar dator, gäller dess droppregler för tjänsten som avslutar tunnlarna. Svar på en klients handskakning släpps, så varje klient misslyckas med att ansluta medan servern ser frisk ut och dess tunnelinterface står oanvänt.
Den värden behöver tre smala accepter före droppet: lyssningsporten på det fysiska interfacet, tunnelinterfacet för dekrypterad trafik och vidarebefordran från tunneln mot det klienterna ska kunna nå. Läs den installerade uppsättningen med nft list ruleset, iptables -S, eller pfctl -sr innan du ändrar något, och kom ihåg att en sparad regeluppsättning överlever omstart, så ett fel där överlever processen som gjorde det.
Återställningsordning som håller maskinen stängd
Arbeta utåt från profilen. Läs peerens adress och port som klienten använder, bekräfta att värdnamnet löses utan tunneln och lägg sedan till ett undantag för den adressen och porten bara på den fysiska adaptern. Anslut igen och håll koll på sänderäknaren; en slutförd handskakning är signalen att fas två är lagad.
Låt resten av droppolicyn stå kvar medan du testar. En ofarlig kontroll är att försöka en anslutning till en orelaterad dokumentationsadress och bekräfta att den fortfarande timar ut, vilket visar att kill switchen fungerar och inte är avstängd. Dra åt undantaget när tunneln är stabil, och lämna inte en permanent tillåt-allt-regel för klientprogrammet bara för att det är bekvämt.
Om tunneln kommer upp och programmet fortfarande misslyckas är de återstående faserna inte denna: delad DNS, MTU och routning per program ger var och en en ansluten tunnel med trasig trafik, och var och en har en annan första kontroll.