Android OpenVPN: lägg till en privat rutt utan att roota telefonen

Du behöver ett privat subnät till — säg 10.60.0.0/24 — som profilen inte innehåller just nu. På en laptop skulle du lägga till en rutt och gå vidare. På Android är VPN en app, tun-enheten tillhör den appen och det finns ingen routingtabell att redigera utan root. Rutten måste ändå finnas, men den hamnar i profilen som klienten läser in, och den fungerar bara om andra sidan håller med. Här är ändringen, återanslutningen, serversidan och återställningen.

Före ändringen: vad en rutt kan och inte kan göra

En rutt svarar på en fråga: vilket gränssnitt som ska bära trafiken till den här destinationen. Den auktoriserar ingenting. Om nätverkets ägare inte har godkänt att den här telefonen kan nå det subnätet ger en korrekt rutt en konfiguration som ser korrekt ut och ett tyst tapp i gatewayen, och du tillbringar nästa timme med att redigera fel fil.

Skaffa det godkännandet först, skriftligt om nätverket har en ägare. Notera sedan vad du inte gör: du tilldelar inte telefonen en adress i det LANet, du ändrar inte serverns lyssnare och du väljer inte en plats efter värdnamn. Det är fyra olika ändringar och bara den första är din.

Redigera profilen som klienten faktiskt läser in

För en kompatibel klient som importerar vanlig OpenVPN-optionstext är tillägget en rad:

route 10.60.0.0 255.255.255.0

Lägg till den i profilens kropp, nära de andra routingdirektiven, och lämna operatörens endpoint, certifikat, nyckelhantering och verifieringsrader exakt som de var. Klistra inte in ett helt gammalt exempel för att låna en rad: komprimering, absoluta filsökvägar och föråldrade cipher-inställningar följer med och kostar dig en separat felsökningssession.

Steget folk missar är ägandet av filen. Om appen importerade en profil är kopian den använder appens, och att redigera den nedladdade originalet ändrar ingenting. Använd klientens stödda redigerare, eller importera den redigerade filen igen via uppdateringsvägen, och bekräfta namnet på den aktiva profilen när det finns flera liknande namn. Anteckna vilken du ändrade.

Om profilen redan har route-nopull installeras ingen rutt från servern, och varje prefix telefonen behöver måste listas uttryckligen. Det är en legitim design, men det betyder att en utelämnad rad ser exakt ut som en avvisning från servern.

Anslut igen och verifiera på enheten

Koppla från först och anslut sedan igen till just den profil du redigerade i stället för att låta appen återställa den senaste sessionen. Öppna anslutningsloggen och bekräfta att klienten har tolkat den nya raden; ett routingdirektiv som gränssnittet ignorerar är ett vanligt resultat av att redigera fel kopia.

Testa destinationen efter adress, inte efter namn. En TCP-kontroll mot en känd serviceport säger mer än en ping, eftersom många värdar svarar på ICMP medan serviceporten är filtrerad. Om adressen svarar och ett namn inte gör det har du en resolverfråga och inte en routingfråga, och nästa avsnitt är inte för dig.

Hit hör också två omfattningskontroller. Per-app VPN betyder att en adressrutt kan finnas medan appen du testar med ligger utanför den inkluderade mängden, så testa med en app som verkligen är innanför. Och ett IPv4-prefix säger ingenting om IPv6-vägen; om tjänsten är dual-stack lägger du till motsvarande IPv6-rutt eller räknar med att klienten föredrar en väg du inte avsåg.

Ett negativt resultat är värt att känna igen tidigt: om en full-tunnel-rutt redan täcker 0.0.0.0/0 saknas inte prefixet, och att lägga till det igen ändrar ingenting. Dubbel täckning reparerar inte en avvisning på serversidan eller ett saknat svar.

Slutför vägen på servern

Tre saker måste vara sanna bortom telefonen. Gatewayen behöver en rutt till destinationen och tillstånd att vidarebefordra telefonens källa dit. Målet måste acceptera den källan och returnera svar genom gatewayen, annars behöver designen en medveten översättning vid utgången. OpenVPN-handbokens route-alternativ täcker direktivet på klientsidan; vidarebefordran och returrouting är separata inställningar på separata maskiner.

Om destinationen ligger bakom en annan VPN-klient i stället för direkt bakom gatewayen behöver servern en iroute för den peerns subnät. Det direktivet ägs av servern och beskriver vilken klient som äger ett prefix; en telefon kan inte leverera det från sin egen profil, och ingen mängd klientredigering ersätter det.

Kontrollera returvägen uttryckligen. Ett svar som går ut via standardrutten i stället för tunneln ger det klassiska halvöppna symptomet: anslutningen upprättas i en riktning och ingenting kommer tillbaka. Källöversättning i gatewayen är en legitim åtgärd när målet inte kan routa tillbaka, men det är ett policybeslut med egna konsekvenser.

Återställning och acceptans

Spara den föregående profilen innan du redigerar den. Om ändringen gör saken värre, återställ den kopian via samma återimportväg, anslut igen och bekräfta att det gamla beteendet kommer tillbaka — det bekräftar att du ändrade det du trodde du ändrade. En återställning som inte återställer det gamla tillståndet betyder att appen håller en tredje kopia som du inte har hittat.

Acceptera ändringen när fyra saker gäller, testade i den här ordningen efter en ny anslutning: destinationen svarar på sin serviceport, det privata namnet löses upp om det förväntas, HTTPS validerar fortfarande det avsedda värdnamnet, och allt fungerar fortfarande efter en omstart eller ett byte från Wi-Fi till mobilnät. Den sista kontrollen är den som fångar en rutt som bara finns tills Android återupprättar tunneln.

• Bekräfta att nätverkets ägare tillåter destinationen innan du redigerar något.
• Sätt rutten i profilen som klienten läser in, importera sedan igen och anslut igen.
• Verifiera via serviceport, inom per-app-omfånget, för rätt adressfamilj.
• Rätta vidarebefordran, returrouting och iroute på servern, inte på telefonen.
• Spara en återställningskopia och testa igen efter en omstart.