Android OpenVPN: leggje til ei privat rute utan å roote telefonen

Du treng eitt privat subnett til — seie 10.60.0.0/24 — som profilen ikkje inneheld no. På ein laptop ville du lagt til ei rute og gått vidare. På Android er VPN-en ein app, tun-eininga høyrer til den appen, og det finst inga rutetabell du kan redigere utan root. Ruta må likevel finnast, men ho går inn i profilen klienten lastar inn, og ho verkar berre om den andre sida er samd. Her er endringa, attilkoplinga, tenarsida og tilbakerullinga.

Før endringa: kva ei rute kan og ikkje kan gjere

Ei rute svarar på eitt spørsmål: kva grensesnitt som skal bere trafikken til denne destinasjonen. Ho autoriserer ingenting. Om netverkssjefen ikkje har godteke at denne telefonen kan nå det subnettet, gir ei korrekt rute ein konfigurasjon som ser rett ut og eit stille dropp i gatewayen, og du brukar den neste timen på å redigere feil fil.

Skaff den semja først, skriftleg om netverket har ein eigar. Noter så kva du ikkje gjer: du tildeler ikkje telefonen ei adresse inne i det LAN-et, du endrar ikkje tenaren sin lyttar, og du vel ikkje ein nettstad etter vertsnamn. Det er fire ulike endringar, og berre den første er din.

Rediger profilen klienten faktisk lastar inn

For ein kompatibel klient som importerer vanleg OpenVPN-opsjonstekst, er tillegget éi linje:

route 10.60.0.0 255.255.255.0

Legg henne til i kroppen av profilen, nær dei andre rutingsdirektiva, og hald endepunktet, sertifikata, nøkkelhandteringa og verifiseringslinjene til operatøren nøyaktig som dei var. Ikkje lim inn eit heilt gammalt døme for å låne éi linje: komprimering, absolutte filstigar og utdaterte cipher-innstillingar følgjer med og kostar deg ei eiga feilsøkingsøkt.

Trinnet folk hoppar over, er eigarskapet til fila. Om appen importerte ein profil, er kopien han brukar appen sin, og å redigere den nedlasta originalen endrar ingenting. Bruk den støtta editoren til klienten, eller importer den redigerte fila på nytt via oppdateringsvegen, og stadfest namnet på den aktive profilen når det finst fleire like namn. Noter kva for ein du endra.

Om profilen alt har route-nopull, blir inga rute frå tenaren installert, og kvart prefiks telefonen treng må listast opp eksplisitt. Det er ei legitim utforming, men det tyder at ei utelaten linje ser nøyaktig ut som ei avvising frå tenaren.

Kople til på nytt og verifiser på eininga

Kople frå først, og kople så til på nytt med den spesifikke profilen du redigerte, i staden for å la appen gjenopprette den siste økta. Opne tilkoplingloggen og stadfest at klienten har tolka den nye linja; eit rutingsdirektiv som grensesnittet ignorerer, er eit vanleg resultat av å redigere feil kopi.

Test destinasjonen etter adresse, ikkje etter namn. Ein TCP-sjekk mot ein kjend tenesteport seier meir enn ein ping, fordi mange vertar svarar på ICMP medan tenesteporten er filtrert. Om adressa svarar og eit namn ikkje gjer det, har du eit resolver-spørsmål og ikkje eit rutingsspørsmål, og neste avsnitt er ikkje for deg.

To omfangssjekkar høyrer også heime her. Per-app VPN tyder at ei adresserute kan vere til stades medan appen du testar med, er utanfor det inkluderte settet, så test med ein app som faktisk er innanfor. Og eit IPv4-prefiks seier ingenting om IPv6-vegen; om tenesta er dual-stack, legg til den tilsvarande IPv6-ruta eller rekn med at klienten føretrekkjer ein veg du ikkje hadde tenkt.

Eitt negativt resultat er verdt å kjenne att tidleg: om ei full-tunnel-rute alt dekkjer 0.0.0.0/0, manglar ikkje prefikset, og å leggje det til på nytt endrar ingenting. Dobbelt dekning reparerer ikkje ei avvising på tenarsida eller eit manglande svar.

Fullfør vegen på tenaren

Tre ting må vere sanne utover telefonen. Gatewayen treng ei rute til destinasjonen og løyve til å senda kjelda til telefonen vidare mot henne. Målet må godta den kjelda og returnere svar gjennom gatewayen, elles treng utforminga ei medviten omsetjing på utgangen. OpenVPN-handboka sitt route-alternativ dekkjer direktivet på klientsida; videresending og returrutting er separate innstillingar på separate maskinar.

Om destinasjonen ligg bak ein annan VPN-klient i staden for rett bak gatewayen, treng tenaren ein iroute for subnettet til den peeren. Det direktivet er eigd av tenaren og skildrar kva klient som eig eit prefiks; ein telefon kan ikkje levere det frå sin eigen profil, og inga mengd klientredigering erstattar det.

Kontroller returvegen eksplisitt. Eit svar som går ut via standardruta i staden for tunnelen, gir det klassiske halvopne symptomet: sambandet blir oppretta i éi retning, og ingenting kjem tilbake. Kjeldeomsetjing på gatewayen er ei legitim løysing når målet ikkje kan rute tilbake, men det er ei politikkgreiing med eigne følgjer.

Tilbakerulling og aksept

Ta vare på den førre profilen før du redigerer han. Om endringa gjer ting verre, gjenopprett den kopien via same reinportveg, kople til på nytt, og stadfest at den gamle åtferda kjem tilbake — det stadfestar at du endra det du trudde du endra. Ei tilbakerulling som ikkje gjenopprettar den gamle tilstanden, tyder at appen held på ein tredje kopi du ikkje har funne.

Godta endringa når fire ting held, testa i denne rekkjefølgja etter ei fersk attilkopling: destinasjonen svarar på tenesteporten sin, det private namnet blir løyst opp om det er venta, HTTPS validerer framleis det tiltenkte vertsnamnet, og alt verkar framleis etter ein omstart eller eit byte frå Wi-Fi til mobilnett. Den siste kontrollen er den som fangar ei rute som berre finst til Android gjenopprettar tunnelen.

• Stadfest at netverkssjefen tillèt destinasjonen før du redigerer noko.
• Set ruta i profilen klienten lastar inn, og importer så på nytt og kople til på nytt.
• Verifiser via tenesteport, innanfor per-app-omfanget, for rett adressefamilie.
• Rett videresending, returrutting og iroute på tenaren, ikkje på telefonen.
• Ta vare på ein tilbakerullingskopi, og test på nytt etter ein omstart.