VPN lässt keinen Datenverkehr durch? Routing, Metriken und Konflikte im Detail erklärt

Hattest du schon mal das Gefühl, dass du dich mit dem VPN verbunden hast und das Internet plötzlich ohne Vorwarnung Urlaub macht? Oder dass ein Teil deiner internen Ressourcen funktioniert, während der andere scheinbar stumm bleibt, als wärest du für ihn ein Gespenst? Wir kennen dieses Problem. Routing über VPN ist eine heikle Angelegenheit. Eine falsch gesetzte Routemetrik oder ein falsch konfiguriertes Standardgateway, und der Datenverkehr fließt an die falsche Stelle. Irgendwo geht die Rückroute verloren. Mal schaut der DNS in die falsche Richtung. Und manchmal spielt die MTU einen fiesen Streich und schneidet Pakete ab wie ein Koch im Meisterkurs. Aber keine Panik. Ruhig, Schritt für Schritt, mit Checkliste in der Hand – wir gehen alles systematisch durch.

Im Jahr 2026 ist VPN nicht mehr einfach „Tunnel aufsetzen und vergessen“. Wir leben im Zeitalter von Zero Trust, SASE, ZTNA und unzähligen hybriden Szenarien: Cloud, Filialen, Homeoffice, Mobilfunknetze und alles zusammen. Auf dem Tisch liegen parallel WireGuard, IKEv2/IPsec, SSL-VPN über QUIC und sogar Tunnel über Proxies und HTTP/3. Und ja, oft hast du gleichzeitig DoH, unternehmensinterne DNS mit Split-Horizon, IPv6-only Segmente mit NAT64/DNS64 und ein paar Policies, die um die Vorherrschaft deines Datenverkehrs kämpfen. Klingt kompliziert? Definitiv spannend.

Dieser Artikel ist ein praktischer Leitfaden. Keine trockene Theorie um der Theorie willen. Wir analysieren konkrete Routenkonflikte, verstehen Metriken und Prioritäten unter Windows, Linux und macOS, zeigen, wo Gateways brechen und warum Datenverkehr „einseitig“ wird, richten Split-Tunneling so ein, dass kein Kopfweh entsteht, und lernen, wie man stabil diagnostiziert. Es gibt reale Beispiele, hilfreiche Befehle, Checklisten und Automatisierungstipps. Am Ende wartet ein FAQ, das du dir unbedingt bookmarken solltest. Los geht’s!

Wie funktioniert Routing im VPN und wo hakt es am häufigsten?

Routingtabelle: der Hauptregisseur deines Datenverkehrs

Wenn wir uns mit dem VPN verbinden, kommen neue Routen ins System. Jede Route hat ein Zielnetz, eine Maske (oder Präfix), den nächsten Hop (Gateway), ein Interface und eine Metrik. Die Prioritätsregel ist einfach: Erst wird der längste Präfixmatch gesucht, danach die Metriken verglichen. Je kürzer der Weg und je niedriger die Metrik, desto wahrscheinlicher wählt das System diese Route. Und ja, manchmal fügt der VPN-Client „breite“ Routen hinzu (z. B. 0.0.0.0/0) und zieht damit den ganzen Datenverkehr auf sich. Wenn dann keine Ausnahmen definiert sind, verschwindet das Internet wie durch Zauberei. Das klingt banal, aber genau hier sollte die Analyse beginnen.

Ein weiterer Punkt sind die Schnittstellenreihenfolge und automatische Metriken. Unter Windows und macOS neigt das System dazu, „mitzudenken“ und die auto-metric anhand der Schnittstellengeschwindigkeit zu vergeben. VPN über WLAN verbunden, daneben Ethernet? Überraschungen sind programmiert. Unter Linux ist die Sache etwas komplexer: Bei Policy-Based Routing (PBR) und mehreren Routingtabellen sieht man manchmal in der Haupttabelle eine Route und in der Policy eine komplett andere, die den Datenverkehr abfängt. Ergebnis: unterschiedliche Wege für verschiedene Pakete, obwohl auf den ersten Blick „alles passt“.

Typische Konflikte: Subnetzüberlappungen, Duplikate und Black Holes

Klassiker sind sich überschneidende RFC1918-Netze: internal in der Firma 10.0.0.0/8, während der Mitarbeiter zu Hause 10.0.0.0/24 vom Router bekommt. Oder noch verwirrender: im VPN werden mehrere überlappende Subnetze durch BGP-Aggregation „eingesogen“. Dann kann die Route zum gewünschten Subnetz von einer allgemeineren Ankündigung überdeckt werden, und du bekommst den falschen Weg. Siehst du 10.20.0.0/16 und 10.20.5.0/24, aber die Metrik für /16 ist niedriger? Dann läuft der Verkehr falsch und du fängst „Black Holes“.

