OpenVPN op Android voegt geen route toe zonder tunneladres

Je OpenVPN-profiel op Android voegt geen route toe omdat de telefoon geen adres op de virtuele interface heeft, dus er is niets waar een route naar kan wijzen. Routes beantwoorden alleen waar pakketten heen moeten. Het tunneladres beantwoordt wie de telefoon binnen de tunnel is, en de client moet er een leveren voordat de interface kan bestaan. Doorloop de vier controles hieronder in volgorde en stop bij de eerste fout, want routes bewerken voordat het adres bestaat verbergt het echte probleem.

Lees de fout in de volgorde waarin de client hem uitvoert

De VpnService.Builder van Android houdt de twee begrippen gescheiden: addAddress() zet een adres op de interface die de app bouwt, addRoute() voegt een bestemmingsprefix toe, en establish() weigert de interface te maken tot minstens één adres is toegevoegd. Een OpenVPN-client mapt het profiel en de opties die de server pusht precies op die aanroepen, dus een verbinding die nooit een adres parseert kan de interface helemaal niet bouwen.

Daarom kan de logregel die je leest een route noemen terwijl de oorzaak een stap eerder zit. De client bereikt de routefase pas nadat de interface bestaat; zonder adres faalt de route-aanroep meteen of draait hij nooit. Als de log zegt dat er geen route kan worden toegevoegd, begin dan bij het adres en niet bij de routesyntaxis.

Controle 1: zet de server een adres in het antwoord?

Voor een gerouteerde OpenVPN-dienst komt het adres uit de pool van de server of uit een toewijzing per client, en de topologie bepaalt welke vorm het heeft. Op een OpenVPN 2.4 of nieuwere server ziet een dienst met subnettopologie er zo uit:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Met die vorm pusht de server iets als ifconfig 10.8.0.6 255.255.255.0. Een oudere topology net30-installatie pusht in plaats daarvan een peeradres, bijvoorbeeld ifconfig 10.8.0.6 10.8.0.5, dus een profiel dat tussen de twee modellen wordt verplaatst kan er correct uitzien terwijl het het verkeerde netmasker draagt.

Zoek in de verbindingslog van de client de set gepushte opties. Staat er geen enkele ifconfig-regel in, dan heeft de server nooit een adres gestuurd of heeft de client de optie geweigerd. Op een server die client-config-dir gebruikt, moet het bestand dat naar de common name van het certificaat is genoemd bestaan en de toewijzing bevatten:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Controle 2: houdt de client het adres dat hij kreeg?

Een te breed filter is de tweede veelvoorkomende oorzaak. pull-filter bestaat in OpenVPN 2.4 en nieuwer, en wanneer meerdere filters op dezelfde optie passen wint de laatste die past, dus een catch-all aan het eind verwijdert het adres zonder fout:

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

Beperk het filter tot de optie waar je echt van af wilt en laat het adres met rust:

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

Het advies om alle pull uit te schakelen komt meestal van iemand die één enkele route kwijt wil. route-nopull is de smallere schakelaar: hij houdt ifconfig en de andere gepushte opties terwijl hij gepushte routes en DHCP-achtige opties weigert. Gebruik hem als dat werkelijk is wat je wilt, en beantwoord de adresvraag apart.

Controle 3: is het adres aan jou om te typen?

Handmatige adressering is alleen legitiem als de operator jou de waarde geeft. Typ je er zelf een, dan moet die uit het subnet van de VPN-client komen, uniek zijn onder actieve sessies en passen bij de topologie die de server draait. Het adres van een desktopbrug of een host op het externe LAN kopiëren faalt op beide punten: de telefoon zou een adres claimen dat al elders bestaat, en de gateway zou geen retourpad ernaar hebben.

Het prefix van het externe LAN in een route is een bestemming, nooit de identiteit van de telefoon. Een route voor 10.60.0.0/24 zegt dat dat netwerk via de tunnel bereikbaar is; hij zegt niets over welk 10.60.0.x-adres de telefoon zou moeten hebben, en de telefoon zou er geen van moeten hebben. Statische toewijzingen horen aan de serverkant, waar ze niet met de dynamische pool kunnen botsen.

Twee sessies op één identiteit leggen dezelfde botsing bloot. Als hetzelfde certificaat twee keer verbindt en de server één vast adres naar beide pusht, dupliceert de tweede sessie de eerste, en de oplossing is gescheiden identiteiten of gescheiden toewijzingen in plaats van een aanpassing aan de clientkant.

Controle 4: houdt iets anders de tunnelsleuf bezet?

Android staat slechts één actieve VPN-dienst tegelijk toe. Een andere VPN-app, of een always-on VPN-item dat aan blijft staan voor een profiel dat niet meer werkt, kan die sleuf innemen voordat je OpenVPN-client establish() aanroept. Dan verschijnt de interface nooit, ook al is het profiel geldig, dus verbreek de andere VPN, zet de always-on-instelling uit en verbind opnieuw voordat je het profiel aanraakt.

Een dienst die op Ethernet-bridging staat, is de andere doodlopende weg. Een Android-app zonder root kan een IP-tunnel maken, geen overbrugd Ethernet-segment, dus geen enkel adres dat je typt laat een dev tap-server werken; de operator moet een gerouteerde dienst aanbieden. Als je het probleem meldt, voeg dan de clientnaam en -versie, de set gepushte opties, de topologie en de exacte stap toe waarin het adres had moeten verschijnen.

Als alle vier controles slagen en het adres aanwezig, uniek en correct gemaskeerd is, wordt de routevraag de gewone: welke prefixen de server autoriseert en hoe de client ze moet afbakenen. Noteer het tunneladres, het netmasker en de topologie voordat je iets anders wijzigt, want die drie waarden zijn wat de operator met de serverkant moet vergelijken.