Android OpenVPN: voeg @APOS@n privaat roete by sonder om die selfoon te root

Jy het nog een privaat subnet nodig, sê 10.60.0.0/24, wat die profiel tans nie insluit nie. Op ’n skootrekenaar voeg jy ’n roete by en gaan aan. Op Android is die VPN ’n app, die tun-toestel behoort aan daardie app, en daar is geen roetertabel wat jy sonder root kan wysig nie. Die roete moet steeds bestaan, maar dit gaan in die profiel wat die kliënt laai, en dit werk net as die ander kant saamstem. Hier is die wysiging, die herverbinding, die bedienerkant en die terugrol.

Voor die wysiging: wat ’n roete wel en nie kan doen nie

’n Roete beantwoord een vraag: watter koppelvlak die verkeer vir hierdie bestemming moet dra. Dit magtig niks. As die netwerkeienaar nie ingestem het dat hierdie selfoon daardie subnet mag bereik nie, lewer ’n korrekte roete ’n konfigurasie wat reg lyk en ’n stil verwerping by die poort, en jy sal die volgende uur die verkeerde lêer wysig.

Kry eers daardie instemming, skriftelik as die netwerk ’n eienaar het. Let dan op wat jy nie doen nie: jy ken nie die selfoon ’n adres binne daardie LAN toe nie, verander nie die bediener se luisteraar nie, en kies nie ’n werf op hostnaam nie. Dit is vier verskillende veranderinge en net die eerste is joune.

Wysig die profiel wat die kliënt werklik laai

Vir ’n versoenbare kliënt wat gewone OpenVPN-opsieteks invoer, is die byvoeging een reël:

route 10.60.0.0 255.255.255.0

Voeg dit by die profielliggaam, naby die ander roeteringsopdragte, en hou die operateur se eindpunt, sertifikate, sleutelhantering en verifikasielyne presies soos dit was. Moenie ’n hele ou voorbeeld invoeg om een reël te leen nie: kompressie, absolute lêerpaaie en verouderde syferinstellings reis saam en kos jou ’n aparte ontfoutingsessie.

Die stap wat mense mis, is die eienaarskap van die lêer. As die app ’n profiel ingevoer het, is die kopie wat dit gebruik die app s’n, en om die afgelaaide oorspronklike te wysig verander niks. Gebruik die kliënt se ondersteunde redigeerder, of voer die gewysigde lêer weer in deur die opdateringspad, en bevestig die aktiewe profiel se naam wanneer daar verskeie soortgelyke name is. Teken aan watter een jy verander het.

As die profiel reeds route-nopull bevat, word geen roete van die bediener geïnstalleer nie en moet elke voorvoegsel wat die selfoon nodig het, eksplisiet gelys word. Dit is ’n geldige ontwerp, maar dit beteken ’n weggelate reël lyk presies soos ’n weiering van die bediener.

Herverbind en verifieer op die toestel

Ontkoppel eers en herverbind dan die spesifieke profiel wat jy gewysig het, eerder as om die app die laaste sessie te laat herstel. Maak die verbindingslog oop en bevestig dat die kliënt die nuwe reël geparseer het; ’n roete-opdrag wat die voorkant ignoreer, is ’n algemene gevolg van die verkeerde kopie wysig.

Toets die bestemming per adres, nie per naam nie. ’n TCP-kontrole na een bekende dienspoort is meer informatief as ’n ping, want baie gashere antwoord ICMP terwyl die dienspoort gefiltreer word. As die adres antwoord en ’n naam nie, het jy ’n oplosser-vraag en nie ’n roetevraag nie, en die volgende afdeling is nie vir jou nie.

Twee omvangkontroles hoort hier. Per-app VPN beteken ’n adresroete kan teenwoordig wees terwyl die app waarmee jy toets buite die ingeslote stel is, so toets met ’n app wat werklik binne is. En ’n IPv4-voorvoegsel sê niks oor die IPv6-pad nie; as die diens dubbelstapel is, voeg die ooreenstemmende IPv6-roete by of verwag dat die kliënt ’n pad verkies wat jy nie bedoel het nie.

Een negatiewe resultaat is vroeg die moeite werd om te herken: as ’n volledige tonnelroete reeds 0.0.0.0/0 dek, ontbreek die voorvoegsel nie en verander dit niks om dit weer by te voeg nie. Dubbele dekking herstel nie ’n weiering aan die bedienerkant of ’n ontbrekende antwoord nie.

Voltooi die pad op die bediener

Drie dinge moet waar wees buite die selfoon. Die poort het ’n roete na die bestemming nodig en toestemming om die selfoon se bron daarheen te stuur. Die teiken moet daardie bron aanvaar en antwoorde deur die poort terugstuur, of die ontwerp het doelbewuste vertaling aan die uitgang nodig. Die OpenVPN-handleiding se roete-opsie dek die kliëntkant-opdrag; stuur en terugroetering is aparte instellings op aparte masjiene.

As die bestemming agter ’n ander VPN-kliënt sit eerder as direk agter die poort, het die bediener ’n iroute vir daardie eweknie se subnet nodig. Daardie opdrag is die bediener s’n en beskryf watter kliënt ’n voorvoegsel besit; ’n selfoon kan dit nie uit sy eie profiel lewer nie, en geen kliëntkant-wysiging vervang dit nie.

Kontroleer die terugpad eksplisiet. ’n Antwoord wat per standaardroete vertrek in plaas van deur die tonnel, lewer die klassieke halfoop-simptoom: die verbinding is in een rigting gevestig en niks kom terug nie. Brontranslasie by die poort is ’n geldige oplossing wanneer die teiken nie kan terugroeteer nie, maar dit is ’n beleidsbesluit met eie gevolge.

Terugrol en aanvaarding

Hou die vorige profiel voor jy dit wysig. As die verandering dinge vererger, herstel daardie kopie deur dieselfde herinvoerpad, herverbind, en bevestig dat die ou gedrag terugkeer; dit bevestig dat jy verander het wat jy gedink het. ’n Terugrol wat nie die ou toestand herstel nie, beteken die app hou ’n derde kopie wat jy nog nie gevind het nie.

Aanvaar die verandering wanneer vier dinge geld, in hierdie volgorde getoets ná ’n vars herverbinding: die bestemming antwoord op sy dienspoort, die private naam los op as een verwag word, HTTPS valideer steeds die bedoelde hostnaam, en die geheel werk steeds ná ’n herbegin of ’n oorskakeling van Wi-Fi na sellulêr. Die laaste kontrole vang ’n roete wat net bestaan totdat Android die tonnel weer vestig.

• Bevestig dat die netwerkeienaar die bestemming toelaat voordat jy iets wysig.
• Plaas die roete in die profiel wat die kliënt laai, voer dit weer in en herverbind.
• Verifieer per dienspoort, binne die per-app-omvang, vir die regte adresfamilie.
• Herstel stuur, terugroetering en iroute op die bediener, nie op die selfoon nie.
• Hou ’n terugrolkopie en toets weer ná ’n herbegin.