Ein weiteres häufiges Problem ist die Duplizierung von Routen durch denselben VPN-Client: OpenVPN kann z.B. 0.0.0.0/1 und 128.0.0.0/1 hinzufügen (so funktioniert Full Tunnel), während parallel bereits eine Defaultroute existiert. Das System wählt eine der Routen, aber die Kontrolle der Rückwege kann verloren gehen. Dritter Fall: Routen zu internen Ressourcen sind eingetragen, aber die Rückroute auf dem Server fehlt. Pakete fliegen ins interne Netz, Antworten nehmen ‚Umwege‘ über den Provider, wo sie verworfen werden. Das ist asymmetrisches Routing: Client Ping geht, Server bleibt stumm.

VPN-Client und Server: Wer regelt wann die Routen?

Verschiedene Clients verhalten sich unterschiedlich. WireGuard setzt auf AllowedIPs: Das ist Filter und Routing in einem. 0.0.0.0/0 hinzugefügt = Full Tunnel; enge Präfixe = Split. OpenVPN nutzt oft Optionen wie redirect-gateway def1, route-nopull und Push-Strings vom Server zum Hinzufügen benötigter Routen. IKEv2/IPsec arbeitet mit Traffic-Selectoren und Policies; bei BGP-Integration können Präfixe dynamisch angekündigt werden. Der Server kann Routen aufdrängen oder die Entscheidung an die lokale Maschine delegieren.

In großen Infrastrukturen verknüpfen VPN-Server sich mit SD-WAN, PBR und Firewall-Regeln. Routen zu Segmenten kommen via BGP oder statisch, und Clients erhalten nur die nötigen Bereiche. Wichtig ist zu wissen, wer in deiner Topologie „Chef“ ist: der Client, der selbst entscheidet, wohin der Traffic soll, oder Server/Controller, der die Regeln vorgibt. Davon hängt ab, wo du den Fehler suchen musst. Manchmal ist es einfacher, das Verhalten des Clients zu ändern (z. B. auto-metric deaktivieren und explizite Werte setzen), als die Server-Policy zu brechen.

Grundlegende Diagnostik: Was zuerst überprüfen?

Netzwerktests: Ping, Traceroute, MTR und DNS-Check

Fang einfach an. Ping per IP zum internen Ressource: Läuft, heißt, Verbindung grundsätzlich da. Ping per Name prüft DNS. Wenn IP klappt, Name nicht, liegt das Problem beim Resolver, Split-Horizon oder DNS-Server-Reihenfolge. Traceroute (oder tracepath unter Linux) zeigt, über welches Interface und wohin der Traffic tatsächlich fließt. MTR ist super für lange Strecken und unstabile Routen: Verzögerungen und Paketverluste auf einen Blick.

Check, wohin dein Internetverkehr fließt. Versuch traceroute zu 8.8.8.8 oder anderen öffentlichen Adressen. Nach VPN-Verbindung ist die Route unterbrochen und der erste Hop liegt im Tunnel? Klar, Full Tunnel läuft. Wenn aber kein Full Tunnel besteht und das Internet trotzdem ausfällt, liegt vielleicht ein DNS-Problem oder MTU vor. Ein einfacher Test: Kleine Webseite herunterladen, dann größere. Hängt es bei „schweren“ Seiten, merk dir: MTU oder blockiertes PMTUD sind oft der Übeltäter.

Routingtabellen: Windows, Linux, macOS – Abweichungen suchen

Unter Windows nutze route print und Get-NetRoute, bei Bedarf auch Get-NetIPInterface, um Schnittstellenmetriken zu prüfen. Vergleiche, wer 0.0.0.0/0 besitzt, welche spezifischeren Routen existieren und wie die Metrik für VPN und LAN aussieht. Manchmal hilft es, auto-metric abzuschalten und telefonisch Prioritäten zu setzen, damit Traffic „richtig geleitet“ wird. Denke auch an IPv6-Tabellen: route print -6 und Get-NetRoute -AddressFamily IPv6.

Unter Linux schau ip route show, ip -6 route und bei Verdacht auf PBR ip rule list plus die verschiedenen Tabellen (ip route show table 100 usw.). Achtung auf Prioritäten und Markierungen (fwmark). Anwendungen können Markierungen setzen, sodass Traffic den falschen Pfad nimmt. macOS: nutze netstat -rn, route -n get , networksetup -listallnetworkservices und scutil --dns, um Resolver-Reihenfolge und Interfaceprioritäten zu prüfen. Oft ist VPN-Interface hinzugefügt, aber der „Service-Priorität“ bleibt auf Wi-Fi stehen – und dort fließt der Traffic weiter.

Paketerfassung: Wireshark, tcpdump und Systemtools

