Was TUN tut und was das VPN-Protokoll noch tun muss

tun0 und ein VPN-Protokoll als eine Sache zu behandeln, führt Menschen ins falsche Log. Die Schnittstelle ist eine lokale Grenze, an der ein Programm im Userspace IP-Pakete mit dem Kernel austauscht. Das Protokoll ist das, was das Programm mit den Paketen anstellt, sobald es sie hat: Transport, Authentifizierung, Verschlüsselung und ein Gegenüber. Das Anlegen des Geräts wählt nichts davon aus.

Zwei Komponenten, ein Paketweg

Der Kernel schreibt ein IP-Paket in das Gerät, und das Programm liest es über einen Dateideskriptor. In der anderen Richtung schreibt das Programm ein Paket zurück, und der Kernel leitet es weiter, als wäre es auf einer echten Schnittstelle angekommen. TUN trägt IP, TAP dagegen Ethernet-Frames. Ein Paket an dieser Grenze zu lesen zeigt die Rahmenbildung, und genau dafür ist das Gerät da.

Alles jenseits dieser Grenze ist Sache des Programms. Zwei Programme können dasselbe Schnittstellenkonzept nutzen und völlig verschiedene Dinge mit den Paketen tun. Das Gerät selbst hat keine Meinung dazu, was als Nächstes passiert. Der Dateideskriptor ist der einzige Griff, den das Programm auf der Kernelseite hat.

Gerät anlegen, dann die Grenze beobachten

Lege ein Gerät bewusst an, wenn du die Grenze testest. Ein persistentes Gerät überlebt den Prozess, der es erzeugt hat, was für Experimente nützlich ist und danach eine häufige Quelle von Verwirrung. Prüfe die Flags und den Eigentümer, bevor du das VPN beschuldigst.

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

Die Link-Details zeigen den Gerätetyp und den zugeordneten Eigentümer. Wenn kein Prozess es offen hält, gehen die hineingeschriebenen Pakete nirgendwohin. Ein Gerät ohne zugeordneten Prozess kann in einer Link-Liste gesund aussehen und trotzdem nichts durchreichen.

Was der Schnittstellenname nicht versprechen kann

Der Schnittstellenname sagt nichts über Verschlüsselung oder Authentifizierung. Ein Programm kann Pakete in TLS, in ein eigenes Protokoll, in IPsec oder in gar nichts packen. TUN statt TAP zu wählen ändert die Rahmenbildung an der Grenze, nicht das Sicherheitsdesign. Die Wahl der Rahmenbildung ist real, und sie ist viel kleiner als die Sicherheitsfrage.

Erkennung funktioniert genauso: Ein Beobachter sieht das äußere Protokoll auf der Leitung, kein Etikett, das sagt, welches lokale Gerät es erzeugt hat. Ein Tunnel, der wie etwas anderes aussieht, tut das wegen seines äußeren Protokolls, nicht wegen seines Schnittstellennamens. Ein Beobachter kann nicht sehen, welches lokale Gerät ein Paket erzeugt hat, nur wie das Paket aussieht. Halte diese beiden Fragen auseinander, wenn du Produkte vergleichst, denn eine Antwort impliziert nie die andere.

Die Reparatur zur fehlschlagenden Stufe passen

Trenne die Fehlerstufen, wenn etwas kaputtgeht. Ein fehlendes Gerät, ein Berechtigungsfehler und eine abgelehnte Anmeldung liefern unterschiedliche Belege und unterschiedliche Reparaturen. Lies zuerst den lokalen Zustand, dann das eigene Log des Programms, dann die Sicht des Gegenübers. Lies alle drei, bevor du etwas änderst.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

Wenn das Gerät existiert und ein Prozess es hält, arbeitet die lokale Grenze, und das Problem liegt weiter draußen. Wenn das Gerät fehlt, hilft keine noch so gründliche Prüfung der Zugangsdaten. Eine Stufe, die du benennen kannst, ist eine Stufe, die du testen kannst. Die TUN/TAP-Dokumentation beschreibt die Grenze und das Gerätemodell.