Android-OpenVPN ohne Tunneladresse: keine Route

Android-OpenVPN-Clients fügen keine Routen hinzu, solange dem Telefon eine Tunneladresse fehlt. Prüfe, wer sie vergibt, was Pull-Filter verwerfen und wann du selbst eine eintragen darfst.

Dein OpenVPN-Profil kann keine Route hinzufügen, weil das Telefon keine Adresse auf der virtuellen Schnittstelle hat und eine Route damit auf nichts zeigen kann. Routen sagen nur, wohin Pakete gehen. Die Tunneladresse sagt, wer das Telefon im Tunnel ist, und der Client muss eine setzen, bevor die Schnittstelle entstehen kann. Gehe die vier Prüfungen unten der Reihe nach durch und halte beim ersten Fehler an, denn Routen zu ändern, bevor die Adresse da ist, verdeckt das eigentliche Problem.

Lies den Fehler in der Reihenfolge, in der der Client ihn ausführt

Androids VpnService.Builder trennt beide Begriffe: addAddress() legt eine Adresse auf die Schnittstelle, die die App gerade baut, addRoute() fügt ein Zielpräfix hinzu, und establish() verweigert die Schnittstelle, solange keine Adresse gesetzt ist. Ein OpenVPN-Client bildet Profil und gepushte Optionen genau auf diese Aufrufe ab, also kann eine Verbindung ohne Adresse die Schnittstelle gar nicht erst bauen.

Darum nennt die Logzeile, die du liest, vielleicht eine Route, obwohl die Ursache einen Schritt früher liegt. Der Client erreicht die Route erst, wenn die Schnittstelle steht; ohne Adresse scheitert der Aufruf sofort oder läuft nie. Wenn das Log sagt, es könne keine Route hinzufügen, fang bei der Adresse an und nicht bei der Routensyntax.

Prüfung 1: Steht im Antwortpaket des Servers eine Adresse?

Bei einem gerouteten OpenVPN-Dienst kommt die Adresse aus dem Serverpool oder aus einer Zuweisung pro Client, und die Topologie bestimmt ihre Form. Auf einem OpenVPN 2.4 Server mit Subnetz-Topologie sieht das so aus:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Damit pusht der Server etwa ifconfig 10.8.0.6 255.255.255.0. Eine ältere topology net30-Bereitstellung pusht stattdessen eine Peer-Adresse, zum Beispiel ifconfig 10.8.0.6 10.8.0.5, sodass ein zwischen beiden Modellen verschobenes Profil korrekt wirken kann, aber die falsche Netzmaske trägt.

Suche im Verbindungslog des Clients nach den gepushten Optionen. Fehlt dort jede ifconfig-Zeile, hat der Server nie eine Adresse gesendet oder der Client hat die Option abgelehnt. Bei einem Server mit client-config-dir muss die Datei, die nach dem Common Name im Zertifikat benannt ist, existieren und die Zuweisung enthalten:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Prüfung 2: Behält der Client die zugewiesene Adresse?

Ein zu breiter Filter ist die zweite häufige Ursache. pull-filter gibt es ab OpenVPN 2.4, und wenn mehrere Filter auf dieselbe Option passen, gewinnt der letzte, sodass ein abschließender Catch-all die Adresse ohne Fehler entfernt:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Verenge den Filter auf die Option, die wirklich weg soll, und lass die Adresse in Ruhe:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Der Rat, alle Pulls abzuschalten, kommt meist von jemandem, der eine einzelne Route loswerden will. route-nopull ist der engere Schalter: Er behält ifconfig und die übrigen gepushten Optionen und lehnt nur gepushte Routen und DHCP-Optionen ab. Nutze ihn, wenn du genau das willst, und beantworte die Adressfrage getrennt.

Prüfung 3: Darfst du die Adresse selbst eintragen?

Manuelle Adressierung ist nur zulässig, wenn der Betreiber dir den Wert gibt. Tippst du selbst eine ein, muss sie aus dem VPN-Client-Subnetz stammen, unter aktiven Sitzungen eindeutig sein und zur Topologie des Servers passen. Die Adresse einer Desktop-Bridge oder eines Hosts im entfernten LAN zu kopieren scheitert doppelt: Das Telefon würde eine anderswo bereits vergebene Adresse beanspruchen, und das Gateway hätte keinen Rückweg dorthin.

Das entfernte LAN-Präfix in einer Route ist ein Ziel, nie die Identität des Telefons. Eine Route für 10.60.0.0/24 sagt: erreiche dieses Netz durch den Tunnel; sie sagt nichts darüber, welche 10.60.0.x-Adresse das Telefon haben soll, und es soll keine davon haben. Statische Zuweisungen gehören auf die Serverseite, wo sie nicht mit dem dynamischen Pool kollidieren.

Zwei Sitzungen auf einer Identität zeigen dieselbe Kollision. Verbindet sich dasselbe Zertifikat zweimal und pusht der Server beiden eine feste Adresse, doppelt die zweite Sitzung die erste; getrennte Identitäten oder getrennte Zuweisungen sind die Lösung, nicht eine Änderung am Client.

Prüfung 4: Belegt etwas anderes den Tunnelplatz?

Android erlaubt nur einen aktiven VPN-Dienst. Eine andere VPN-App oder ein Always-on-Eintrag für ein nicht mehr funktionierendes Profil kann den Platz belegen, bevor dein OpenVPN-Client establish() aufruft. Dann erscheint die Schnittstelle nie, obwohl das Profil gültig ist; trenne also das andere VPN, schalte Always-on aus und verbinde neu, bevor du das Profil anfasst.

Ein Dienst, der auf Ethernet-Bridging besteht, ist die andere Sackgasse. Eine Android-App ohne Root kann einen IP-Tunnel bauen, kein gebrücktes Ethernet-Segment, also macht keine eingetippte Adresse einen dev tap-Server funktionsfähig; der Betreiber muss einen gerouteten Dienst anbieten. Melde das Problem mit Clientname und Version, gepushter Optionsliste, Topologie und dem genauen Schritt, an dem die Adresse hätte erscheinen müssen.

Wenn alle vier Prüfungen bestehen und die Adresse vorhanden, eindeutig und richtig maskiert ist, wird die Routenfrage die gewöhnliche: welche Präfixe der Server erlaubt und wie der Client sie zuschneiden soll. Notiere Tunneladresse, Netzmaske und Topologie, bevor du etwas anderes änderst, denn diese drei Werte braucht der Betreiber für den Vergleich mit der Serversicht.

Ähnliche Artikel