Wenn die Routentabelle nicht klar ist, kommen Sniffer zum Einsatz. Linux: tcpdump -i wg0 host gewünschte_Adresse oder tcpdump -i any port 53 für DNS. Beobachte, wohin der Traffic wirklich geht, ob Antworten kommen und wie TTL sich verändert. Windows 2026 setzt verstärkt auf pktmon und event logs, Wireshark bleibt aber ungeschlagen: Filter nach VPN-Interface und Zieladresse. Siehst du SYN, aber kein SYN-ACK? Check Rückroute und Firewall.

Tipp: Prüfe PMTUD, setze df-Bit und probiere große Pakete. Hängen sie in der Mitte der Route, blockiert jemand ICMP Fragmentation Needed. DNS-Tests separat wichtig: scutil --dns (macOS) zeigt, welche Domains welchen Resolver nutzen, resolvectl status (Linux) sagt dir, welcher Server wirklich bedient. Manchmal reicht es, Resolver-Reihenfolge zu ändern oder bedingte Weiterleitungen für interne Domains einzubauen, und schon funktioniert’s.

Metriken und Prioritäten: So funktionieren sie unter Windows, Linux und macOS

Windows: auto-metric, InterfaceMetric und RouteMetric

Unter Windows ist die automatische Priorisierung oft großzügig, aber nicht immer klug. Das schnellere Interface kann eine niedrigere Metrik bekommen, und das System entscheidet, dass es wichtiger ist. VPN-Interfaces haben virtuelles Tempo, und die Metrik wirkt seltsam. Deshalb deaktiviert man häufig auto-metric am VPN-Interface und setzt InterfaceMetric manuell (z. B. 5 oder 15, je nach Design). Danach kontrolliert man RouteMetric für einzelne Routen: Je kleiner die Zahl, desto eher wird diese Route genommen.

Mit Get-NetIPInterface und Set-NetIPInterface -InterfaceMetric prüfen. Für Routen New-NetRoute oder Set-NetRoute mit RouteMetric. Wenn der VPN-Client Default pusht, du aber Split möchtest, nutze Client-Policies: z. B. route-nopull bei OpenVPN plus explizite route add für Subnetze. In Always On VPN und modernen Firmenclients kannst du erlaubende/ausnehmende Regeln konfigurieren, damit Internet nicht kaputt geht und nur nötige Präfixe durch den Tunnel.

Linux: Prioritäten, Policy-Based Routing und mehrere Tabellen

Unter Linux ist die Metrik in ip route nur ein Teil der Story. Mit ip rule entstehen mehrere Routingtabellen, und die Priorität der Regeln legt fest, welche Tabelle den Paketpfad bestimmt. Das ist mächtig, aber tückisch: Du kannst feinste Regeln nach Quelle, fwmark oder TOS machen, aber leicht übers Ziel hinausschießen und Apps in eine „isolierte Welt“ schicken. Fügt der VPN-Client Tabelle und Regel mit hoher Priorität hinzu, kann der gesamte Traffic ins Tunnel gehen, selbst wenn der Hauptdefault ins Internet führen sollte.

Praktischer Tipp: ip rule list, danach ip route show table main und weitere Tabellen prüfen. Achte auf Regelkonflikte und dass VPN-Tabelle Rückrouten enthält. Für IPv6 ebenso: ip -6 rule. Bei WireGuard sind AllowedIPs nicht nur Filter, sondern setzen auch Routen. Split lass dich mit genauen Präfixen realisieren. Nutze iptables/nftables Markierungen und Tabellen, aber dokumentiere Reihenfolge – sonst weiß nach einem Monat keiner mehr, warum Browser über einen Pfad und curl über den anderen läuft.

macOS: Service-Reihenfolge, ifscope und Resolver-Prioritäten

Route auf macOS hängt von der Service-Reihenfolge ab: höhere Netzwerkdienste gewinnen. Das stellst du über GUI oder networksetup ein. Außerdem können Routen an ifscope gebunden sein, die System wählt explizit Interfaces für Ziele. route -n get zeigt Interface und Gateway. Wenn VPN für bestimmte Subnetze „Chef“ sein soll, muss es in der Reihenfolge nach oben und präzise Routen gesetzt werden.

DNS auf macOS ist komplex: scutil --dns zeigt Split-Szenarios, in denen interner Traffic per Unternehmens-DNS aufgelöst wird, der Rest über öffentliche Server. Falsche Reihenfolge führt zu mysteriösen Fehlern: IP geht, Name nicht. Löst sich durch Suchedomains, Resolver-Umsortierung und klare Interface-Zuweisung. 2026 können viele Firmen-VPN-Clients auf macOS per App domain-spezifische Regeln setzen, Kontrolle per Hand bleibt aber sinnvoll.

Gateways, NAT und asymmetrisches Routing

Standardgateway: Default Capture und Kill Switch

