VPN-Kill-Switch ohne Magie: Wie der OS-Kernel den Datenverkehr trennt und Privatsphäre schützt

Einleitung: Warum man 2026 einen VPN-Kill-Switch wirklich braucht

Ziele und Realität: Was schützen wir eigentlich praktisch gesehen

Eine einfache Frage, aber mit tiefgründigem Hintergrund: Was bist du bereit, innerhalb einer Sekunde ohne VPN zu verlieren? Deine IP-Adresse, deine Suchhistorie, App-Daten? Im Jahr 2026, wenn Apps alles synchronisieren und Browser dutzende Hintergrundverbindungen halten, ist der einzige verlässliche Schutz der VPN-Kill-Switch. Er macht eine klare Ansage: Wenn der Tunnel fällt, wird jeglicher Datenverkehr ohne Ausnahme blockiert. Kein „vielleicht“, kein „wird schon halten“. Alles wird abgeschaltet – außer dem Traffic über die gesicherte Schnittstelle. Klingt simpel? Unter der Haube verbirgt sich ein komplexer Tanz aus OS-Kernel, Routing-Tabellen, Paketmarkierungen, Treibern und Firewall-Regeln.

Warum das heute besonders kritisch ist

Die Risiken sind gestiegen. Heimkameras, Cloud-Mail, super-sensible Messenger, Krypto-Wallets – alles verbindet sich von selbst und permanent. Der Tunnel wackelt für eine Sekunde – schon droht ein DNS-Leak oder echte IP wird an eine API gesendet. Ja, nur eine Sekunde. Wir haben zahlreiche Fälle gesehen: Update des Netzwerktreibers in Windows 11 24H2, Mikro-Aussetzer im WLAN, Wechsel des Netzwerks am Laptop – und fertig. Der Kill-Switch verhandelt nicht, er handelt: er kappt die Verbindung. Und hält das Steuer, bis der Tunnel wieder stabil ist.

Kurz und knapp: Was der Kill-Switch tatsächlich tut

Ein Kill-Switch ist keine „Internet-aus-Schaltfläche“. Es ist ein Regelwerk, das im Netzwerkstack und in der System-Firewall verankert ist und sicherstellt: Nur Pakete, die über die VPN-Schnittstelle (tun, tap, utun, wg, ikev2) gehen, dürfen das Netzwerk verlassen; Pakete außerhalb davon werden an frühen Hooks verworfen. Plus DNS-Kontrolle: Die Auflösung erfolgt über VPN, lokale DNS-Resolver außerhalb des Tunnels sind verboten. Und ja, das Ganze muss auf Kernel-Ebene laufen, nicht in einer „Knöpfe-App“. Sonst gibt’s Rennbedingungen und die Privatsphäre ist passé.

Wie der Kill-Switch auf Kernel-Ebene funktioniert: Anatomie des Netzwerkstacks

Routing, Sockets und Hooks: Wo die Pakete genau abgefangen werden

Im OS-Kernel durchlaufen Pakete mehrere Phasen: Socket-Erstellung durch die Anwendung, Routenauswahl, Firewall-Regeln, Interface-Verarbeitung, Versand. Der Kill-Switch baut eine „Sperre“ an genau zwei Stellen ein: in den Routing-Tabellen (damit die Standardroute immer zum Tunnel zeigt) und in der Firewall (um sofort alles außer VPN-vermarkten Traffic zu droppen). Diese doppelte Absicherung schützt vor Rennbedingungen: Wenn die Route kurz ausfällt, sichert die Firewall ab; fällt die Firewall noch nicht auf das Interface an, blockiert die Route den Traffic außerhalb.

Kernel-Ebene auf Windows: WFP und NDIS-Filter

Unter Windows übernimmt die Windows Filtering Platform (WFP) die Hauptarbeit. Der VPN-Client setzt Callout-Treiber oder nutzt Systemschichten, filtert auf Transport- und Network-Stack-Ebene, markiert VPN-Daten und verwirft alles andere. Zusätzlich werden Firewall-Profile angepasst: Regel „Ausgehenden Traffic blockieren, außer über VPN-Schnittstelle“. Am NIC-Stack können NDIS LWF-Treiber eingreifen, aber 2026 ist der Trend klar: WFP ohne Zusatztreiber, um Kompatibilität mit Windows 11 24H2 und HVCI zu bewahren.

