Android OpenVPN: eine private Route hinzufügen, ohne das Telefon zu rooten

Sie brauchen ein weiteres privates Subnetz — sagen wir 10.60.0.0/24 —, das das Profil derzeit nicht enthält. Auf einem Laptop würden Sie eine Route hinzufügen und weitermachen. Unter Android ist das VPN eine App, das tun-Gerät gehört dieser App, und es gibt keine Routing-Tabelle, die Sie ohne root bearbeiten könnten. Die Route muss trotzdem existieren, aber sie gehört in das Profil, das der Client lädt, und sie funktioniert nur, wenn die Gegenseite zustimmt. Hier kommen die Änderung, die Neuverbindung, die Serverseite und der Rückbau.

Vor der Änderung: was eine Route kann und was nicht

Eine Route beantwortet eine Frage: welche Schnittstelle den Verkehr zu diesem Ziel tragen soll. Sie autorisiert nichts. Wenn der Netzwerkeigentümer nicht zugestimmt hat, dass dieses Telefon dieses Subnetz erreichen darf, erzeugt eine korrekte Route eine korrekt aussehende Konfiguration und einen stillen Drop am Gateway, und Sie verbringen die nächste Stunde damit, die falsche Datei zu bearbeiten.

Holen Sie diese Zustimmung zuerst ein, schriftlich, wenn das Netzwerk einen Eigentümer hat. Notieren Sie dann, was Sie nicht tun: Sie weisen dem Telefon keine Adresse innerhalb dieses LAN zu, Sie ändern nicht den Listener des Servers, und Sie wählen keine Site über einen Hostnamen aus. Das sind vier verschiedene Änderungen, und nur die erste ist Ihre.

Bearbeiten Sie das Profil, das der Client tatsächlich lädt

Für einen kompatiblen Client, der gewöhnlichen OpenVPN-Optionstext importiert, ist die Ergänzung eine Zeile:

route 10.60.0.0 255.255.255.0

Fügen Sie sie in den Rumpf des Profils ein, in der Nähe der anderen Routing-Direktiven, und lassen Sie Endpoint, Zertifikate, Schlüsselbehandlung und Prüfzeilen des Betreibers genau so, wie sie waren. Kleben Sie kein ganzes altes Beispiel ein, um eine Zeile zu borgen: Kompression, absolute Dateipfade und veraltete Cipher-Einstellungen reisen mit und kosten Sie eine separate Debugging-Sitzung.

Der Schritt, den viele übersehen, ist der Besitz der Datei. Wenn die App ein Profil importiert hat, gehört die Kopie, die sie verwendet, der App, und das Bearbeiten des heruntergeladenen Originals ändert nichts. Verwenden Sie den unterstützten Editor des Clients oder importieren Sie die bearbeitete Datei über den Update-Pfad erneut, und bestätigen Sie den Namen des aktiven Profils, wenn mehrere ähnliche Namen existieren. Halten Sie fest, welche Sie geändert haben.

Trägt das Profil bereits route-nopull, wird keine Route vom Server installiert, und jedes Präfix, das das Telefon braucht, muss ausdrücklich aufgeführt werden. Das ist ein legitimes Design, bedeutet aber, dass eine ausgelassene Zeile genauso aussieht wie eine Ablehnung durch den Server.

Neu verbinden und auf dem Gerät prüfen

Trennen Sie zuerst die Verbindung, und verbinden Sie dann genau das Profil neu, das Sie bearbeitet haben, statt die App die letzte Sitzung wiederherstellen zu lassen. Öffnen Sie das Verbindungslog und bestätigen Sie, dass der Client die neue Zeile geparst hat; eine Routing-Direktive, die das Frontend ignoriert, ist ein häufiges Ergebnis des Bearbeitens der falschen Kopie.

Testen Sie das Ziel über die Adresse, nicht über den Namen. Eine TCP-Prüfung auf einen bekannten Dienstport sagt mehr als ein Ping, weil viele Hosts ICMP beantworten, während der Dienstport gefiltert ist. Antwortet die Adresse und ein Name nicht, haben Sie eine Resolver-Frage und keine Routing-Frage, und der nächste Abschnitt ist nicht für Sie.

