Android OpenVPN: privát útvonal hozzáadása a telefon rootolása nélkül

Még egy privát alhálózatra van szüksége — mondjuk 10.60.0.0/24 —, amely jelenleg nincs a profilban. Hordozható gépen hozzáadna egy útvonalat, és továbblépne. Androidon a VPN egy alkalmazás, a tun eszköz ahhoz az alkalmazáshoz tartozik, és root nélkül nincs szerkeszthető útvonaltábla. Az útvonalnak mégis léteznie kell, de abba a profilba kerül, amelyet a kliens betölt, és csak akkor működik, ha a másik fél egyetért. Íme a módosítás, az újracsatlakozás, a kiszolgáló oldala és a visszaállítás.

A módosítás előtt: mit tud és mit nem tud egy útvonal

Az útvonal egyetlen kérdésre válaszol: melyik interfész vigye a forgalmat ehhez a célhoz. Semmit nem engedélyez. Ha a hálózat tulajdonosa nem járult hozzá, hogy ez a telefon elérje azt az alhálózatot, a helyes útvonal helyesnek látszó konfigurációt és csendes eldobást eredményez az átjárónál, és a következő órát a rossz fájl szerkesztésével tölti.

Először szerezze meg ezt a beleegyezést, írásban, ha a hálózatnak van tulajdonosa. Utána jegyezze fel, mit nem tesz: nem ad a telefonnak címet azon a LAN-on belül, nem változtatja a kiszolgáló listenerét, és nem választ helyet gazdagépnév alapján. Ez négy különböző változtatás, és csak az első az öné.

Azt a profilt szerkessze, amelyet a kliens valóban betölt

Egy kompatibilis kliensnél, amely közönséges OpenVPN opciószöveget importál, a kiegészítés egy sor:

route 10.60.0.0 255.255.255.0

Adja hozzá a profil törzséhez, a többi útvonalkezelési direktíva közelében, és hagyja az üzemeltető endpointját, tanúsítványait, kulcskezelését és ellenőrzősorait pontosan úgy, ahogy voltak. Ne illesszen be egy egész régi példát egyetlen sor kölcsönzéséhez: a tömörítés, az abszolút fájlútvonalak és az elavult cipher-beállítások vele utaznak, és külön hibakeresési munkamenetbe kerülnek.

A lépés, amelyet az emberek kihagynak, a fájl tulajdonjoga. Ha az alkalmazás importált egy profilt, az általa használt példány az alkalmazásé, és a letöltött eredeti szerkesztése semmit nem változtat. Használja a kliens támogatott szerkesztőjét, vagy importálja újra a szerkesztett fájlt a frissítési úton, és erősítse meg az aktív profil nevét, ha több hasonló név van. Jegyezze fel, melyiket módosította.

Ha a profil már tartalmaz route-nopull beállítást, a kiszolgálótól egyetlen útvonal sem települ, és minden előtagot, amelyre a telefonnak szüksége van, kifejezetten fel kell sorolni. Ez legitim tervezés, de azt jelenti, hogy egy kihagyott sor pontosan úgy néz ki, mint a kiszolgáló elutasítása.

Csatlakozzon újra, és ellenőrizze az eszközön

Először bontsa a kapcsolatot, majd pontosan azt a profilt csatlakoztassa újra, amelyet szerkesztett, ahelyett hogy az alkalmazás visszaállítaná az utolsó munkamenetet. Nyissa meg a kapcsolatnaplót, és erősítse meg, hogy a kliens feldolgozta az új sort; az az útvonal-direktíva, amelyet a felület figyelmen kívül hagy, a rossz példány szerkesztésének gyakori következménye.

A célt cím alapján tesztelje, ne név alapján. Egy ismert szolgáltatási portra irányuló TCP-ellenőrzés többet mond a pingnél, mert sok gazdagép válaszol ICMP-re, miközben a szolgáltatási port szűrt. Ha a cím válaszol, a név pedig nem, akkor névfeloldási kérdése van, nem útvonalkérdése, és a következő szakasz nem önnek szól.