Linux: netfilter, nftables und cgroup-bpf

Auf Linux basiert der Kill-Switch meist auf netfilter. Die moderne Empfehlung ist nftables (Kernel 5.10+ und idealerweise 6.x): Wir erstellen output/forward-Ketten mit Drop-Policy, erlauben nur Pakete mit Markierung oder über bestimmte Interfaces (z. B. wg0). Zusätzlich richten wir policy routing ein: Traffic mit fwmark läuft über eigene Routingtabelle, Standard geht durch den Tunnel, der Rest in ein schwarzes Loch. Für fortgeschrittene Konfigurationen kommt cgroup-bpf (BPF_CGROUP_INET_EGRESS) zum Einsatz: Prozessbasierte Filter, damit z.B. der Admin-SSH aus dem Kill-Switch herausgehalten wird, alles andere aber nicht. Flexibel und schnell.

macOS: Network Extension und PF

MacOS setzt auf Network Extension (NE) und den systemeigenen Packet Filter (PF). Der NE-Client kontrolliert den Tunnel (utun-Interface) und PF nutzt Anchor, um eine restriktive Policy durchzusetzen: Alle ausgehenden Verbindungen blockieren, außer utunX-Interface und freigegebene Tunnel-Services. DNS wird über NEAppProxyProvider oder systemeigenen Resolver-Einstellungen erzwungen, sodass Queries durch VPN gehen. Ab macOS 14 hat Apple die NE-Stabilität verbessert, sodass 2026 die meisten ausgereiften Clients stabile PF-Regeln ohne Kollision bei Netzwerkwechseln bieten.

Routing und Tabellen: Ein einfacher Weg, Privatsphäre kaputt zu machen oder zu retten

Standardroute als Nervenzentrale

Häufiger Fehler: Zwei Standardrouten – eine zum physischen Netzwerk, eine zum Tunnel. Das OS wählt die „beste“ via Metrik. Beim Verbindungswechsel, WLAN-Wechsel oder aus dem Standby können sich Metriken ändern. Ergebnis: Ein Teil des Datenverkehrs geht am VPN vorbei, besonders schnelle DNS-Anfragen. Ein richtiger Kill-Switch stellt sicher, dass die Standardroute immer auf VPN zeigt und sonst alles discarded wird. Auch darf das Hinzufügen physischer Interfaces die Default-Route nicht zurücksetzen.

Policy Routing und fwmark: Chirurgie unter Linux

Linux bietet ein simples und robustes Rezept. Pakete von Anwendungen, die durch den Tunnel müssen (oder alle Pakete bei Total-Strategie) werden markiert, eine eigene Routingtabelle mit Default-Route zum Tunnel erstellt, in der Haupttabelle gibt’s entweder keine Default-Route oder sie zeigt ins schwarze Loch. Sinkt das Interface, findet der Traffic ohne Tunnel keinen Ausgang. Besonders in Kombination mit nftables kann man fein granulare Regeln definieren: Interface, Prozessgruppe, UID, Ports, Domains über sets und maps.

Windows: Metriken und Interface-Profile

Windows mag „Eigenständigkeit“. Deshalb fixieren wir Interface-Metriken: VPN bekommt eine niedrige Metrik, physische Interfaces höhere Werte. Firewall-Regeln erlauben ausgehenden Traffic nur über VPN-Schnittstelle (InterfaceAlias oder InterfaceType). Fällt der Tunnel aus, blockiert die Firewall alles – außer evtl. lokale Adressen 127.0.0.0/8 und link-local zur OS-Stabilität. 2026 implementieren viele Clients automatische Metrik-Korrekturen und Recovery der Regeln nach Neustart des BFE-Diensts, vorher eine Achillesferse.

macOS: Sticky Routes und PF-Anker

Unter macOS funktioniert die Lösung mit PF zuverlässig: Ein Anchor wird erstellt, Default-Policy blockiert, nur Regeln mit utunX-Interface sind freigegeben. Sticky-Routes für VPN werden automatisch über NE gesetzt, PF lässt keine „Hintertür“ zu. Wichtig: Nach Standby und Netzwerkwechsel bitte utun-Interface-Nummer aktualisieren, sie kann sich ändern. Gute Clients machen das selbst, indem sie Events via NE abfangen.

Firewall-Regeln: Wie die Blockade genau aufgebaut wird