Wenn VPN 0.0.0.0/0 übernimmt, ist das normal für Full Tunnel. Es gibt kreative Umsetzungen: statt einer Defaultroute fügt der Client 0.0.0.0/1 und 128.0.0.0/1 ein, teilt somit die Welt und leitet beide Hälften über den Tunnel. Clever und kompatibel. Risiko entsteht, wenn der lokale Default nicht deaktiviert ist und je nach Metrik mal eine Route, mal die andere gewählt wird. Ergebnis sind chaotisches Internet. Hier besser explizite Prioritäten setzen oder Kill Switch aktivieren, der Ausgangsverkehr ohne VPN blockiert. Aber Achtung: Kill Switch kann das Internet komplett kappen, wenn der Tunnel fällt.

Doppelte Gateways und Multi-WAN bringen Würze: Zwei Provider, ein VPN, Rückweg kann über den „falschen“ Ausgang laufen. Router löst das mit Policy Routing und Markierungen, Hosts mit sorgsamer Metrikkonfiguration und Symmetrie. Wichtig: Paket muss dort raus, wo es reinkam. Sonst schmeißt der stateful Firewall Fremdantworten weg. Im Log findeste dann komische Einträge und ratlose Fragen: „Warum Ping klappt, aber App nicht?“

NAT-T, Hairpin und Rückkehr-Symmetrie

IPsec über NAT (NAT-T) ist Standard. Aber wenn der Client hinter Carrier-Grade NAT sitzt und der Server strikte Firewall hat, braucht es halt Lebenszeichen von beiden Seiten: Keepalive, korrekte Quellportbindung und sanfte Timeouts. Hairpin NAT (wenn man internen Dienst via externe Adresse anpingt) scheitert oft mit VPN: Client geht durch Tunnel, Server antwortet außen, Rückweg geht verloren. Lösung: Lokale DNS-Einträge für interne Domains und Verzicht auf Hairpin wo möglich.

ECMP und Load-Balancing über mehrere Links erzeugen Asymmetrie: Pakete eines Streams gehen unterschiedliche Wege. Firewalls mögen das nicht und kappen Verbindungen. Läuft VPN über mehrere Provider, aktiviere Stickiness per Quelle oder 5-tuple, und kontrolliere, dass Rückwege gleich bleiben. Symmetrie ist der Schlüssel für TCP-Gesundheit, vor allem mit Inspection.

Einseitiger Datenverkehr: rp_filter, Rückrouten und Firewalls

Unter Linux hängt rp_filter standardmäßig straff: Pakete werden verworfen, wenn die erwartete Rückroute nicht zur tatsächlichen passt. Bei komplexem PBR tut das richtig weh: Anfrage ging über Tabelle 100 im Tunnel, Antwort plant main über Internet – Kernel killt. Lösung: rp_filter auf loose oder Symmetrie herstellen. Auch Windows und macOS schützen sich gegen Spoofing mit Firewall-Regeln, die verdächtigen Traffic abblocken, wenn Pfade nicht passen.

Firewall und Applikationsinspektion (SSL-VPN, Proxy über 443, DPI) können unerwartet Traffic filtern und ungewöhnliche Fragmente droppen. Manchmal hilft es, smarte Inspektion kurz auszuschalten und Verhalten zu prüfen. Verschwindet das Problem, definiere Ausnahmen für VPN-Verkehr und aktiviere die Inspektion mit schärferen Regeln wieder.

Split Tunneling vs Full Tunnel: Wie wählt man richtig und konfiguriert ohne Stress?

Wann Split Tunneling dein Freund ist

Split Tunneling spart Bandbreite, reduziert Latenzen zu öffentlichen Diensten und entlastet VPN-Konzentratoren. 2026 ist das besonders wichtig: Videokonferenzen, CDN, SaaS wollen lokalen „Ausgang“. Einfaches Beispiel: Über VPN nur 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 und interne Domains, Internet sonst direkt. Nutzer sind glücklich, Admins auch, wenn Routen und DNS sauber sind. Risiko: Weniger Kontrolle auf externem Verkehr, DLP und lokale Filter sind nötig.

Richtiges Split heißt präzise Präfixe plus korrekter DNS. Bedingtes Domain-Forwarding einrichten, damit interne Namen nicht ins öffentliche Internet laufen. WireGuard: AllowedIPs sauber setzen. OpenVPN: redirect-gateway aus, gezielte Routen pushen. IKEv2: Traffic Selector und Include-Listen korrekt definieren. Denk an Ausnahmen für Banken, Behörden oder kritische Dienste, die per Policy durch den Tunnel oder immer lokal laufen müssen.

Wann Full Tunnel richtig und sicher ist

