OpenVPN på Android legger ikke til rute uten tunneladresse

OpenVPN-klienter på Android kan ikke legge til ruter før telefonen har en tunneladresse. Kontroller hvem som tildeler den, hvilke pull-filtre som dropper den, og når du må skrive den inn selv.

Android-OpenVPN-profilen din legger ikke til en rute fordi telefonen ikke har noen adresse på det virtuelle grensesnittet, så det er ingenting en rute kan peke på. Ruter svarer bare på hvor pakkene skal gå. Tunneladressen svarer på hvem telefonen er inne i tunnelen, og klienten må levere en før grensesnittet kan eksistere. Gå gjennom de fire kontrollene nedenfor i rekkefølge og stopp ved første feil, fordi å redigere ruter før adressen finnes skjuler det egentlige problemet.

Les feilen i den rekkefølgen klienten utfører den

Androids VpnService.Builder holder de to begrepene atskilt: addAddress() setter en adresse på grensesnittet appen bygger, addRoute() legger til et destinasjonsprefiks, og establish() nekter å opprette grensesnittet før minst én adresse er lagt til. En OpenVPN-klient mapper profilen og alternativene serveren dytter inn på nøyaktig disse kallene, så en forbindelse som aldri parser en adresse kan ikke bygge grensesnittet i det hele tatt.

Derfor kan logglinjen du leser nevne en rute mens årsaken ligger ett steg tidligere. Klienten når rutesteget først etter at grensesnittet finnes; uten adresse feiler rutekallet umiddelbart eller kjører aldri. Når loggen sier at den ikke kan legge til en rute, start med adressen og ikke med rutesyntaksen.

Kontroll 1: setter serveren en adresse i svaret?

For en rutet OpenVPN-tjeneste kommer adressen fra tjenerens basseng eller fra en tildeling per klient, og topologien avgjør hvilken form den har. På en OpenVPN 2.4 eller nyere tjener ser en tjeneste med subnett-topologi slik ut:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Med den formen dytter tjeneren noe som ifconfig 10.8.0.6 255.255.255.0. En eldre topology net30-installasjon dytter i stedet en peer-adresse, for eksempel ifconfig 10.8.0.6 10.8.0.5, så en profil som flyttes mellom de to modellene kan se riktig ut mens den bærer feil nettmaske.

Søk i klientens tilkoblingslogg etter settet med dyttede alternativer. Hvis det ikke inneholder en eneste ifconfig-linje, har tjeneren aldri sendt en adresse, eller klienten har avvist alternativet. På en tjener som bruker client-config-dir, må filen som er oppkalt etter common name på sertifikatet finnes og inneholde tildelingen:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontroll 2: beholder klienten adressen den fikk?

Et for bredt filter er den nest vanligste årsaken. pull-filter finnes i OpenVPN 2.4 og nyere, og når flere filtre passer på samme alternativ, vinner det siste som passer, så en catch-all på slutten fjerner adressen uten feil:

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

Begrens filteret til alternativet du faktisk vil bli kvitt, og la adressen være i fred:

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

Rådet om å slå av alle pull kommer som regel fra noen som vil bli kvitt én enkelt rute. route-nopull er den smalere bryteren: den beholder ifconfig og de andre dyttede alternativene mens den avviser dyttede ruter og DHCP-lignende alternativer. Bruk den når det virkelig er det du vil, og svar på adresse-spørsmålet separat.

Kontroll 3: er adressen din å skrive?

Manuell adressering er bare legitim når operatøren gir deg verdien. Skriver du en selv, må den komme fra VPN-klientens subnett, være unik blant aktive økter og passe til topologien tjeneren kjører. Å kopiere adressen til en skrivebordsbro eller en vert på det eksterne LAN-et feiler på begge punkter: telefonen ville kreve en adresse som allerede finnes andre steder, og gatewayen ville ikke ha noen returvei til den.

Det eksterne LAN-prefikset i en rute er en destinasjon, aldri telefonens identitet. En rute for 10.60.0.0/24 sier at nettverket nås gjennom tunnelen; den sier ingenting om hvilken 10.60.0.x-adresse telefonen skal ha, og telefonen skal ikke ha noen av dem. Statiske tildelinger hører hjemme på tjenersiden, der de ikke kan kollidere med det dynamiske bassenget.

To økter på én identitet avdekker den samme kollisjonen. Hvis det samme sertifikatet kobler til to ganger og tjeneren dytter én fast adresse til begge, dupliserer den andre økten den første, og løsningen er separate identiteter eller separate tildelinger i stedet for en endring på klientsiden.

Kontroll 4: holder noe annet tunnelplassen?

Android tillater bare én aktiv VPN-tjeneste om gangen. En annen VPN-app, eller en alltid-på VPN-oppføring som er latt på for en profil som ikke lenger virker, kan ta den plassen før OpenVPN-klienten din kaller establish(). Da vises aldri grensesnittet selv om profilen er gyldig, så koble fra den andre VPN-en, slå av alltid-på-innstillingen og koble til på nytt før du rører profilen.

En tjeneste som insisterer på Ethernet-broing er den andre blindveien. En Android-app uten root kan lage en IP-tunnel, ikke et broet Ethernet-segment, så ingen adresse du skriver får en dev tap-tjener til å virke; operatøren må tilby en rutet tjeneste. Når du rapporterer problemet, ta med klientnavn og versjon, settet med dyttede alternativer, topologien og det nøyaktige steget der adressen skulle ha dukket opp.

Hvis alle fire kontrollene består og adressen er til stede, unik og riktig maskert, blir rutespørsmålet det vanlige: hvilke prefikser tjeneren autoriserer, og hvordan klienten bør avgrense dem. Skriv ned tunneladressen, nettverksmasken og topologien før du endrer noe annet, fordi det er disse tre verdiene operatøren trenger å sammenligne med tjenerens visning.

Relaterte artikler