Android OpenVPN: legge til en privat rute uten å roote telefonen

Du trenger ett privat subnett til — si 10.60.0.0/24 — som profilen ikke inneholder nå. På en laptop ville du lagt til en rute og gått videre. På Android er VPN-en en app, tun-enheten tilhører den appen, og det finnes ingen rutetabell du kan redigere uten root. Ruten må likevel finnes, men den går inn i profilen klienten laster inn, og den virker bare hvis den andre siden er enig. Her er endringen, gjentilkoblingen, serversiden og tilbakerullingen.

Før endringen: hva en rute kan og ikke kan gjøre

En rute svarer på ett spørsmål: hvilket grensesnitt som skal bære trafikken til denne destinasjonen. Den autoriserer ingenting. Hvis nettverkseieren ikke har godtatt at denne telefonen kan nå det subnettet, gir en korrekt rute en konfigurasjon som ser riktig ut og et stille dropp i gatewayen, og du bruker den neste timen på å redigere feil fil.

Skaff den enigheten først, skriftlig hvis nettverket har en eier. Noter deretter hva du ikke gjør: du tildeler ikke telefonen en adresse inne i det LAN-et, du endrer ikke serverens listener, og du velger ikke et nettsted etter vertsnavn. Det er fire forskjellige endringer, og bare den første er din.

Rediger profilen klienten faktisk laster inn

For en kompatibel klient som importerer vanlig OpenVPN-opsjonstekst, er tillegget én linje:

route 10.60.0.0 255.255.255.0

Legg den til i profilens kropp, nær de andre rutingsdirektivene, og hold operatørens endpoint, sertifikater, nøkkelhåndtering og verifiseringslinjer nøyaktig som de var. Ikke lim inn et helt gammelt eksempel for å låne én linje: komprimering, absolutte filstier og utdaterte cipher-innstillinger følger med og koster deg en egen feilsøkingsøkt.

Trinnet folk går glipp av, er eierskapet til filen. Hvis appen importerte en profil, er kopien den bruker appens, og å redigere den nedlastede originalen endrer ingenting. Bruk klientens støttede editor, eller importer den redigerte filen på nytt via oppdateringsveien, og bekreft navnet på den aktive profilen når det finnes flere like navn. Noter hvilken du endret.

Hvis profilen allerede har route-nopull, installeres ingen rute fra serveren, og hvert prefiks telefonen trenger må listes opp eksplisitt. Det er en legitim utforming, men det betyr at en utelatt linje ser nøyaktig ut som en avvisning fra serveren.

Koble til på nytt og verifiser på enheten

Koble fra først, og koble deretter til på nytt med den spesifikke profilen du redigerte i stedet for å la appen gjenopprette den siste økten. Åpne tilkoblingsloggen og bekreft at klienten har tolket den nye linjen; et rutingsdirektiv som grensesnittet ignorerer, er et vanlig resultat av å redigere feil kopi.

Test destinasjonen etter adresse, ikke etter navn. En TCP-sjekk mot en kjent tjenesteport sier mer enn en ping, fordi mange verter svarer på ICMP mens tjenesteporten er filtrert. Hvis adressen svarer og et navn ikke gjør det, har du et resolver-spørsmål og ikke et rutingspørsmål, og neste avsnitt er ikke for deg.

To omfangssjekker hører også hjemme her. Per-app VPN betyr at en adresserute kan være til stede mens appen du tester med, er utenfor det inkluderte settet, så test med en app som faktisk er innenfor. Og et IPv4-prefiks sier ingenting om IPv6-veien; hvis tjenesten er dual-stack, legg til den tilsvarende IPv6-ruten eller forvent at klienten foretrekker en vei du ikke hadde tenkt.

Ett negativt resultat er verdt å kjenne igjen tidlig: hvis en full-tunnel-rute allerede dekker 0.0.0.0/0, mangler ikke prefikset, og å legge det til på nytt endrer ingenting. Dobbel dekning reparerer ikke en avvisning på serversiden eller et manglende svar.

Fullfør veien på serveren

Tre ting må være sanne utover telefonen. Gatewayen trenger en rute til destinasjonen og tillatelse til å videresende telefonens kilde mot den. Målet må godta den kilden og returnere svar gjennom gatewayen, ellers trenger utformingen en bevisst oversettelse på utgangen. OpenVPN-håndbokens route-alternativ dekker direktivet på klientsiden; videresending og returruting er separate innstillinger på separate maskiner.

Hvis destinasjonen ligger bak en annen VPN-klient i stedet for rett bak gatewayen, trenger serveren en iroute for den peerens subnett. Det direktivet eies av serveren og beskriver hvilken klient som eier et prefiks; en telefon kan ikke levere det fra sin egen profil, og ingen mengde klientredigering erstatter det.

Kontroller returveien eksplisitt. Et svar som går ut via standardruten i stedet for tunnelen, gir det klassiske halvåpne symptomet: forbindelsen etableres i én retning, og ingenting kommer tilbake. Kildeoversettelse på gatewayen er en legitim løsning når målet ikke kan rute tilbake, men det er en policybeslutning med egne konsekvenser.

Tilbakerulling og aksept

Ta vare på den forrige profilen før du redigerer den. Hvis endringen gjør ting verre, gjenopprett den kopien via samme reimportvei, koble til på nytt, og bekreft at den gamle oppførselen kommer tilbake — det bekrefter at du endret det du trodde du endret. En tilbakerulling som ikke gjenoppretter den gamle tilstanden, betyr at appen holder en tredje kopi du ikke har funnet.

Godta endringen når fire ting holder, testet i denne rekkefølgen etter en fersk gjentilkobling: destinasjonen svarer på tjenesteporten sin, det private navnet løses opp hvis det forventes, HTTPS validerer fortsatt det tiltenkte vertsnavnet, og alt virker fortsatt etter en omstart eller et bytte fra Wi-Fi til mobilnett. Den siste kontrollen er den som fanger en rute som bare finnes til Android gjenoppretter tunnelen.

• Bekreft at nettverkseieren tillater destinasjonen før du redigerer noe.
• Sett ruten i profilen klienten laster inn, og importer deretter på nytt og koble til på nytt.
• Verifiser via tjenesteport, innenfor per-app-omfanget, for riktig adressefamilie.
• Rett videresending, returruting og iroute på serveren, ikke på telefonen.
• Ta vare på en tilbakerullingskopi, og test på nytt etter en omstart.