Full Tunnel ist Pflicht, wenn Compliance und Sicherheit wichtiger sind als Geschwindigkeit: sensible Daten, strenge Regulierungen, scharfe Grenzen. Du leitest gesamten Verkehr durch VPN, aktivierst Filter und Inspektion am Perimeter, bekommst zentrale Kontrolle. Das ist ein berechenbarer Weg, wenn Kapazitäten und MTU passen. Keine DNS-Leaks oder Konflikte mit lokalen Policies. Viele SSL-VPNs 2026 laufen über QUIC und bieten stolze Geschwindigkeit trotz Full Tunnel.

Nachteile: höhere Last auf Konzentratoren und potenziell mehr Latenz. Zwischenschritt: „Smart Full“ mit lokalem Breakout für Video oder CDN auf Gateway-Seite. Oder SASE-Struktur: Clients verbinden sich zur nächsten Point of Presence, dort laufen Policies. Planung der Kapazität und Monitoring der Metriken sind Pflicht: Ist Tunnel voll, spüren die Nutzer es schnell.

Designmuster: Include- und Exclude-Listen, DNS-Split und PAC

Definiere klar Ein- und Ausschlusslisten. Include-Listen eignen sich für Split: Schon vorab weißt du, welche Netze per VPN laufen. Exclude-Listen für Full, um „laute“ Bereiche zu trimmen. DNS mit Split-Horizon: interne Domains über Firmen-DNS, alles andere über öffentliche, idealerweise DoH/DoQ falls erlaubt. PAC-Dateien helfen beim Proxy-Management, damit Web-Apps bei gemischten Szenarien den richtigen Weg nehmen.

Dokumentiere alles in Playbooks: „Für neuen SaaS gelten diese Regeln; für neues VPC kommt dieser Präfix, plus Rückroute prüfen.“ Spart dir später Stunden. Und ja, bau Tests ein: Mini-Set mit curl, dig und traceroute, das automatisch nach Konfig-Änderungen läuft – deine Rettung bei Ausfällen.

Praxisbeispiele: Heimrouter, Cloud und Homeoffice

RFC1918-Konflikte: Wenn alle 10.0.0.0/8 haben und niemand Schuld hat

Mitarbeiter von zu Hause kommt mit 10.0.0.0/24, Firma hat 10.0.0.0/8. Routingtabelle beinhaltet spezifisch 10.10.20.0/24 via VPN und allgemein 10.0.0.0/8 via lokalem Gateway. Hat die allgemeine Route die niedrigere Metrik, gewinnt sie und Pakete umgehen den Tunnel. Diagnose: route print oder ip route, dann interne IP-Pings. Lösung: Metrik lokal erhöhen, spezifischere VPN-Präfixe setzen oder, im Notfall, NAT an den VPN-Endpunkten für Überschneidungen.

Langfristig besser, das „wild zusammengewürfelte“ 10.0.0.0/8 gegen klare Adressierung und Segmentierung zu tauschen. Viele migrieren 2026 zu dedizierten Blöcken und dokumentieren zentral. Wenn Migration dauert, nutze Policy Routing und SNAT am Gateway: Verkehr zu „Problem-Subnetzen“ zwingend durch VPN, der Rest lokal. Und denk an Rückrouten: Server müssen wissen, wie sie Clients mit untypischen Adressen antworten.

Clouds: AWS, Azure, GCP – P2S, BGP und Routing zwischen VPCs

Klassisches Problem: unterschiedliche Adressierung in mehreren Clouds. Zwischen VPC/VNet Peering, Transit-Hubs, Firewalls, dazu P2S VPN für Mitarbeiter. Fehlen exakte Routenankündigungen, sind manche Subnetze vom Client aus „unsichtbar“. Lösung: Zentrales Routing-Management: BGP wo möglich, statisches Exportieren von Cloud-Präfixen zu VPN-Konzentratoren mit Filterregeln. Check Clients: Wenn Default per VPN kommt, muss auch Rückweg aus der Cloud über selbigen Tunnel laufen.

Weiterer Fall: Überschneidende CIDRs zwischen Clouds. Entweder Adressänderung im Zeitverlauf oder zeitweiliger NAT. Wichtig: Tracing an jeder Station – vom Client zur Cloud-IP und zurück. MTR für interne IP in Cloud, tcpdump am Tunnelinterface und am Cloud-Firewall, um Paketverluste zu identifizieren. Mit kompletter Übersicht findet sich die Lösung: Ankündigung anpassen, Metrik ändern oder Rückroute reparieren.

Mobile und „IPv6-only“ Netze: NAT64, DNS64 und CGNAT

Mobilanbieter stellen oft nur IPv6 bereit und nutzen NAT64/DNS64, um IPv4-Zugriff zu ermöglichen. VPN über diesen Stapel funktioniert, hat aber Feinheiten. Wird IPv6 nicht vom VPN unterstützt, weicht Traffic über v6 um den Tunnel herum aus, Dienste reagieren merkwürdig. Lösung: IPv6-Support im VPN erweitern, Präfixe ergänzen, Routen checken, Filter setzen. DNS so einstellen, dass interne IPv4-Ressourcen korrekt aufgelöst werden, auch bei DNS64.

