Android OpenVPN: een privéroute toevoegen zonder de telefoon te rooten

Je hebt nog één privésubnet nodig — zeg 10.60.0.0/24 — dat het profiel nu niet bevat. Op een laptop zou je een route toevoegen en doorgaan. Op Android is de VPN een app, het tun-apparaat hoort bij die app, en er is geen routetabel die je zonder root kunt aanpassen. De route moet er toch zijn, maar hij komt in het profiel dat de client laadt, en hij werkt alleen als de andere kant instemt. Hier volgen de wijziging, het opnieuw verbinden, de serverkant en het terugdraaien.

Vóór de wijziging: wat een route wel en niet kan

Een route beantwoordt één vraag: welke interface moet het verkeer naar deze bestemming dragen. Hij machtigt niets. Als de netwerkeigenaar niet heeft ingestemd dat deze telefoon dat subnet mag bereiken, levert een correcte route een configuratie op die er correct uitziet en een stille drop bij de gateway, en je brengt het volgende uur door met het bewerken van het verkeerde bestand.

Haal die instemming eerst, schriftelijk als het netwerk een eigenaar heeft. Noteer daarna wat je niet doet: je geeft de telefoon geen adres binnen dat LAN, je wijzigt de listener van de server niet en je kiest geen site op hostnaam. Dat zijn vier verschillende wijzigingen en alleen de eerste is van jou.

Bewerk het profiel dat de client echt laadt

Voor een compatibele client die gewone OpenVPN-optietekst importeert, is de toevoeging één regel:

route 10.60.0.0 255.255.255.0

Voeg hem toe aan de body van het profiel, bij de andere routingdirectieven, en laat de endpoint, certificaten, sleutelafhandeling en verificatieregels van de operator precies zoals ze waren. Plak geen heel oud voorbeeld om één regel te lenen: compressie, absolute bestandspaden en verouderde cipher-instellingen reizen mee en kosten je een aparte debug-sessie.

De stap die mensen overslaan is het eigendom van het bestand. Als de app een profiel heeft geïmporteerd, is de kopie die hij gebruikt van de app, en het bewerken van het gedownloade origineel verandert niets. Gebruik de ondersteunde editor van de client, of importeer het bewerkte bestand opnieuw via het updatepad, en bevestig de naam van het actieve profiel wanneer er meerdere vergelijkbare namen zijn. Noteer welke je hebt gewijzigd.

Als het profiel al route-nopull bevat, wordt er geen enkele route van de server geïnstalleerd en moet elk prefix dat de telefoon nodig heeft expliciet worden vermeld. Dat is een legitiem ontwerp, maar het betekent dat een weggelaten regel er precies zo uitziet als een weigering van de server.

Verbind opnieuw en controleer op het apparaat

Verbreek eerst de verbinding en verbind daarna opnieuw met het specifieke profiel dat je hebt bewerkt, in plaats van de app de laatste sessie te laten herstellen. Open het verbindingslog en bevestig dat de client de nieuwe regel heeft geparseerd; een routedirectief dat de interface negeert, is een veelvoorkomend gevolg van het bewerken van de verkeerde kopie.

Test de bestemming op adres, niet op naam. Een TCP-controle naar één bekende servicepoort zegt meer dan een ping, omdat veel hosts ICMP beantwoorden terwijl de servicepoort gefilterd is. Als het adres antwoordt en een naam niet, heb je een resolvervraag en geen routingvraag, en de volgende sectie is niet voor jou.

Hier horen ook twee scope-controles bij. VPN per app betekent dat een adresroute aanwezig kan zijn terwijl de app waarmee je test buiten de inbegrepen set valt, dus test met een app die er echt in zit. En een IPv4-prefix zegt niets over het IPv6-pad; als de dienst dual-stack is, voeg de bijbehorende IPv6-route toe of verwacht dat de client een pad verkiest dat je niet bedoelde.

Eén negatief resultaat is de moeite waard om vroeg te herkennen: als een full-tunnelroute al 0.0.0.0/0 dekt, ontbreekt het prefix niet en verandert opnieuw toevoegen niets. Dubbele dekking repareert geen weigering aan de serverkant en geen ontbrekend antwoord.

Maak het pad af op de server

Drie dingen moeten waar zijn buiten de telefoon. De gateway heeft een route naar de bestemming nodig en toestemming om de bron van de telefoon daarheen door te sturen. Het doel moet die bron accepteren en antwoorden via de gateway terugsturen, anders heeft het ontwerp bewuste vertaling bij de uitgang nodig. De route-optie uit de OpenVPN-handleiding dekt het directief aan de clientkant; doorsturen en retourroutering zijn afzonderlijke instellingen op afzonderlijke machines.

Als de bestemming achter een andere VPN-client zit in plaats van direct achter de gateway, heeft de server een iroute nodig voor het subnet van die peer. Dat directief is eigendom van de server en beschrijft welke client een prefix bezit; een telefoon kan het niet uit zijn eigen profiel leveren, en geen enkele hoeveelheid bewerken aan de clientkant vervangt het.

Controleer het retourpad expliciet. Een antwoord dat via de standaardroute naar buiten gaat in plaats van via de tunnel, levert het klassieke halfopen symptoom: de verbinding komt in één richting tot stand en er komt niets terug. Bronvertaling op de gateway is een legitieme oplossing wanneer het doel niet terug kan routeren, maar het is een beleidsbeslissing met eigen gevolgen.

Terugdraaien en acceptatie

Bewaar het vorige profiel voordat je het bewerkt. Als de wijziging de situatie verslechtert, herstel die kopie via hetzelfde herimportpad, verbind opnieuw en bevestig dat het oude gedrag terugkomt — dat bevestigt dat je hebt gewijzigd wat je dacht te wijzigen. Een terugdraaiing die de oude toestand niet herstelt, betekent dat de app een derde kopie vasthoudt die je niet hebt gevonden.

Accepteer de wijziging wanneer vier dingen gelden, in deze volgorde getest na een nieuwe verbinding: de bestemming antwoordt op zijn servicepoort, de privénaam wordt opgelost als die wordt verwacht, HTTPS valideert nog steeds de bedoelde hostnaam, en het geheel werkt nog na een herstart of een overstap van Wi-Fi naar mobiel. De laatste controle is degene die een route vangt die alleen bestaat tot Android de tunnel opnieuw opzet.

• Bevestig vóór elke bewerking dat de netwerkeigenaar de bestemming toestaat.
• Zet de route in het profiel dat de client laadt, importeer daarna opnieuw en verbind opnieuw.
• Controleer via de servicepoort, binnen de scope per app, voor de juiste adresfamilie.
• Herstel doorsturen, retourroutering en iroute op de server, niet op de telefoon.
• Bewaar een terugdraaikopie en test opnieuw na een herstart.