Ide tartozik két hatókör-ellenőrzés is. Az alkalmazásonkénti VPN azt jelenti, hogy létezhet címútvonal, miközben a teszteléshez használt alkalmazás a belefoglalt halmazon kívül van, ezért olyan alkalmazással teszteljen, amely valóban benne van. Az IPv4-előtag pedig semmit nem mond az IPv6-útról; ha a szolgáltatás dual-stack, adja hozzá a megfelelő IPv6-útvonalat, vagy számítson rá, hogy a kliens egy nem szándékolt utat részesít előnyben.

Egy negatív eredményt érdemes korán felismerni: ha egy full-tunnel útvonal már lefedi a 0.0.0.0/0 tartományt, az előtag nem hiányzik, és újbóli hozzáadása semmit nem változtat. A kettős lefedettség nem javítja a kiszolgálóoldali elutasítást és a hiányzó választ.

Fejezze be az utat a kiszolgálón

Három dolognak kell igaznak lennie a telefonon túl. Az átjárónak útvonalra van szüksége a célhoz, és engedélyre, hogy a telefon forrását felé továbbítsa. A célnak el kell fogadnia ezt a forrást, és a válaszokat az átjárón keresztül vissza kell küldenie, különben a tervezésnek szándékos fordításra van szüksége a kimeneten. Az OpenVPN kézikönyv route opciója a kliensoldali direktívát fedi le; a továbbítás és a visszaút-útvonalazás külön beállítások külön gépeken.

Ha a cél egy másik VPN-kliens mögött van, nem közvetlenül az átjáró mögött, a kiszolgálónak iroute-ra van szüksége ahhoz az alhálózathoz, amely az adott partnerhez tartozik. Ez a direktíva a kiszolgálóé, és leírja, melyik kliens birtokol egy előtagot; egy telefon nem tudja a saját profiljából szolgáltatni, és a kliensoldali szerkesztés semmilyen mennyisége nem pótolja.

Ellenőrizze kifejezetten a visszautat. Az alapértelmezett útvonalon, nem az alagúton kilépő válasz a klasszikus félig nyitott tünetet okozza: a kapcsolat egy irányban létrejön, és semmi nem jön vissza. A forrásfordítás az átjárón legitim javítás, ha a cél nem tud visszafelé útvonalazni, de ez saját következményekkel járó szabály döntés.

Visszaállítás és elfogadás

Szerkesztés előtt őrizze meg az előző profilt. Ha a változtatás ront a helyzeten, állítsa vissza azt a példányt ugyanazon az újraimportálási úton, csatlakozzon újra, és erősítse meg, hogy a régi viselkedés visszatér — ez igazolja, hogy azt változtatta meg, amit gondolt. Az a visszaállítás, amely nem állítja vissza a régi állapotot, azt jelenti, hogy az alkalmazás egy harmadik példányt tart, amelyet nem talált meg.

Akkor fogadja el a változtatást, ha négy dolog teljesül, friss újracsatlakozás után ebben a sorrendben tesztelve: a cél válaszol a szolgáltatási portján, a privát név feloldódik, ha várható, a HTTPS továbbra is érvényesíti a szándékolt gazdagépnevet, és az egész még újraindítás vagy Wi-Fi-ről mobilra váltás után is működik. Az utolsó ellenőrzés az, amely elkapja azt az útvonalat, amely csak addig létezik, amíg az Android újra fel nem építi az alagutat.

• Bármilyen módosítás előtt erősítse meg, hogy a hálózat tulajdonosa engedélyezi a célt.
• Tegye az útvonalat abba a profilba, amelyet a kliens betölt, majd importálja újra és csatlakozzon újra.
• Ellenőrizze szolgáltatási porton keresztül, az alkalmazásonkénti hatókörön belül, a megfelelő címcsaládra.
• A továbbítást, a visszaút-útvonalazást és az iroute-ot a kiszolgálón javítsa, ne a telefonon.
• Tartson visszaállítási példányt, és újraindítás után tesztelje újra.