CGNAT beim Client erschwert Tunnel bei kurzen Timeouts und fehlendem Keepalive. WireGuard mit PersistentKeepalive, IKEv2 mit DPDP/DPD und Lifetimes. QUIC über 443 probieren – läuft oft besser. Wenn App per Name klappt, per IP nicht, prüfe Split-DNS: Ist der Resolver außerhalb VPN falsch, während der Firmen-Resolver korrekt antwortet? Häufig, aber lösbar.

Tools 2026: Observability, Telemetrie und neue Features

eBPF und Streaming-Telemetrie: Traffic komplett sehen

2026 ist eBPF Mainstream, nicht nur in Clustern sondern auf Workstations. Damit sieht man, welcher Prozess einen Socket erzeugte, welche Route gewählt wurde und wo Pakete verloren gehen. Tools wie Cilium Hubble für Server und leichtgewichtige Agenten auf Hosts helfen, komplexe PBR- und Asymmetrie-Fälle zu fassen. Vorteil: Man sieht, dass Browser Traffic durch VPN schickt, aber Updater direkt ins Internet, weil fwmark und Tabelle 200 den Verkehr lenken.

Unter Windows wächst pktmon und die Integration ins Network-Log, macOS hat pro App Profile, Linux bietet bpftrace-Skripte zur schnellen Analyse. Kombiniert mit zentralen Dashboards: Tunnel-Latenz, MTU-Fehler, Anteil Split/Full Traffic, Top-Domains. Sichtbarkeit verwandelt „funktioniert nicht“ in exakte Fakten: „Um 11:42 fiel bei 30 % der Clients PMTUD im Link Fernost aus.“

Simulierte Tests und Health Checks: Reagieren, bevor es brennt

Starte synthetische Tests: Ping zu wichtigen Subnetzen, HTTPS zu internen Portalen, DNS-Anfragen zu Zielzonen, von verschiedenen Punkten und Policies. Lass die Tests jede Minute laufen und Alarm schlagen bei Anomalien. Auf dem Client ein leichter Agent mit Host- und Ziel-Liste, auf der VPN-Seite Health-Check-API mit Tunnelstatus, Erneuerungen und Auth-Fehlern. Gutes Alerting spart Nerven und Zeit.

Führe „Canary“-Routen ein: Wenige Test-Clients erhalten Konfiguration früher. Bricht etwas, leiden nicht alle. Diese DevOps-Praxis funktioniert auch im Networking. Arbeite mit Change-Logs: Wer hat wann Präfixe geändert? Rollback per Knopfdruck. Transparenz ist kein Luxus, sondern Schutz vor Menschfehlern.

Intelligente Hilfe und Tipps: Von LLM bis zum VPN-Advisor

Nicht jeder mag „KI überall“, aber in der Praxis hilft sie. Ein Konsolen-Assistent, der basierend auf ip route und traceroute Konflikte findet, rettet nachts. Lokal, ohne externe Anfragen. Beispiel: Es gibt 10.20.0.0/16 und 10.20.5.0/24, /16 hat niedrigere Metrik – also Metrik anheben oder präzisere Route ergänzen. Oder DNS-Resolver für internal.corp zeigt auf öffentlich – bedingtes Forwarding zum Firmen-DNS wird empfohlen.

Viele VPN-Clients 2026 bringen automatische Checks mit: MTU-Diagnose, DNS-Leak-Tests, Validierung von Split-Listen vor Anwendung. Beschwert sich der Client, ist Hinhören sinnvoll. Diese Checks erwischen oft Probleme, die sonst erst im Produktivbetrieb auffallen. Log-Level hochsetzen: Schweigt der Log, rätselst du. Sagts der Log, hast du Fakten.

Sicherheit, Performance und Feintuning

MTU, MSS-Clamping und PMTUD-Black-Holes

Zu großes MTU im Tunnel führt zu unerklärlichen Hängern. Seite lädt halb, dann Stopp. Lösung: MTU sinnvoll wählen und TCP MSS-Clamping aktivieren. Unter Linux via nftables/iptables MSS auf sichere Werte reduzieren (z.B. 1360–1380 für meist UDP-basierte Tunnel). Prüfe PMTUD: Werden ICMPs geblockt, versagt Mechanismus. Hilft manchmal hartes MSS-Fixing oder ICMP auf Firewalls erlauben. Mach A/B-Tests: Vorher und nachher. Unterschied ist oft deutlich.

