Kill switch blokkeert de VPN-server voordat er verkeer stroomt
Welke fase een kill switch blokkeert: eindpuntopzoeking, buitenste route, terugweg en verouderde peer-uitzonderingen — met tellers in plaats van gissingen.
Kill switches falen in een richting die mensen niet verwachten: ze zijn gebouwd om verkeer te blokkeren terwijl de tunnel omlaag is, en de pakketten die de tunnel opbouwen zijn zelf verkeer. Dat is de hele fout. Een regelset die alles weggooit wat niet via de tunnel naar buiten gaat, gooit ook de handshake weg die hem zou opzetten, dus de client probeert opnieuw in een lus en de fout wordt toegeschreven aan de fase die het eerst wordt gecontroleerd. Voordat u een firewall verbreedt, zoek uit welke van drie fasen wordt geweigerd: de naamopzoeking, het buitenste pakket naar de peer of het antwoord dat terugkomt.
Hoe de tunnel en zijn eigen transport van elkaar afhangen
Lees een VPN-client als twee netwerktoestanden die één socketpad delen. Voordat de tunnel bestaat, opent de client een socket op de fysieke adapter en stuurt versleutelde frames naar het adres en de poort van de peer. Pas als die uitwisseling slaagt, maakt hij het tunnelapparaat en installeert routes. Een kill switch is een beleid over de tweede toestand, zo breed geschreven dat het voor beide geldt.
Op interfaces gebaseerde regels zijn de gebruikelijke vorm: accepteer wat via tun0 of wg0 naar buiten gaat, gooi de rest van het uitpad weg. Die formulering kan de eigen verbinding van de client met de server niet uitzonderen, dus een correcte implementatie voegt die uitzondering expliciet toe, en u ook wanneer u regels met de hand schrijft. Regels per toepassing op Windows en macOS omzeilen een deel hiervan door een proces in plaats van een interface te matchen, maar het proces moet nog steeds naar buiten voordat de tunnel bestaat.
Drie fasen, in de volgorde waarin ze gebeuren
De eerste fase is resolutie. Wanneer het profiel een hostnaam opslaat in plaats van een letterlijk adres, heeft de client een DNS-antwoord nodig voordat hij iets kan verzenden. Een profiel dat DNS naar de resolver van de tunnel wijst, maakt een impasse: de resolver is alleen bereikbaar via de tunnel die de opzoeking mogelijk moest maken. Buiten de tunnel resolven, of het eindpunt aan een adres vastpinnen, haalt de dubbelzinnigheid weg.
De tweede fase is het buitenste pakket, dat eerst routing en dan de firewall moet overleven, in die volgorde. wireguard-tools doet de routinghelft hiervan voor WireGuard door zijn eigen pakketten te markeren en een beleidsregel toe te voegen zodat ze de standaardroute overslaan die het net heeft geïnstalleerd; de manpagina van wg-quick beschrijft die regel en de tabel die hij gebruikt. Bouw die routing met de hand opnieuw op, of laat een tweede hulpmiddel de regels herschrijven, en de gemarkeerde pakketten kunnen terug worden gestuurd de tunnel in die ze zouden moeten opzetten.
De derde fase is de terugweg. Een handshake zonder antwoord is geen bewijs van een uitgaand wegvallen; hij past even goed bij een inkomende serverregel of een NAT-apparaat dat de mapping vergat. Scheid dat voordat u de client aanraakt.
| 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 |
Clients loggen het symptoom dat ze detecteren, niet de fase die faalde, dus de tabel is meestal sneller dan het log.
Tellers beslissen sneller dan logs
Op Linux, nft list ruleset of iptables -vnL OUTPUT drukt een pakketteller per regel af. Verbind één keer, laat het mislukken en lees daarna de tellers opnieuw. Een regel waarvan de teller is bewogen, is een regel die de handshake raakte; als nergens iets is bewogen, heeft het pakket de firewall nooit bereikt. Ik heb een regelset zijn eigen handshake zien weggooien, en alleen de tellers zeiden dat.
Om nooit de firewall bereikt van nooit de host verlaten te onderscheiden, houd de interface zelf in de gaten. ip -s link show dev wlan0 rapporteert verzonden pakketten, en tcpdump -ni wlan0 udp port 51820 toont de frames. Als het plat blijft terwijl de client het opnieuw probeert, zit de storing boven netfilter: een ontbrekende peer-route, een beleidsregel die naar een apparaat wijst dat er nog niet is, of een socketfout die de client inslikt.
Test uitzonderingen tegen documentatieadressen zoals 203.0.113.10, zodat een vergissing niet de host van iemand anders kan aftasten.
Een verouderde eindpuntuitzondering leest als een serverstoring
De meest misleidende versie verschijnt nadat het adres van de peer is veranderd: een dienst voor dynamische adressen heeft het verplaatst, de host is opnieuw opgebouwd, of het uitgaande adres van uw netwerk is anders. De uitzondering noemt nog het oude adres, dus pakketten naar het nieuwe raken de weggooiregel. Dezelfde configuratie werkte gisteren, en daarom beginnen mensen met het diagnosticeren van de server.
Een hostnaam in een firewallregel redt u niet. In nftables wordt de naam opgelost bij het laden van de regelset, dus hij pint het adres vast dat op dat moment bestond en veroudert als een letterlijk adres. De blijvende oplossing is de uitzondering bijwerken wanneer het eindpunt verandert en hem smal houden: één peer-adres, één transportpoort. Een bereik dat breed genoeg is om een adreswijziging te overleven, is ook breed genoeg om ongerelateerd verkeer naar buiten te laten.
Wanneer de kill switch op de serverhost draait
Dezelfde afhankelijkheid bestaat aan de andere kant, en daar is hij makkelijker te missen. Als de machine die als uw VPN-server dient ook een desktopclient met kill switch draait, of een firewallprofiel dat van een laptop is gekopieerd, gelden de weggooiregels ervan voor de dienst die de tunnels beëindigt. Antwoorden op een clienthandshake worden weggegooid, dus elke client kan niet verbinden terwijl de server gezond lijkt en zijn tunnelinterface ongebruikt blijft staan.
Die host heeft drie smalle acceptaties nodig vóór het weggooien: de luisterpoort op de fysieke interface, de tunnelinterface voor ontsleuteld verkeer en doorsturen van de tunnel naar wat de clients moeten bereiken. Lees de geïnstalleerde set met nft list ruleset, iptables -S, of pfctl -sr voordat u iets verandert, en onthoud dat een opgeslagen regelset een herstart overleeft, dus een fout daar overleeft het proces dat hem maakte.
Herstelvolgorde die de machine dicht houdt
Werk van het profiel naar buiten. Lees het peer-adres en de poort die de client gebruikt, bevestig dat de hostnaam zonder de tunnel wordt opgelost en voeg dan één uitzondering toe voor dat adres en die poort, alleen op de fysieke adapter. Verbind opnieuw en houd de verzendteller in de gaten; een voltooide handshake is het signaal dat fase twee is gerepareerd.
Laat de rest van het weggooibeleid staan tijdens het testen. Een onschuldige controle is een verbinding proberen naar een ongerelateerd documentatieadres en bevestigen dat die nog steeds verloopt, wat laat zien dat de kill switch werkt en niet is uitgeschakeld. Trek de uitzondering strak zodra de tunnel stabiel is, en laat geen permanente alles-toestaan-regel voor het clientprogramma liggen alleen omdat het handig is.
Als de tunnel omhoog komt en de toepassing nog steeds faalt, zijn de resterende fasen niet deze: gesplitst DNS, MTU en routing per toepassing leveren elk een verbonden tunnel met kapot verkeer, en elk heeft een andere eerste controle.