Android OpenVPN tilføjer ikke en rute uden en tunneladresse

Din Android-OpenVPN-profil kan ikke tilføje en rute, fordi telefonen ikke har nogen adresse på det virtuelle interface, så der er intet, en rute kan pege på. Ruter svarer kun på, hvor pakker skal hen. Tunneladressen svarer på, hvem telefonen er inde i tunnelen, og klienten skal levere en, før interfacet kan eksistere. Gå gennem de fire kontroller nedenfor i rækkefølge, og stop ved den første fejl, fordi redigering af ruter før adressen findes skjuler det egentlige problem.

Læs fejlen i den rækkefølge, klienten udfører den

Androids VpnService.Builder holder de to begreber adskilt: addAddress() sætter en adresse på det interface, appen bygger, addRoute() tilføjer et destinationspræfiks, og establish() nægter at oprette interfacet, før mindst én adresse er tilføjet. En OpenVPN-klient mapper profilen og de optioner, serveren pusher, over på præcis disse kald, så en forbindelse, der aldrig parser en adresse, kan slet ikke bygge interfacet.

Derfor kan den loglinje, du læser, nævne en rute, mens årsagen ligger et skridt tidligere. Klienten når først rutetrinnet, efter interfacet findes; uden adresse fejler rutekaldet med det samme eller kører aldrig. Når loggen siger, at den ikke kan tilføje en rute, så start med adressen i stedet for rutesyntaksen.

Kontrol 1: sætter serveren en adresse i svaret?

For en routet OpenVPN-tjeneste kommer adressen fra serverpuljen eller fra en tildeling pr. klient, og topologien bestemmer, hvilken form den har. På en OpenVPN 2.4- eller nyere server ser en tjeneste med subnet-topologi sådan ud:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Med den form pusher serveren noget i retning af ifconfig 10.8.0.6 255.255.255.0. En ældre topology net30-opsætning pusher i stedet en peer-adresse, for eksempel ifconfig 10.8.0.6 10.8.0.5, så en profil, der flyttes mellem de to modeller, kan se korrekt ud, mens den bærer den forkerte netmaske.

Søg i klientens forbindelseslog efter det pushed option-sæt. Hvis det slet ikke indeholder en ifconfig-linje, har serveren aldrig sendt en adresse, eller klienten har afvist optionen. På en server, der bruger client-config-dir, skal filen opkaldt efter common name på certifikatet findes og indeholde tildelingen:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontrol 2: beholder klienten den adresse, den fik?

Et filter, der er for bredt, er den næstmest almindelige årsag. pull-filter findes i OpenVPN 2.4 og senere, og når flere filtre matcher den samme option, vinder den sidst matchende, så et afsluttende catch-all fjerner adressen uden fejl:

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

Indsnævr filteret til den option, du faktisk vil af med, og lad adressen være:

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

Rådet om at slå alle pulls fra kommer normalt fra en, der vil af med en enkelt rute. route-nopull er den smallere kontakt: den beholder ifconfig og de øvrige pushed optioner, mens den afviser pushed ruter og DHCP-lignende optioner. Brug den, når det virkelig er det, du vil, og besvar adresse-spørgsmålet separat.

Kontrol 3: er adressen din at skrive?

Manuel adressering er kun legitim, når operatøren giver dig værdien. Skriver du selv en, skal den komme fra VPN-klientens subnet, være unik blandt aktive sessioner og matche den topologi, serveren kører. At kopiere adressen fra en desktop-bro eller en vært på det fjernede LAN fejler på begge punkter: telefonen ville gøre krav på en adresse, der allerede findes andre steder, og gatewayen ville ikke have nogen returvej til den.

Det fjernede LAN-præfiks i en rute er en destination, aldrig telefonens identitet. En rute for 10.60.0.0/24 siger, at netværket nås gennem tunnelen; den siger intet om, hvilken 10.60.0.x-adresse telefonen skal have, og telefonen bør ikke have nogen af dem. Statiske tildelinger hører til på serversiden, hvor de ikke kan kollidere med den dynamiske pulje.

To sessioner på én identitet afslører den samme kollision. Hvis det samme certifikat forbinder to gange, og serveren pusher én fast adresse til begge, duplikerer den anden session den første, og adskilte identiteter eller adskilte tildelinger er løsningen frem for en ændring på klientsiden.

Kontrol 4: holder noget andet tunnelslotten?

Android tillader kun én aktiv VPN-tjeneste ad gangen. En anden VPN-app eller en always-on VPN-post, der er efterladt aktiveret for en profil, som ikke længere virker, kan tage den slot, før din OpenVPN-klient kalder establish(). Så vises interfacet aldrig, selv om profilen er gyldig, så afbryd den anden VPN, slå always-on-indstillingen fra, og genopret forbindelsen, før du rører profilen.

En tjeneste, der kræver Ethernet-bridging, er den anden blindgyde. En Android-app uden root kan oprette en IP-tunnel, ikke et bridget Ethernet-segment, så ingen adresse, du skriver, får en dev tap-server til at virke; operatøren må tilbyde en routet tjeneste. Når du rapporterer problemet, skal du medtage klientnavn og -version, det pushed option-sæt, topologien og det præcise trin, hvor adressen burde være dukket op.

Hvis alle fire kontroller består, og adressen er til stede, unik og korrekt maskeret, bliver rutespørgsmålet det sædvanlige: hvilke præfikser serveren autoriserer, og hvordan klienten bør afgrænse dem. Skriv tunneladressen, dens netmaske og topologien ned, før du ændrer noget andet, fordi de tre værdier er dem, operatøren skal sammenholde med serverens visning.