Mit QUIC und HTTP/3 über 443 ist Sensibilität anders, aber Problem bleibt. Tunnel über UDP mag fragmentierte Pakete nicht und blockiert große Datagramme – führt zu Qualitätseinbußen. Faustregel: lieber mit konservativem MTU starten und steigern, statt zu groß zu wählen. Und dokumentiere die Konfiguration fürs Team, sonst vergisst du morgen, was gut lief.

DNS: Split-Horizon, DoH/DoQ und Resolver-Reihenfolge

DNS kann deinen Tag machen oder zerstören. Interne Domains über öffentliche Resolver? Das gibt NXDOMAIN oder schlimmer falsch. Nutze Split-Horizon: Firmenzonen per Firmenresolver, der Rest per öffentlichen, ideal mit DoH/DoQ, wenn policy-konform. Windows prüfe Interface-DNS-Reihenfolge, macOS mit scutil --dns, Linux mit resolvectl. VPN-Client kann Domains Resolvern zuordnen – dann einschalten.

DNS Leak Protection ist 2026 Standard. Viele Clients prüfen, wohin Queries wirklich gehen. Starte regelmäßig Tests: interne Anfragen müssen durch Tunnel, öffentliche wie geplant. Cache vergessen nicht: Cache leeren und neu anfragen – einfacher Schritt, der oft hilft.

IPv6-first, ULA und „Happy Eyeballs“

IPv6 ist nicht mehr „Gast“, sondern Gastgeber. Ignoriert dein VPN v6, umgehst du Policies und kriegst unerwartetes Verhalten. Füge Routen für ULA und globale IPv6 hinzu, stell sicher, dass Filter Protokolle und Ports erlauben. Teste Happy Eyeballs: Apps wählen v4 oder v6 nach Latenz. Wenn v6 außerhalb und v4 im Tunnel geht, herrscht Durcheinander. Einheitliche Strategie wählen: Beide Stacks im VPN oder klarer Split mit DNS- und Routingkontrolle.

IPv6 verzichtet auf klassisches NAT, Symmetrie-Probleme treten aber deutlicher zutage. Rückrouten sorgfältig konfigurieren. Große MTU in v6 ist Plus, aber nur, wenn PMTUD funktioniert. Sonst beginnt das Laden der Seite wieder zu hängen. Halte Checklisten bereit, damit das nicht passiert.

Checklisten, Playbooks und Automatisierung

Checkliste „Keine Panik“ – Schnelle Schritte in 10 Minuten

Erstens: Verbindung auf IP und Name prüfen. Zweitens: traceroute zu internem und externem Ziel. Drittens: Routentabelle und Interface-Metriken anschauen. Viertens: DNS-Resolver und Split checken. Fünftens: MTU prüfen und MSS reduzieren. Sechstens: Pakete an VPN- und lokalem Interface mitschneiden. Siebtens: Rückroute vom Server checken. Achtens: Smarte Inspektion temporär aus, Verhalten prüfen. Neuntens: Client- und Serverkonfiguration abgleichen. Zehntens: Funde dokumentieren und festhalten.

Die Checkliste klingt simpel, spart aber Stunden. Folge ihr Schritt für Schritt, spring nicht drüber. Manchmal liegt die Lösung bei Punkt zwei, manchmal bei neun. Hauptsache, du behältst den Überblick und schreibst mit. In einem Monat wirst du deinem früheren Ich dankbar sein.

Playbooks für Windows, Linux und macOS

Windows: Auto-Metric am VPN-Interface deaktivieren, InterfaceMetric manuell setzen, RouteMetric bei Konflikt-Subnetzen prüfen. Diagnose mit route print und PowerShell. DNS: Interface-Priorität und korrekter Resolver für interne Domains. Linux: ip rule und Routingtabellen checken, Prioritäten ordnen, fwmark konfigurieren falls nötig. WireGuard: Vorsichtig bei AllowedIPs. MSS Clamping konfigurieren und PMTUD prüfen. macOS: Service-Reihenfolge per networksetup, scutil --dns für Resolver prüfen, route -n get zur Interface-Auswahl. VPN-Logs und Sniffer überall dabei.

Vergiss Änderungsmuster nicht: YAML-Dateien mit Subnetzen, Metriken, DNS-Domains und Regeln. In Git verwalten, Review machen und Canary-Tests durchlaufen. Bei Problemen: Rollback per Commit. So zähmst du das Chaos und machst Veränderungen sicher. Automatisierung ersetzt nicht den Verstand, entlastet ihn aber fürs Wesentliche.

GitOps für Routen: prüfen und sicher anwenden

Infrastructure as Code hat auch Routing erreicht. Sichere Präfix- und Ausnahmelisten in Repos speichern. Pull Request öffnen, automatisch synthetische Tests in Staging und Canary starten. Bei Erfolg Rollout auf alle Clients oder VPN-Server, sonst Rollback und Analyse. Kein „Bei Peter ist’s aktueller, bei Maria läuft’s“. Transparent und reproduzierbar.