Linux: nftables statt iptables

2026 gibt es iptables noch, doch die Empfehlungen sind veraltet. Wir legen eine Inet-Tabelle "vpn" an, Chains input, forward, output. Output-Policy ist drop. Erlaubt werden: established, related; Interface wg0 (oder tun0); DNS via wg0; optional localhost. Eine Regel lautet: Wenn Interface != wg0, dann drop, sonst accept. Um abzusichern, kann man in nftables-Route-Tabelle flexibel Traffic bei downem Interface lenken, meist reicht aber striktes Output-Dropping.

Windows: AdvFirewall und WFP

Die Strategie: Erst wird eine Block-All-Regel für ausgehenden Traffic angelegt, dann eine Ausnahme für das VPN-Interface. GUI ist mühsam, deshalb PowerShell: New-NetFirewallRule mit Direction=Outbound, Action=Block für alle Profile, gefolgt von punktuellen Allow-Regeln fürs InterfaceAlias. Moderne Clients gehen weiter: Sie installieren WFP-Callouts, die Pakete vor TCP-Stack droppen und VPN-Pakete markieren, sodass zufällige Allow-Regeln außen vor bleiben. Schneller und sicherer als User-Regeln.

macOS: PF mit Anchors und States

PF regelt: set block-policy drop; set skip on lo0; anchor vpn-killswitch mit Regeln zum erlauben von Traffic nur auf utunX von überall nach überall mit State-Kontrolle und Block auf allen anderen Interfaces. Stateful Verarbeitung macht das Verhalten für Apps zuverlässig. DNS-Schutz: UDP/53 auf allen Interfaces außer utun blockieren. Wenn DoH im Tunnel genutzt wird – perfekt, dann UDP/53 global blockieren und nur TCP/443 über utun lassen.

DNS: Ein eigener Brennpunkt

DNS ist die heimtückischste Leckstelle. Die einfache Regel lautet: Auflösung nur über VPN oder keine. Unter Linux wird resolv.conf auf lokalen Resolver umgeleitet, der nur auf tun-Interface hört, oder systemd-resolved mit domänenspezifischem Routing genutzt. Unter Windows aktiviert man „Block outside DNS“ (OpenVPN hat dafür einen Flag), zusätzlich sperrt die Firewall udp/53 außerhalb VPN. macOS nutzt scoped DNS via NE, PF blockt 53 außerhalb utun. Und ja, prüfe DoH-Clients (Browser tricksen oft): Sie müssen das System-Stack oder DoH-Endpunkt im VPN nutzen.

Wie VPN-Clients den Kill-Switch umsetzen: Praktische Analyse

WireGuard: Markierungen und AllowedIPs

WireGuard ist schnell, simpel und transparent. In Kombination mit wg-quick erreicht der Kill-Switch zwei Ziele: AllowedIPs umfassen den gesamten Traffic (0.0.0.0/0, ::/0), und Routingtabellen plus fwmark zwingen den Traffic ins wg-Interface. Fällt das Interface aus, droppen nftables-Regeln den Ausgangsverkehr. Optional lässt sich Table=off aktivieren und policy routing manuell pflegen: flexibel und vorhersehbar. Mobilgeräte erstellen das Interface on-the-fly mit Drop-Regeln – ein Muss.

OpenVPN: Blockade außerhalb des Tunnels und Routing

OpenVPN ist etabliert. Unter Windows schließt der Parameter block-outside-dns DNS-Lecks, client-config-dir und route-pre-down Scripts sorgen für sauberes Routing. Unter Linux gilt als guter Stil: Nftables-Verbindung – Drop alles außer tun0. macOS nutzt PF plus Launchd für atomare Regelsets. Beim aktiven Reconnect blockieren fortgeschrittene Clients zunächst den gesamten Traffic, bringen dann den Tunnel hoch und öffnen anschließend nur VPN-Interface-Traffic.

IKEv2/IPsec: Systemstacks und Selektoren

IKEv2 auf Windows und macOS nutzt die systemeigenen IPsec-Stacks. Hier baut der Kill-Switch oft auf OS-Ebene: Ausgangsverkehre auf virtuelle Adapter begrenzen, 0.0.0.0/0 nach draußen sperren, mit expliziter Routen für Exceptions (Split-Tunnel). Bei No-Split-Tunnel heißt es: Alles über VPN, alle anderen Interfaces global blockiert. Linux strongSwan koppelt xfrm-Policies mit nftables und policy routing – so fällt der nicht selektierte Traffic ins Nichts.

