Android OpenVPN: bæta við einkaleið án þess að róta símanum

Þú þarft eitt einkasnet í viðbót — segjum 10.60.0.0/24 — sem prófíllinn inniheldur ekki núna. Á fartölvu myndir þú bæta við leið og halda áfram. Á Android er VPN app, tun-tækið tilheyrir því appi og það er engin leiðatöfla sem þú getur breytt án root. Leiðin verður samt að vera til, en hún fer í prófílinn sem biðlarinn hleður, og hún virkar aðeins ef hin hliðin samþykkir. Hér eru breytingin, endurtengingin, þjónninn og afturköllunin.

Fyrir breytinguna: hvað leið getur og getur ekki gert

Leið svarar einni spurningu: hvaða tengi á að bera umferðina til þessa áfangastaðar. Hún heimildar ekkert. Ef eigandi netsins hefur ekki samþykkt að þessi sími megi ná því undirneti, þá framleiðir rétt leið stillingu sem lítur rétt út og hljóðláta hendingu við gáttina, og þú eyðir næstu klukkustund í að breyta rangri skrá.

Fáðu þá samþykkt fyrst, skriflega ef netið á sér eiganda. Skráðu svo hvað þú ert ekki að gera: þú ert ekki að úthluta símanum vistfangi innan þess LAN, ekki að breyta hlustanda þjónsins og ekki að velja stað eftir hýsilheiti. Þetta eru fjórar ólíkar breytingar og aðeins fyrsta er þín.

Breyttu prófílnum sem biðlarinn hleður í raun

Fyrir samhæfan biðlara sem flytur inn venjulegan OpenVPN valkosti texta, er viðbótin ein lína:

route 10.60.0.0 255.255.255.0

Bættu henni við líkama prófílsins, nálægt öðrum leiðabeiningum, og haltu endpoint, skírteinum, lyklastjórnun og sannprófunarlínum rekstraraðilans nákvæmlega eins og þær voru. Límdu ekki heilt gamalt dæmi til að fá eina línu að láni: þjöppun, algildar skráarslóðir og úreltar cipher-stillingar ferðast með því og kosta þig sérstaka villuleitarsetu.

Skrefið sem fólk missir af er eignarhald skrárinnar. Ef appið flutti inn prófíl, þá er afritið sem það notar appsins, og að breyta upphaflegu skránni sem sótt var breytir engu. Notaðu studdan ritil biðlarans, eða flytja inn breyttu skrána aftur í gegnum uppfærsluleiðina, og staðfestu heiti virka prófílsins þegar nokkur lík heiti eru til. Skráðu hverjum þú breyttir.

Ef prófíllinn ber þegar route-nopull er engin leið frá þjóninum sett upp og hvert forskeyti sem síminn þarf verður að telja upp skýrt. Það er lögmæt hönnun, en það þýðir að sleppt lína lítur nákvæmlega út eins og höfnun frá þjóninum.

Tengdu aftur og sannprófaðu í tækinu

Aftengdu fyrst, tengdu svo aftur þann tiltekna prófíl sem þú breyttir í stað þess að láta appið endurheimta síðustu lotu. Opnaðu tengiskrána og staðfestu að biðlarinn hafi þáttað nýju línuna; leiðabeining sem viðmótið hunsar er algeng afleiðing þess að breyta rangu afriti.

Prófaðu áfangastaðinn eftir vistfangi, ekki eftir heiti. TCP-athugun á þekkta þjónustuhöfn gefur meiri upplýsingar en ping, því margir hýslar svara ICMP á meðan þjónustuhöfnin er síuð. Ef vistfangið svarar og heiti ekki, þá ertu með resolver-spurningu en ekki leiðaspurningu, og næsti kafli er ekki fyrir þig.

Tvær umfangsskoðanir eiga líka heima hér. VPN fyrir hvert app þýðir að vistfangsleið getur verið til á meðan appið sem þú prófar með er utan innifalins mengis, svo prófaðu með appi sem er í raun inni. Og IPv4 forskeyti segir ekkert um IPv6 slóðina; ef þjónustan er dual-stack skaltu bæta við samsvarandi IPv6 leið eða búast við að biðlarinn velji slóð sem þú ætlaðir ekki.

Eina neikvæða niðurstöðu er vert að þekkja snemma: ef full-tunnel leið þekur þegar 0.0.0.0/0, þá vantar ekki forskeytið og að bæta því við aftur breytir engu. Tvöföld þekja lagar ekki höfnun á þjónshliðinni né vantað svar.

Kláraðu slóðina á þjóninum

Þrjú atriði verða að vera sönn fyrir utan símann. Gáttin þarf leið að áfangastaðnum og leyfi til að senda uppsprettu símans þangað. Markmiðið þarf að samþykkja þá uppsprettu og skila svörum í gegnum gáttina, annars þarf hönnunin viljandi þýðingu á útleið. route-valkostur OpenVPN handbókarinnar nær yfir beininguna á biðlarahlið; framsending og afturleiðir eru aðskildar stillingar á aðskildum vélum.

Ef áfangastaðurinn er bak við annan VPN-biðlara frekar en beint bak við gáttina, þarf þjónninn iroute fyrir undirnet þess jafnings. Sú beining er í eigu þjónsins og lýsir því hvaða biðlari á forskeyti; sími getur ekki afhent hana úr eigin prófíl og engin magn af breytingum á biðlarahlið kemur í hennar stað.

Athugaðu afturleiðina skýrt. Svar sem fer út um sjálfgefnu leiðina í stað tunnilsins framleiðir klassískt hálfopið einkenni: tengingin myndast í aðra áttina og ekkert kemur til baka. Uppsprettuþýðing á gáttinni er lögmæt lagfæring þegar markmiðið getur ekki leiðbeint til baka, en það er stefnuákvörðun með sínum eigin afleiðingum.

Afturköllun og samþykki

Geymdu fyrri prófílinn áður en þú breytir honum. Ef breytingin gerir illa verra, endurheimtu það afrit í gegnum sömu innflutningsleið, tengdu aftur og staðfestu að gamla hegðunin komi til baka — það staðfestir að þú breyttir því sem þú hélt að þú breyttir. Afturköllun sem endurheimtir ekki gamla ástandið þýðir að appið heldur þriðja afriti sem þú hefur ekki fundið.

Samþykktu breytinguna þegar fjögur atriði gilda, prófuð í þessari röð eftir nýja endurtengingu: áfangastaðurinn svarar á þjónustuhöfn sinni, einkaneitið leysist ef þess er vænst, HTTPS staðfestir enn fyrirhugað hýsilheiti og allt virkar enn eftir endurræsingu eða skipti frá Wi-Fi yfir á farsímanet. Síðasta athugunin er sú sem grípur leið sem er aðeins til þar til Android endurreisir tunnilinn.

• Staðfestu að eigandi netsins leyfi áfangastaðinn áður en þú breytir nokkru.
• Settu leiðina í prófílinn sem biðlarinn hleður, flyttu svo inn aftur og tengdu aftur.
• Sannprófaðu í gegnum þjónustuhöfn, innan umfangs fyrir hvert app, fyrir rétta vistfangsfjölskyldu.
• Lagaðu framsendingu, afturleið og iroute á þjóninum, ekki í símanum.
• Geymdu afturköllunarafrit og prófaðu aftur eftir endurræsingu.