Android OpenVPN: přidejte privátní trasu bez rootu telefonu

Přidejte jednu trasu do profilu, který Android skutečně načítá, a pak ověřte, že ji server povoluje. Postup pro úpravu, opětovné připojení a čtyři kontroly.

Potřebujete ještě jednu privátní podsíť, dejme tomu 10.60.0.0/24, kterou profil zatím neobsahuje. Na notebooku přidáte trasu a jdete dál. Na Androidu je VPN aplikace, zařízení tun patří té aplikaci a neexistuje směrovací tabulka, kterou byste upravili bez rootu. Trasa musí existovat dál, ale jde do profilu, který klient načítá, a funguje jen tehdy, když druhá strana souhlasí. Následuje úprava, opětovné připojení, strana serveru a vrácení.

Před úpravou: co trasa umí a co ne

Trasa odpovídá na jednu otázku: které rozhraní má nést provoz k tomuto cíli. Nic nepovoluje. Pokud vlastník sítě nesouhlasil s tím, že tento telefon dosáhne na tuto podsíť, správná trasa vytvoří konfiguraci, která vypadá správně, a tiché zahození na bráně, a další hodinu budete upravovat špatný soubor.

Nejprve si ten souhlas zajistěte, písemně, pokud síť má vlastníka. Pak si poznamenejte, co neděláte: nepřidělujete telefonu adresu v té LAN, neměníte naslouchající socket serveru a nevybíráte lokalitu podle jména hostitele. To jsou čtyři různé změny a jen první je vaše.

The route gives youThe route does not give you
A destination prefix associated with the tunnelPermission to forward at the gateway
A path for the phone's own trafficA return route on the target host
A scope for the client's virtual interfaceA name in DNS, or HTTPS identity

Upravte profil, který klient skutečně načítá

U kompatibilního klienta, který importuje běžný text voleb OpenVPN, je přírůstek jeden řádek:

route 10.60.0.0 255.255.255.0

Přidejte ho do těla profilu poblíž ostatních směrovacích direktiv a koncový bod operátora, certifikáty, práci s klíči a ověřovací řádky ponechte přesně tak, jak byly. Nevkládejte celý starý příklad, jen abyste si půjčili jeden řádek: komprese, absolutní cesty k souborům a zastaralá nastavení šifer cestují s ním a stojí vás samostatné ladění.

Krok, který lidé vynechávají, je vlastnictví souboru. Pokud aplikace profil importovala, kopie, kterou používá, patří aplikaci, a úprava staženého originálu nic nezmění. Použijte editor podporovaný klientem, nebo upravený soubor znovu importujte cestou aktualizace, a při více podobných jménech potvrďte jméno aktivního profilu. Poznamenejte si, který jste změnili.

Pokud profil už obsahuje route-nopull, neinstaluje se žádná trasa ze serveru a každý prefix, který telefon potřebuje, musí být uveden výslovně. Je to legitimní návrh, ale znamená to, že vynechaný řádek vypadá stejně jako odmítnutí serverem.

Připojte se znovu a ověřte na zařízení

Nejprve se odpojte, pak se znovu připojte ke konkrétnímu profilu, který jste upravili, místo abyste nechali aplikaci obnovit poslední relaci. Otevřete log připojení a potvrďte, že klient nový řádek přečetl; směrovací direktiva, kterou frontend ignoruje, je častý výsledek úpravy špatné kopie.

Testujte cíl podle adresy, ne podle jména. Kontrola TCP na známý port služby řekne víc než ping, protože mnoho hostitelů odpovídá na ICMP, zatímco port služby je filtrovaný. Pokud adresa odpovídá a jméno ne, máte otázku překladače, ne směrování.

Patří sem i dvě kontroly rozsahu. Per-app VPN znamená, že adresová trasa může existovat, zatímco aplikace, se kterou testujete, je mimo zahrnutou množinu, takže testujte aplikací, která je skutečně uvnitř. A prefix IPv4 neříká nic o cestě IPv6; je-li služba dual-stack, přidejte odpovídající trasu IPv6, nebo očekávejte, že klient zvolí cestu, kterou jste nechtěli.

Jeden negativní výsledek je dobré rozpoznat brzy: pokud trasa plného tunelu už pokrývá 0.0.0.0/0, prefix nechybí a opětovné přidání nic nezmění. Dvojité pokrytí neopraví odmítnutí na straně serveru ani chybějící odpověď.

Dokončete cestu na serveru

Tři věci musí platit mimo telefon. Brána potřebuje trasu k cíli a povolení předávat zdroj telefonu tím směrem. Cíl musí tento zdroj přijmout a vracet odpovědi přes bránu, jinak návrh potřebuje záměrný překlad na výstupu. Volba trasy v manuálu OpenVPN pokrývá direktivu na straně klienta; předávání a zpětná směrování jsou samostatná nastavení na samostatných strojích.

Pokud cíl stojí za jiným klientem VPN a ne přímo za bránou, server potřebuje iroute pro podsíť toho peeru. Ta direktiva patří serveru a popisuje, který klient vlastní prefix; telefon ji ze svého profilu dodat nemůže a žádná úprava na straně klienta ji nenahradí.

Zkontrolujte zpětnou cestu výslovně. Odpověď, která odchází výchozí trasou místo tunelem, dává klasický příznak polouzavřeného spojení: spojení je navázáno jedním směrem a nic se nevrací. Překlad zdroje na bráně je legitimní řešení, když cíl neumí směrovat zpět, ale je to politické rozhodnutí s vlastními důsledky.

Vrácení a přijetí

Před úpravou si ponechte předchozí profil. Pokud změna situaci zhorší, obnovte tu kopii stejnou cestou reimportu, připojte se a potvrďte, že se staré chování vrátilo; to potvrzuje, že jste změnili to, co jste mysleli. Vrácení, které neobnoví starý stav, znamená, že aplikace drží třetí kopii, kterou jste nenašli.

Změnu přijměte, když platí čtyři věci, testované v tomto pořadí po čerstvém připojení: cíl odpovídá na portu služby, privátní jméno se přeloží, pokud se očekává, HTTPS stále ověřuje zamýšlené jméno hostitele a vše funguje i po restartu nebo přechodu z Wi-Fi na mobilní síť. Poslední kontrola zachytí trasu, která existuje jen do chvíle, než Android tunel znovu vytvoří.

  • Potvrďte, že vlastník sítě cíl povoluje, než cokoli upravíte.
  • Vložte trasu do profilu, který klient načítá, pak znovu importujte a připojte se.
  • Ověřujte podle portu služby, uvnitř rozsahu per-app, pro správnou rodinu adres.
  • Opravte předávání, zpětné směrování a iroute na serveru, ne v telefonu.
  • Ponechte kopii pro vrácení a po restartu vše znovu otestujte.

Související články