Füge statische Tests hinzu: CIDR-Validator, verbiete sich überschneidende Präfixe ohne explizites Flag, prüfe, dass neue Routen nicht das Internet der Nutzer verstopfen. Und natürlich ein Log, wer was wann genehmigt hat. So verwandelst du Chaos in beherrschbaren Prozess. Nutzer sind keine Beta-Tester mehr.

FAQ: Kurze Antworten auf häufige Fragen

Wieso habe ich nach VPN-Verbindung kein Internet?

Meistens hat der VPN-Client die Defaultroute (full tunnel) übernommen, und der Rückweg ins Internet fehlt oder wird vom Kill Switch blockiert. Check deine Routingtabelle: Gibt es 0.0.0.0/0, 0.0.0.0/1 und 128.0.0.0/1, und wie sind deren Metriken? Mach ein traceroute zu einer öffentlichen IP: Liegt der erste Hop im Tunnel, sollte Internet durch VPN gehen. Tut es das nicht, prüfe DNS (vielleicht zeigt der Resolver auf interne Server ohne externen Zugriff) oder MTU (große Pakete bleiben stecken). Schnelltest: MSS verkleinern, Öffentliches DNS temporär eintragen, Kill Switch deaktivieren und Routen-Symmetrie wiederherstellen.

Wie löse ich Konflikte bei gleichen Subnetzen auf Client und Firma?

Drei Wege: 1) Firmenweite Adressänderung (zuverlässig, aber langwierig), 2) temporäres NAT für Konflikt-Subnetz an der VPN-Grenze (schnell, aber komplex), 3) Policy-Based Routing mit gezielten Routen zu betroffenen Präfixen und erhöhte Metrik beim allgemeinen Client-Subnetz. Starte mit Diagnose: route print/ip route, schau, welche Route gewinnt. Ergänze spezifischere VPN-Präfixe, um den allgemeinen zu übersteuern. Überprüfe Rückrouten auf Servern und Firewall-Regeln. Trag den Konflikt ins Adressregister ein – für dauerhafte Lösung statt Monat-für-Monat Symptomfix.

Was ist besser: Split Tunneling oder Full Tunnel?

Wenn Priorität Sicherheit und Kontrolle haben, wähle Full Tunnel. Für Performance und Traffic-Optimierung, besonders bei öffentlichen Diensten, lieber Split. Kompromiss: Full mit lokalem Breakout am Gateway oder SASE-Ansatz mit Policy-Anwendung an nächster PoP. Vergiss nicht DNS und MTU: Fehlkonfiguration bei Split kann interne Services unsichtbar machen oder Leaks verursachen. Ideal: Kannary-Tests, Metrikmessung und erst dann breiter Rollout. Blind wählen endet meist in Nacharbeit.

Warum pingt es, aber Webseiten öffnen sich nicht?

Ping nutzt ICMP, Webseiten TCP/UDP über HTTP(S). Läuft ICMP, hängt TCP? Check MTU und MSS: Große Segmente werden unterwegs abgeschnitten, PMTUD scheitert an ICMP Fragmentation Needed Blockade. DNS-Problem? IP geht, Name nicht? Schau, welcher Resolver genutzt wird und ob Queries außerhalb VPN gehen. Drittens: Firewall oder SSL-Inspection blockiert Traffic, etwa bei QUIC. Nutze Sniffer: Siehst du SYN, aber kein SYN-ACK? Such Rückroute und Serverfilter.

Wie stelle ich die Priorität von Netzwerkinterfaces und Routen ein?

Windows: Auto-metric abschalten, InterfaceMetric für VPN manuell setzen, relevante RouteMetrics einstellen. Prüfe mit Get-NetRoute und route print. Linux: Nicht nur ip route anschauen, sondern ip rule für Prioritäten. macOS: Service-Reihenfolge per networksetup anpassen, route -n get für Zieladresse prüfen. System-Devise: Kleinere Metrik und längerer Präfix gewinnen. Dokumentiere alle Settings, um Magie zu vermeiden.

Wie diagnostiziere ich Probleme nur mit IPv6?

Prüfe zuerst, ob VPN IPv6 unterstützt und passende Routen (z. B. ULA und globale Präfixe) vorhanden sind. Ping6/tracepath6 zu interner v6-Adresse testen, ip -6 route oder route print -6 checken. DNS: AAAA-Einträge für interne Domains müssen über Firmenresolver laufen. MTU ist bei v6 extrem wichtig, Blockade von ICMPv6 bricht Verbindungen. Wenn Apps über v6 außerhalb VPN laufen dank Happy Eyeballs, dann Passe Policy an: Beide IP-Stacks zusammen oder IPv6 für bestimmte Routen ausschalten. VPN-Logs und Sniffer liefern die finale Diagnose.