Hybride Clients 2026: eBPF, NE und WFP

Der Trend 2026: Weniger Hacks, mehr Integration. Unter Linux kommt eBPF für Filterung auf Prozessebene. macOS setzt auf Network Extension mit smarten PF-Konfigurationen und Event-Monitoring. Windows vertraut WFP ohne User-Tricks. Zusätzlich Telemetrie: Ist das Interface instabil, verändert der Client Routen nicht in Millisekunden-Schritten, sondern nutzt Verzögerungen und Transaktionen, um Leck-Fenster zu vermeiden.

Schritt-für-Schritt Einrichtung: Windows, Linux, macOS

Windows 11: Firewall und Routing

Grundplan: Zuerst generellen ausgehenden Block aktivieren, dann Ausnahmen für VPN-Interface hinzufügen. Per PowerShell sieht das so aus: Regel für Block-All outbound in allen Profilen; Erlaubnis für InterfaceAlias des VPNs (z. B. „WireGuard Tunnel“ oder „Ethernet 5“ je nach Treiber); Prioritäten der Interfaces setzen – Set-NetIPInterface mit Disabled Automation-Metric und InterfaceMetric für VPN niedriger. Ergebnis: Fällt VPN-Dienst, gibt es keinen Traffic, denn Block-All bleibt aktiv. Kleiner Tipp: Separate Loopback-Regel, sonst meckern manche Apps.

Linux (nftables + policy routing)

Vorgehen: Tabelle inet vpn anlegen, output Chain mit Drop-Policy. Erlauben: oifname „wg0“ oder „tun0“, established, localhost. Traffic mit fwmark (z.B. 0x1) markieren, ip rule add fwmark 0x1 table 100, ip route add default dev wg0 table 100. In der Haupttabelle kein Default oder Blackhole. Optional: cgroup-bpf für Ausnahmen bei Admin-Services. Tests mit ping, curl via Interface und Systemtraffic wie NTP müssen durch den Tunnel laufen.

macOS (PF + NE)

So vorgehen: VPN-Client mit Network Extension starten, utunX-Interface bestimmen. In /etc/pf.conf Anchor „vpn-killswitch“ anlegen, Default-Blockdrop, Skip auf lo0 aktivieren. Im Anchor nur erlauben ausgehend auf utunX mit State. PF mit pfctl laden und aktivieren. Scoped DNS im Client einstellen, damit DNS-Abfragen nicht nach außen entkommen. Nach Standby Events abfangen und utunX in Regeln aktualisieren bei geänderter Nummer. So verhindern die meisten Clients 2026 jedes Leck trotz abruptem WLAN-Wechsel.

Apps und Ausnahmen berücksichtigen

Manchmal braucht man Ausnahmen: OS-Updates, Firmenagenten, VoIP außerhalb VPN. Mache das mit Bedacht. Unter Linux cgroup mit eigener Policy anlegen. Unter Windows WFP Callout oder Regeln nach AppPath und Diensten. macOS nutzt NEFilterDataProvider mit App-Regeln. Führe ein komplettes Log, wer wann raus darf. Kill-Switch bleibt standardmäßig strikt, Ausnahmen punktuell und kontrolliert.

Überprüfung und Tests: So siehst du, dass der Kill-Switch wirklich wirkt

Schnelle IP- und DNS-Prüfungen

1) VPN ausmachen und schauen, ob Internet geht. Es sollte kein Zugang bestehen. 2) VPN einschalten und IP-Abfrage-Seite öffnen: IP muss die des VPN-Providers zeigen. 3) Tunnel zwangsweise trennen: Dienst stoppen, Interface deaktivieren. Internet muss weg sein. 4) DNS prüfen: Domain-Resolvierung starten, sicherstellen, dass Queries über VPN-Interface laufen. Wenn Netzwerk auftaucht trotz Tunnelverlust, ist die Sperre löchrig.

Routing und Interface-Check

Windows: Mit route print, Get-NetRoute, Get-NetIPInterface Metriken, Standardrouten und NextHop auf VPN kontrollieren. Linux: ip route, ip rule, ip -4 -6 route show table 100 zur Policy-Anzeige. macOS: netstat -rn, scutil --dns für Default und DNS-Scopes checken. Tunnel down und schauen, ob Default-Route verschwindet, oder ungeschützt auftaucht. Wenn ja, Policy nachbessern.