Zwei Scope-Prüfungen gehören ebenfalls hierher. Per-App-VPN bedeutet, dass eine Adressroute vorhanden sein kann, während die App, mit der Sie testen, außerhalb der eingeschlossenen Menge liegt; testen Sie also mit einer App, die tatsächlich darin liegt. Und ein IPv4-Präfix sagt nichts über den IPv6-Pfad; ist der Dienst dual-stack, fügen Sie die entsprechende IPv6-Route hinzu oder rechnen Sie damit, dass der Client einen Pfad bevorzugt, den Sie nicht beabsichtigt haben.

Ein negatives Ergebnis lohnt sich, früh zu erkennen: Deckt eine Full-Tunnel-Route bereits 0.0.0.0/0 ab, fehlt das Präfix nicht, und es erneut hinzuzufügen ändert nichts. Doppelte Abdeckung repariert keine Ablehnung auf der Serverseite und keine fehlende Antwort.

Den Pfad auf dem Server zu Ende bringen

Drei Dinge müssen über das Telefon hinaus stimmen. Das Gateway braucht eine Route zum Ziel und die Erlaubnis, die Quelle des Telefons dorthin weiterzuleiten. Das Ziel muss diese Quelle akzeptieren und Antworten über das Gateway zurückschicken, oder das Design braucht eine bewusste Übersetzung am Egress. Die route-Option des OpenVPN-Handbuchs deckt die Client-Direktive ab; Weiterleitung und Rückweg-Routing sind getrennte Einstellungen auf getrennten Maschinen.

Liegt das Ziel hinter einem anderen VPN-Client statt direkt hinter dem Gateway, braucht der Server eine iroute für das Subnetz dieses Peers. Diese Direktive gehört dem Server und beschreibt, welcher Client ein Präfix besitzt; ein Telefon kann sie nicht aus seinem eigenen Profil liefern, und keine Menge clientseitiger Bearbeitung ersetzt sie.

Prüfen Sie den Rückweg ausdrücklich. Eine Antwort, die über die Default-Route statt über den Tunnel hinausgeht, erzeugt das klassische halboffene Symptom: Die Verbindung ist in eine Richtung aufgebaut, und es kommt nichts zurück. Quellübersetzung am Gateway ist eine legitime Lösung, wenn das Ziel nicht zurückrouten kann, aber es ist eine Richtungsentscheidung mit eigenen Folgen.

Rückbau und Abnahme

Bewahren Sie das vorherige Profil auf, bevor Sie es bearbeiten. Verschlechtert die Änderung die Lage, stellen Sie diese Kopie über denselben Reimport-Weg wieder her, verbinden Sie neu, und bestätigen Sie, dass das alte Verhalten zurückkehrt — das bestätigt, dass Sie geändert haben, was Sie zu ändern glaubten. Ein Rückbau, der den alten Zustand nicht wiederherstellt, bedeutet, dass die App eine dritte Kopie hält, die Sie noch nicht gefunden haben.

Nehmen Sie die Änderung an, wenn vier Dinge gelten, in dieser Reihenfolge nach einer frischen Neuverbindung geprüft: Das Ziel antwortet auf seinem Dienstport, der private Name löst auf, wenn einer erwartet wird, HTTPS validiert weiterhin den beabsichtigten Hostnamen, und das Ganze funktioniert noch nach einem Neustart oder einem Wechsel von Wi-Fi zu Mobilfunk. Die letzte Prüfung ist die, die eine Route erwischt, die nur besteht, bis Android den Tunnel neu aufbaut.

• Bestätigen Sie vor jeder Änderung, dass der Netzwerkeigentümer das Ziel erlaubt.
• Setzen Sie die Route in das Profil, das der Client lädt, importieren Sie dann neu und verbinden Sie neu.
• Prüfen Sie über den Dienstport, innerhalb des Per-App-Scopes, für die richtige Adressfamilie.
• Beheben Sie Weiterleitung, Rückweg-Routing und iroute auf dem Server, nicht auf dem Telefon.
• Behalten Sie eine Rückbau-Kopie und testen Sie nach einem Neustart erneut.