Android OpenVPN: aldoni privatan itineron sen rooti la telefonon

Vi bezonas ankoraŭ unu privatan subreton — ni diru 10.60.0.0/24 — kiun la profilo nun ne enhavas. Sur tekkomputilo vi aldonus itineron kaj daŭrigus. En Android la VPN estas aplikaĵo, la tun-aparato apartenas al tiu aplikaĵo, kaj ne ekzistas enkursiga tabelo por redakti sen root. La itinero devas tamen ekzisti, sed ĝi iras en la profilon, kiun la kliento ŝargas, kaj ĝi funkcias nur se la alia flanko konsentas. Jen la redakto, la rekonekto, la servila flanko kaj la restarigo.

Antaŭ la redakto: kion itinero povas kaj ne povas fari

Itinero respondas unu demandon: kiu interfaco portu trafikon al ĉi tiu celo. Ĝi rajtigas nenion. Se la posedanto de la reto ne konsentis, ke ĉi tiu telefono rajtas atingi tiun subreton, ĝusta itinero produktas agordon, kiu aspektas ĝusta, kaj silenta forĵeto ĉe la pordego, kaj vi pasigos la sekvan horon redaktante la malĝustan dosieron.

Akiru tiun konsenton unue, skribe se la reto havas posedanton. Poste notu, kion vi ne faras: vi ne asignas al la telefono adreson ene de tiu LAN, vi ne ŝanĝas la aŭdanton de la servilo, kaj vi ne elektas retejon laŭ gastigantnomo. Tiuj estas kvar malsamaj ŝanĝoj, kaj nur la unua estas via.

Redaktu la profilon, kiun la kliento efektive ŝargas

Por kongrua kliento, kiu importas ordinaran OpenVPN-opcian tekston, la aldono estas unu linio:

route 10.60.0.0 255.255.255.0

Aldonu ĝin al la korpo de la profilo, apud la aliaj enkursigaj direktivoj, konservante la finpunkton, atestilojn, ŝlosilmanipuladon kaj kontrolajn liniojn de la funkciigisto precize kiel ili estis. Ne algluu tutan malnovan ekzemplon por prunti unu linion: kunpremado, absolutaj dosiervojoj kaj eksdataj ĉifraj agordoj vojaĝas kun ĝi kaj kostos al vi apartan sencimigan seancon.

La paŝo, kiun homoj maltrafas, estas la posedo de la dosiero. Se la aplikaĵo importis profilon, la kopio, kiun ĝi uzas, estas de la aplikaĵo, kaj redakti la elŝutitan originan dosieron ŝanĝas nenion. Uzu la subtenatan redaktilon de la kliento, aŭ reimportu la redaktitan dosieron per la ĝisdatiga vojo, kaj konfirmu la nomon de la aktiva profilo, kiam ekzistas pluraj similaj nomoj. Notu, kiun vi ŝanĝis.

Se la profilo jam portas route-nopull, neniu itinero de la servilo estas instalita kaj ĉiu prefikso, kiun la telefono bezonas, devas esti eksplicite listigita. Tio estas legitima dizajno, sed ĝi signifas, ke ellastia linio aspektas precize kiel rifuzo de la servilo.

Rekonektu kaj kontrolu sur la aparato

Malkonektu unue, poste rekonektu la specifan profilon, kiun vi redaktis, anstataŭ lasi la aplikaĵon restarigi la lastan seancon. Malfermu la konektan protokolon kaj konfirmu, ke la kliento analizis la novan linion; enkursiga direktivo, kiun la fasado ignoras, estas ofta rezulto de redakto de la malĝusta kopio.

Testu la celon per adreso, ne per nomo. TCP-kontrolo al unu konata serva pordo estas pli informa ol ping, ĉar multaj gastigantoj respondas al ICMP dum la serva pordo estas filtrita. Se la adreso respondas kaj nomo ne, vi havas demandon pri solvilo kaj ne pri enkursigado, kaj la sekva sekcio ne estas por vi.

Du ampleksaj kontroloj ankaŭ apartenas ĉi tie. Per-aplikaĵa VPN signifas, ke adresa itinero povas ekzisti dum la aplikaĵo, per kiu vi testas, estas ekster la inkluzivita aro, do testu per aplikaĵo, kiu efektive estas interne. Kaj IPv4-prefikso diras nenion pri la IPv6-vojo; se la servo estas dual-stack, aldonu la respondan IPv6-itinero aŭ atendu, ke la kliento preferos vojon, kiun vi ne intencis.

Unu negativa rezulto indas esti rekonata frue: se plentunela itinero jam kovras 0.0.0.0/0, la prefikso ne mankas kaj aldoni ĝin denove ŝanĝas nenion. Duobla kovrado ne riparas rifuzon flanke de la servilo nek mankan respondon.

Finu la vojon sur la servilo

Tri aferoj devas esti veraj preter la telefono. La pordego bezonas itineron al la celo kaj permeson plusendi la fonton de la telefono al ĝi. La celo devas akcepti tiun fonton kaj resendi respondojn tra la pordego, aŭ la dizajno bezonas intencan tradukon ĉe la eliro. La route-opcio de la OpenVPN-manlibro kovras la klientflankan direktivon; plusendado kaj revena enkursigado estas apartaj agordoj sur apartaj maŝinoj.

Se la celo situas malantaŭ alia VPN-kliento anstataŭ rekte malantaŭ la pordego, la servilo bezonas iroute por la subreto de tiu samtavolano. Tiu direktivo apartenas al la servilo kaj priskribas, kiu kliento posedas prefikson; telefono ne povas liveri ĝin el sia propra profilo, kaj neniu kvanto da klientflanka redakto anstataŭas ĝin.

Kontrolu la revenan vojon eksplicite. Respondo, kiu eliras per la defaŭlta itinero anstataŭ per la tunelo, produktas la klasikan duonmalferman simptomon: la konekto estas starigita en unu direkto kaj nenio revenas. Fonto-traduko ĉe la pordego estas legitima riparego, kiam la celo ne povas reen enkursigi, sed ĝi estas politika decido kun propraj sekvoj.

Restarigo kaj akcepto

Konservu la antaŭan profilon antaŭ ol redakti ĝin. Se la ŝanĝo plimalbonigas la situacion, restarigu tiun kopion per la sama reimporta vojo, rekonektu, kaj konfirmu, ke la malnova konduto revenas — tio konfirmas, ke vi ŝanĝis tion, kion vi pensis ŝanĝi. Restarigo, kiu ne restaŭras la malnovan staton, signifas, ke la aplikaĵo tenas trian kopion, kiun vi ne trovis.

Akceptu la ŝanĝon kiam kvar aferoj validas, testitaj en ĉi tiu ordo post freŝa rekonekto: la celo respondas sur sia serva pordo, la privata nomo solviĝas se oni atendas ĝin, HTTPS ankoraŭ validigas la celitan gastigantnomon, kaj la tuto ankoraŭ funkcias post restarto aŭ transiro de Wi-Fi al ĉela. La lasta kontrolo estas tiu, kiu kaptas itineron, kiu ekzistas nur ĝis Android reestablos la tunelon.

• Konfirmu, ke la posedanto de la reto permesas la celon, antaŭ ol ŝanĝi ion ajn.
• Metu la itineron en la profilon, kiun la kliento ŝargas, poste reimportu kaj rekonektu.
• Kontrolu per serva pordo, ene de la per-aplikaĵa amplekso, por la ĝusta adresfamilio.
• Riparu plusendadon, revenan enkursigadon kaj iroute sur la servilo, ne sur la telefono.
• Konservu restarigan kopion, kaj retestu post restarto.