Minimalsniffer

Linux: tcpdump -i any not host VPN-Adresse – keine ausgehenden Pakete dürfen das System verlassen. Windows: Eingebautes pktmon oder Wireshark mit Filter not ip.addr==VPN_IP und not interface==VPN. macOS: tcpdump -i en0 oder en1 – bei Tunnelverlust keine Pakete. Sniffer sind der beste Lackmustest. Wenn Pakete fliegen, gibt’s irgendwo eine Lücke.

Race-Condition- und Sleep-Wake-Test

Komplex, aber aussagekräftig: Aktive Downloads, Videoanruf, viele offene Browser-Tabs, dann Laptop in Standby und zurück, WLAN zu Mobilhotspot wechseln, schnelles Docking. Der Kill-Switch muss das durchstehen: Kein Paket unverschlüsselt raus. Wenn Logs kurze Ausreißer zeigen, verschärf Kernel-Regeln und verringere Zeitfenster für Regeländerungen beim Reconnect.

Typische Fehler und reale Fälle

Doppelte Default-Route und Metriken

Ein klassischer Fehler: Unter Windows ist die Metrik des physischen Interfaces niedriger als die des VPN. Nach Treiber-Update optimieren sich Metriken „automatisch“ und Traffic läuft falsch. Heilmittel: Metriken manuell fixieren und Firewall-Regeln genau nach InterfaceAlias VPN prüfen.

DNS-Leaks durch DoH

Browser nutzen oft ihren eigenen DoH-Resolver. Du blockierst UDP/53 – gut, aber der Browser schickt DoH über TCP/443 außerhalb des Tunnels. Lösung: Apps per Policy zwingen, den System-Resolver über VPN zu nutzen; Firewall lässt DoH nur bei oif=VPN zu. Unter Linux praktisch mit nftables Sets, die DoH-IPs per Tunnel erlauben, der Rest wird komplett blockiert.

Split-Tunnel und der menschliche Faktor

Firmenrichtlinien erlauben oft etwas Traffic direkt. Das ist riskant: Ein falscher Ausnahmepfad und die Privatsphäre ist löchrig. Der Ansatz: Minimaler erlaubter Split und klare Audits. Whitelists von Domains lieber über VPN resolven und nur wirklich nötigen IP-Traffic rauslassen.

Mobile Netze und NAT64

In LTE/5G existiert manchmal NAT64 und Übergangslösungen, die IPv6-Traffic an der Filterung vorbeischleusen können, wenn nur IPv4 gefiltert wird. Achte darauf, dass dein Kill-Switch IPv4 und IPv6 abdeckt. Setze AllowedIPs auf 0.0.0.0/0 und ::/0. In nftables Inet-Tabelle nimmst du beide Stacks gleichzeitig mit.

Fortgeschrittene Techniken und Trends 2026

eBPF unter Linux: Prozessbasierte Filterung

Mit eBPF verabschieden wir uns von groben globalen Blockaden hin zu schlauen Policies. cgroup-bpf ermöglicht: Standard alle Prozesse blockiert außerhalb wg0, aber etwa der Zeit-Update-Service kann nur in einen bestimmten IP-Pool. Damit bricht weniger und der Kill-Switch ist bedienfreundlicher, ohne weniger sicher zu sein.

Windows: WFP mit Telemetrie zum Tunnelstatus

Moderne Clients nutzen WFP-Callouts, die nicht nur droppen, sondern den Tunnelzustand „verstehen“. Ist der Tunnel noch nicht etabliert, ist der Block hart, bei Tunnel da, ist Traffic erlaubt. Das minimiert Leck-Fenster, wenn Regeln noch nicht greifen und Daten schon fließen. Plus detaillierte Logs: Welcher Prozess, wohin, Protokoll – Gold wert bei Untersuchungen.

macOS: NE + PF mit atomaren Updates

2026 sind viele Clients auf atomare Updates der PF-Anker umgestiegen: Neue Konfiguration wird generiert, neu geladen, und sauber getauscht. Keine Unterbrechungen, keine Rennbedingungen. NE überwacht Netzwerksituationen, erfasst WLAN-Wechsel und aktualisiert Interface- bzw. DNS-Scopes sofort.

