dev tun unter Windows zeigt weiterhin einen TAP-Adapter. Ist das falsch?

Der Geräte-Manager zeigt einen TAP-Windows Adapter V9, während das Profil dev tun sagt, und der Tunnel funktioniert. Diese Kombination ist keine Fehlkonfiguration, und ein Hin- und Herschalten des Modus ändert daran nichts. Der Adaptername spiegelt wider, welchen Windows-Treiber der Client geladen hat, nicht welche Pakete der Tunnel transportiert. Lies die Treiberzeile im Client-Log, bevor du irgendetwas änderst.

Warum ein Layer-3-Tunnel einen Ethernet-Adapter bekommt

Für den größten Teil der Windows-Geschichte des Clients existierte kein brauchbarer virtueller Layer-3-Adapter. Die einzige Option war der TAP-Windows-Treiber, der eine Ethernet-Schnittstelle bereitstellt. Der Client emulierte dann das fehlende Layer-2-Verhalten, damit Windows ihn konfigurieren konnte. Diese Emulation ist der Grund, warum der Adapter noch immer wie eine Netzwerkkarte aussieht.

Zwei Teile dieser Emulation sind sichtbar, wenn man hinschaut: Der Client beantwortet ARP für die Tunneladresse, und er stellt der lokalen Maschine ein kleines DHCP-Lease bereit. Windows sieht daher einen normalen Ethernet-Adapter mit MAC-Adresse und NDIS-Treiber, während der Tunnel selbst reine IP-Pakete trägt. Das Ethernet-Kostüm gehört zum Treiber, nicht zum Tunnelmodus.

Lies die Treiberzeile, statt nach dem Namen zu urteilen

Zwei Adapter können sich über Treiberversionen hinweg einen Namen teilen, daher kann der Name allein nicht sagen, was gelaufen ist. Das Client-Log nennt das Gerät, das es geöffnet hat, und bei neueren Builds auch den Treiber, den es gewählt hat; das ist die Zeile, die du lesen musst.

Prüfe drei Dinge im Log, in dieser Reihenfolge: ob der Client überhaupt einen Adapter geöffnet hat, welchen Treiber er meldet und ob er nach einem Fehler zurückgefallen ist. Eine Fallback-Zeile ist leicht zu übersehen, weil die Verbindung trotzdem zustande kommt und der Tunnel dann mit dem älteren Treiber läuft, während der Nutzer glaubt, der neue sei aktiv.

Wechsle zum Layer-3-Treiber und prüfe, was vorhanden sein muss

Der vom WireGuard-Projekt ausgelieferte Layer-3-Treiber ist ab Client-Version 2.5 verfügbar, aber er ist optional. Eine einzige Direktive wählt ihn aus:

windows-driver wintun

Der Treiber muss auf dem Rechner installiert sein, und offizielle Builds enthalten eine signierte Kopie. Liefere diese signierte Version aus, wenn du den Client selbst paketierst, denn ein privat gebauter Treiber kollidiert mit den Kopien, die andere VPN-Produkte installieren. Diese Kollisionen erzeugen Fehler, die schwer zuzuordnen sind, und sie treten meist auf, nachdem ein zweiter VPN-Client auf dem Rechner eingetroffen ist. Ein fehlender Treiber hinterlässt dagegen eine klare Zeile im Log.

Der Treiber erzwingt außerdem strengere Berechtigungen, sodass der Client den Adapter über seinen interaktiven Dienst erstellt, der als privilegiertes Konto läuft. Startest du den Client als normalen Benutzerprozess ohne diesen Dienst, kann die Direktive fehlschlagen, was den zuvor installierten Adapter sichtbar lässt und so aussieht, als sei der Wechsel ignoriert worden.

Wann TAP weiterhin die richtige Antwort ist

Wenn der Tunnel Ethernet-Frames, Broadcast-Verkehr oder Nicht-IP-Protokolle tragen muss, ist ein Layer-2-Adapter erforderlich, und der TAP-Treiber folgt aus dieser Anforderung. Ein gebrücktes Design unter Windows hat dieselbe Einschränkung, da die Schnittstelle einer Layer-2-Domäne beitreten muss.

Leistung ist auf der Ebene des Adapternamens kein Grund, das eine dem anderen vorzuziehen. Version 2.6 fügt einen Data-Channel-Offload-Treiber hinzu, der die Paketverarbeitung in den Kernel verlagert, und das ist die Option, die die Durchsatzeigenschaften ändert. Es ist eine Fähigkeitsentscheidung und keine Voraussetzung fürs Verbinden, und sie hängt vom Build und vom installierten Paket ab. Ein Profil, das ohne sie funktioniert, funktioniert weiter.

Nach dem Wechsel aufräumen

Den alten Adapter zu entfernen ist genauso wichtig wie den neuen hinzuzufügen. Eine zurückgebliebene TAP-Schnittstelle kann eine Adresse und eine Route aus einer früheren Sitzung behalten, und diese Einträge überleben die Verbindung, die sie erzeugt hat. Lösche das veraltete Gerät im Geräte-Manager, verbinde dich dann erneut und bestätige, dass die Routing-Tabelle es nicht mehr nennt.

Wenn mehrere VPN-Produkte installiert sind, notiere, welches Treiberpaket jedes mitbringt, bevor du das Profil debugst. Zwei Clients, die unterschiedliche Builds desselben Treibers installieren, sind ein Konflikt, den keine Profilbearbeitung löst. Deinstalliere den ungenutzten Client, starte neu und suche dann im Geräte-Manager nach doppelten Adaptern. Erst danach lohnt es sich, Logzeilen zwischen den beiden Produkten zu vergleichen.