OpenVPN på Android lägger inte till rutt utan tunneladress

Din Android-OpenVPN-profil lägger inte till en rutt eftersom telefonen inte har någon adress på det virtuella gränssnittet, så det finns ingenting en rutt kan peka på. Rutter svarar bara på vart paketen ska ta vägen. Tunneladressen svarar på vem telefonen är inne i tunneln, och klienten måste leverera en innan gränssnittet kan finnas. Gå igenom de fyra kontrollerna nedan i ordning och stanna vid första felet, eftersom att redigera rutter innan adressen finns döljer det egentliga problemet.

Läs felet i den ordning klienten utför det

Androids VpnService.Builder håller de två begreppen åtskilda: addAddress() sätter en adress på gränssnittet appen bygger, addRoute() lägger till ett destinationsprefix, och establish() vägrar skapa gränssnittet förrän minst en adress lagts till. En OpenVPN-klient mappar profilen och de alternativ servern skickar exakt till dessa anrop, så en anslutning som aldrig tolkar en adress kan inte bygga gränssnittet alls.

Det är därför loggrader du läser kan nämna en rutt medan orsaken ligger ett steg tidigare. Klienten når ruttsteget först efter att gränssnittet finns; utan adress misslyckas ruttanropet omedelbart eller körs aldrig. När loggen säger att den inte kan lägga till en rutt, börja med adressen och inte med ruttens syntax.

Kontroll 1: sätter servern en adress i svaret?

För en routad OpenVPN-tjänst kommer adressen från serverns pool eller från en tilldelning per klient, och topologin avgör vilken form den har. På en server med OpenVPN 2.4 eller senare ser en tjänst med subnätstopologi ut så här:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Med den formen skickar servern något i stil med ifconfig 10.8.0.6 255.255.255.0. En äldre topology net30-installation skickar i stället en peer-adress, till exempel ifconfig 10.8.0.6 10.8.0.5, så en profil som flyttas mellan de två modellerna kan se korrekt ut medan den bär fel nätmask.

Sök i klientens anslutningslogg efter uppsättningen skickade alternativ. Om den inte innehåller en enda ifconfig-rad har servern aldrig skickat en adress eller så har klienten avvisat alternativet. På en server som använder client-config-dir måste filen som är uppkallad efter certifikatets common name finnas och innehålla tilldelningen:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontroll 2: behåller klienten adressen den fick?

Ett för brett filter är den näst vanligaste orsaken. pull-filter finns i OpenVPN 2.4 och senare, och när flera filter matchar samma alternativ vinner det sista som matchar, så en catch-all på slutet tar bort adressen utan fel:

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

Begränsa filtret till det alternativ du faktiskt vill bli av med och låt adressen vara:

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

Rådet att stänga av alla pull kommer oftast från någon som vill bli av med en enda rutt. route-nopull är den smalare brytaren: den behåller ifconfig och de andra skickade alternativen men avvisar skickade rutter och DHCP-liknande alternativ. Använd den när det verkligen är vad du vill, och svara på adressfrågan separat.

Kontroll 3: är adressen din att skriva?

Manuell adressering är bara legitim när operatören ger dig värdet. Skriver du en själv måste den komma från VPN-klientens subnät, vara unik bland aktiva sessioner och matcha topologin servern kör. Att kopiera adressen från en skrivbordsbrygga eller en värd på det avlägsna LAN-et misslyckas på båda punkterna: telefonen skulle hävda en adress som redan finns någon annanstans, och gatewayen skulle inte ha någon returväg till den.

Det avlägsna LAN-prefixet i en rutt är en destination, aldrig telefonens identitet. En rutt för 10.60.0.0/24 säger att nätverket nås genom tunneln; den säger ingenting om vilken 10.60.0.x-adress telefonen borde ha, och telefonen borde inte ha någon av dem. Statiska tilldelningar hör hemma på serversidan, där de inte kan kollidera med den dynamiska poolen.

Två sessioner på en identitet avslöjar samma kollision. Om samma certifikat ansluter två gånger och servern skickar en fast adress till båda, duplicerar den andra sessionen den första, och lösningen är separata identiteter eller separata tilldelningar i stället för en ändring på klientsidan.

Kontroll 4: håller något annat tunnelplatsen?

Android tillåter bara en aktiv VPN-tjänst åt gången. En annan VPN-app, eller en alltid-på VPN-post som lämnats påslagen för en profil som inte längre fungerar, kan ta den platsen innan din OpenVPN-klient anropar establish(). Då visas aldrig gränssnittet trots att profilen är giltig, så koppla från den andra VPN:en, stäng av alltid-på-inställningen och anslut igen innan du rör profilen.

En tjänst som insisterar på Ethernet-bryggning är den andra återvändsgränden. En Android-app utan root kan skapa en IP-tunnel, inte ett bryggat Ethernet-segment, så ingen adress du skriver får en dev tap-server att fungera; operatören måste erbjuda en routad tjänst. När du rapporterar problemet, ta med klientnamn och version, uppsättningen skickade alternativ, topologin och det exakta steg där adressen borde ha dykt upp.

Om alla fyra kontrollerna passerar och adressen finns, är unik och korrekt maskerad, blir ruttfrågan den vanliga: vilka prefix servern auktoriserar och hur klienten bör avgränsa dem. Skriv ner tunneladressen, dess nätmask och topologin innan du ändrar något annat, eftersom det är dessa tre värden operatören behöver jämföra med serverns vy.