Schutz vor „versteckten“ Kanälen

Manche Apps nutzen QUIC, uTP, eingebaute Proxys zur „Optimierung“. Der Kill-Switch behandelt sie als mögliche Wege zum Umgehen. Lösung: Ausgehenden Traffic auf allen Interfaces außer VPN blockieren, aber basierend auf Socket-Status, nicht auf Ports; Erlaubnis nur bei Interface-Übereinstimmung oder Markierung. So hilft auch Port-Masking nicht, die Policy zu umgehen.

Implementierungs-Checkliste: Schritte, die man nicht überspringen sollte

Richtlinien-Design

Entscheide: Total-Tunnel oder teiler Tunnel. Liste notwendiger Ausnahmen. DNS-Anforderungen (DoH, DoT). Unterstützte OS-Versionen (Windows 11 24H2+, Linux Kernel 6.x, macOS 14+). Szenarien mit Standby, Roaming zwischen WiFi & Ethernet und Mobilnetz.

Technische Umsetzung

Windows: AdvFirewall + WFP; Linux: nftables + Policy Routing + ggf. eBPF; macOS: NE + PF Anchors. Kernpunkte: Vollständige Blockade außer VPN-Interface; DNS außerhalb VPN verbieten; Standardroute über Tunnel; Schwarzes Loch bei Interface-Ausfall.

Test & Monitoring

Sniffer, Stress-Tests beim Reconnect, Prozess-Logging, IPv6-Überprüfung, DoH-Checks, „schwierige“ Apps (Game-Launcher, Torrents, Firmenagenten). Monitoring: Alerts bei Default-Route außerhalb VPN, Schnittstellen-Ausfall-Meldungen, Telemetrie von Umgehungsversuchen.

Betrieb & Rücksetzung

Halte einen „Notfall-Schlüssel“ bereit: Wie den Kill-Switch entfernen, falls der VPN-Client abstürzt und sofort Internet nötig ist. Unter Windows ein Skript für Regelentfernung, Linux eine Datei mit nft flush ruleset plus Backup-Konfig, macOS pfctl -d und NE Profil Rücksetzung. Nutze das nur offline oder mit Absprache, um die Sicherheit nicht zu gefährden.

Praktische Kommandos und Beispiele: Kompakte Spickzettel

Windows PowerShell

Block-All Outbound hinzufügen: New-NetFirewallRule -DisplayName "Block All Outbound" -Direction Outbound -Action Block -Profile Any. Erlauben für VPN-Interface: New-NetFirewallRule -DisplayName "Allow VPN Outbound" -Direction Outbound -Action Allow -InterfaceAlias "Name_des_VPN_Interfaces" -Profile Any. Metrik fixieren: Set-NetIPInterface -InterfaceAlias "Name_des_VPN_Interfaces" -AutomaticMetric Disabled -InterfaceMetric 5; für physische Interfaces 50+.

Linux nftables

Tabelle und Policy anlegen: add table inet vpn; add chain inet vpn output { type filter hook output priority 0; policy drop; }; add rule inet vpn output oifname "wg0" accept; add rule inet vpn output meta oifname "lo" accept; add rule inet vpn output ct state established,related accept. Policy Routing: ip rule add fwmark 0x1 table 100; ip route add default dev wg0 table 100. Haupttabelle ohne Default oder blackhole default dev lo.

macOS PF

In pf.conf: set block-policy drop; set skip on lo0; anchor "vpn-killswitch"; im Anchor: block out on ! utunX from any to any; pass out on utunX from any to any keep state; block out proto { udp, tcp } to port 53 on ! utunX. Aktivieren mit pfctl -f /etc/pf.conf; pfctl -E. utunX bei Reconnect updaten.

DNS-Diagnose

Windows: Resolve-DnsName mit Trace; sicherstellen, dass Server aus Get-DnsClientServerAddress zum VPN gehören. Linux: resolvectl dns & resolvectl status; Interface tun/wg korrekt. macOS: scutil --dns prüft Scoped Resolvers; Systemdienste müssen utun zeigen.

Warum funktioniert der Kill-Switch manchmal „plötzlich“ nicht und wie behebt man das

Rennbedingungen beim Reconnect

