TAP oder TUN? OpenVPN-Clients für Android und überbrückte Server

Ein Profil, das auf einem Laptop funktioniert, scheitert auf dem Telefon. Der naheliegende Schritt ist, ein Wort in der Client-Konfiguration zu ändern. Dieses Wort wird nicht helfen, weil die beiden Enden nicht von derselben Art Verkehr sprechen.

TAP überträgt Ethernet-Frames. TUN überträgt IP-Pakete. Einer Android-VPN-App wird eine IP-Schnittstelle übergeben, was eine der beiden Anordnungen möglich macht und die andere nicht, unabhängig davon, was die Konfiguration sagt.

Der Vergleich ist kurz, aber er entscheidet, ob Sie das auf dem Telefon reparieren können oder den Dienst ändern müssen.

Zwei Tunneltypen mit unterschiedlichen Nutzdaten

Eine TAP-Schnittstelle verhält sich wie ein Ethernet-Adapter. Sie überträgt Frames, also ARP, Broadcast und alles andere, was ein LAN unterhalb von IP überträgt. Das ermöglicht die Überbrückung: Der Tunnel erweitert eine Broadcast-Domäne, und Clients verhalten sich, als wären sie an einen Switch angeschlossen.

Eine TUN-Schnittstelle überträgt IP-Pakete, die an sie adressiert sind. Es gibt keine Sicherungsschicht auszuhandeln, kein ARP und keinen Broadcast. Das Routing entscheidet, was in den Tunnel gelangt, und die Serverkonfiguration verwendet ein Subnetz statt einer Brücke.

Beide Enden müssen sich einig sein, welche der beiden Varianten sie betreiben. dev tap auf einer Seite durch dev tun zu ersetzen, wandelt den Dienst nicht um; es entsteht ein Client, der einen gerouteten Tunnel erwartet, und ein Server, der weiterhin Frames schickt, und der Handshake kann gelingen, während nichts Brauchbares durchkommt.

Was Android der App tatsächlich übergibt

Die VpnService-API der Plattform gibt einer App eine virtuelle Schnittstelle für IP-Pakete, konfiguriert mit Adressen, Routen und einer MTU. In dieser API gibt es keinen Ethernet-Adapter, und die App kann keinen herbeizaubern.

Deshalb dokumentiert OpenVPN Connect die Unterstützung gerouteter TUN-Verbindungen unter Android statt TAP-Bridging. Die Android-FAQ ist die clientseitige Aussage zu dieser Grenze, und sie entspricht der Plattform-API.

Netzwerkwerkzeuge mit Root-Rechten, eigene Firmware oder ein Produkt mit einer ausdrücklichen Übersetzungsschicht sind andere Anordnungen. Der Normalfall ist der, um den Sie planen sollten: eine App, die Ihre Datei importieren und als normaler Benutzer laufen kann, mit einer IP-Schnittstelle und nichts darunter.

Wie es aussieht, wenn Sie es trotzdem versuchen

Die Verbindung kommt meist zustande. Genau das macht den Fehler verwirrend: Der Client meldet verbunden, das Serverprotokoll zeigt einen Peer, und keine Anwendung funktioniert.

Verkehr, der an die zugewiesene Adresse des Telefons adressiert ist, kommt nicht an, weil der Server Frames an eine MAC-Adresse brückt, die das Telefon nie hatte. Broadcast-abhängige Erkennung bleibt leer. Verlässt sich das LAN auf DHCP über die Brücke, erhält das Telefon so keine Lease, und eine manuell zugewiesene Adresse im überbrückten Subnetz erzeugt die fehlende Schnittstelle trotzdem nicht.

Manche Clients scheitern früher, beim Profilimport, wenn sie einen Gerätetyp sehen, den sie nicht umsetzen können. Beide Verhaltensweisen bedeuten dasselbe, und keine von beiden wird durch zusätzliche Routen, eine Änderung des DNS oder eine Erweiterung des Adressbereichs des Tunnels behoben.

Was die Serverseite ändern muss

Die Korrektur liegt bei dem, der den VPN-Dienst betreibt, und sie ist meist ergänzend statt eine Migration. Betreiben Sie eine zweite OpenVPN-Instanz mit einem gerouteten Gerät, einem eigenen Client-Subnetz und einer Serverkonfiguration, die Adressen zuweist und die Routen verteilt, die die Telefone brauchen. Die bestehende überbrückte Instanz bedient weiterhin die Geräte, die wirklich Ethernet brauchen.

Zwei Details machen das in der Praxis funktionsfähig. Das LAN braucht eine Rückroute für das neue Client-Subnetz, die auf den VPN-Host zeigt, sonst kommen Antworten nie zurück. Und die Firewall auf dem Tunnel-Host muss zwischen der Tunnelschnittstelle und dem LAN weiterleiten, und das ist der Schritt, der am häufigsten vergessen wird, wenn ein Test vom Host selbst gelingt.

Kann der Betreiber keinen Dienst hinzufügen, ist die Alternative ein Gerät, das der Brücke beitreten kann, also ein Laptop oder ein Router, der im Namen des Telefons handelt. Das ist ein Behelf mit eigenen Verwaltungskosten, keine Android-Konfiguration.

Entscheiden Sie von der Anwendung aus, nicht vom Tunnel

Fragen Sie, was das Telefon tatsächlich erreichen muss, und bilden Sie es dann ab. Eine Dateifreigabe oder eine Intranetseite, die über Namen oder Adresse erreicht wird, ist eine IP-Anforderung, und ein gerouteter Tunnel erfüllt sie, sobald DNS den Namen auflöst und die Route existiert. Ein Erkennungswerkzeug, das die lokale Broadcast-Domäne durchsucht, ist keine IP-Anforderung, und keine Menge Routing wird es füllen.

Diese Tabelle ist zugleich die Anfrage, die Sie senden. Benennen Sie die Anwendung, die Adresse oder den Namen, den sie verwendet, und ob sie von Erkennung abhängt. Ein Betreiber kann auf diese Beschreibung reagieren, was niemand auf ein Telefon kann, das sich nicht verbindet.

Schließlich, behalten Sie den TAP-Dienst für die Geräte, die ihn brauchen, statt jeden Client einen LAN-Adapter nachahmen zu lassen. Zwei Dienste mit klaren Zwecken sind leichter zu betreuen als einer, der für alle halb funktioniert.