Wenn der Client Regeln vor der Aktivierung des neuen Tunnels entfernt, entstehen Millisekunden- bis Sekundenfenster. Lösung: Atomare Transaktionen. Erst global blockieren, dann Tunnel hochziehen, dann Regeln auf Interface öffnen. Nur so sicher.

OS-Dienste mit Sonderrechten

Antiviren, Corporate Agents, Systemupdates können reguläre Regeln umgehen. Diese muss man kernelseitig fangen: WFP Callout für Windows, cgroup-bpf für Linux, NEFilterDataProvider für macOS. Sonst reist ein „magischer“ Service ein Loch rein.

Inkongruenzen bei IPv6

Nur IPv4 filtern reicht nicht. 2026 gibt es IPv6 überall. Prüfe ::/0, RA, SLAAC und blockiere Ausgang auf physischem Interface in beiden Stacks. Inet-Tabellen bei nftables helfen, PF und WFP schaffen das auch.

Browser mit eigenem Netzwerkstack

Manche Browser nutzen eigenen DNS-Stack, QUIC und Proxies. Schalte „DNS-over-HTTPS immer“ aus, wenn dein Setup keine DoH-Tunnelung unterstützt. Ansonsten droht DoH-Lücke. Besser ist DoH zum eigenen Resolver im VPN plus strikte Blockade alles anderer.

Fazit: Woran du erkennst, dass dein Kill-Switch „richtig“ ist

Merkmale einer ausgereiften Umsetzung

Kein Internet bei VPN-Ausfall. Default-Route zeigt zum Tunnel. DNS ausschließlich über VPN. IPv6 berücksichtigt. Ausnahmen selten, punktuell, geloggt. Sniffer-Test bestanden. Standby, Roaming, Reconnect ohne Leak.

Was es dir wirklich bringt

Ruhe und Sicherheit. Echt. Wenn du weißt, dass bei Verbindungsabriss kein Byte nach draußen fliegt, kannst du arbeiten, Videos schauen und Backups synchronisieren. Ohne Angst vor der „Sekunde der Wahrheit“. Der Kill-Switch ist ein Schutz, der nicht versagt.

Handlungsaufforderung

Prüfe deine Konfiguration heute. Beseitige doppelte Standardrouten. Verschärfe Regeln. Schließe DNS-Lecks. Und kontrolliere Logs: Wenn der VPN stillsteht, soll auch der Traffic stillstehen. Dann sind alle anderen Details nur noch Beiwerk.

FAQ: Häufige Fragen zum VPN-Kill-Switch

Geht ein Kill-Switch auch ohne Administratorrechte?

Zuverlässig: Nein. Änderungen an Routing und Firewall brauchen Adminrechte. Sonst ist es ein Spielzeug, keine echte Sicherheit.

Worin unterscheidet sich ein Kill-Switch vom einfachen „Internet bei Verbindungsabbruch blockieren“ im Client?

Ein richtiger Kill-Switch arbeitet im Kernel und der Firewall. „Nur blockieren“ in der App ist zu spät und verliert Rennbedingungen. Notwendig sind WFP, nftables, PF.

Verliert der Kill-Switch bei Split-Tunnel überhaupt Sinn?

Nein. Er blockiert weiterhin unerlaubten Traffic. Allerdings steigt das Risiko: Split ist komplex und braucht genaue Konfiguration.

Sollte man IPv6 blockieren, wenn der Provider es nicht bereitstellt?

Ja. Apps können lokale IPv6-Sessions über andere Netze aufbauen. Blockiere beide Stacks dauerhaft.

Wie teste ich, dass DoH nicht am VPN vorbeigeht?

Sniffer auf dem physischen Interface und Firewall-Strategie: Erlaube DoH nur über VPN-Interface, alles andere Drop.

Bietet WireGuard von Haus aus einen Kill-Switch?

Fast. Wenn AllowedIPs = 0.0.0.0/0, ::/0 und Routing korrekt sind. Ohne Firewall-Regeln bleiben Leck-Fenster beim Reconnect. Drop-Regeln außerhalb wg sind Pflicht.

Warum habe ich bei VPN-Ausfall noch Zugriff auf das lokale Netzwerk?

Weil entsprechende Regeln das erlauben. Link-local und LAN-Zugriff kann nötig sein. Wer es strenger will, blockiert das ebenfalls – aber damit sind Drucker und Filesharing oft verloren.