Az Android OpenVPN alagút-cím nélkül nem ad hozzá útvonalat

Az Androidos OpenVPN-profilod nem tud útvonalat hozzáadni, mert a telefonon nincs cím a virtuális interfészen, így nincs mi felé az útvonal mutathatna. Az útvonalak csak arra válaszolnak, hová menjenek a csomagok. Az alagút-cím arra válaszol, ki a telefon az alagúton belül, és a kliensnek adnia kell egyet, mielőtt az interfész létrejöhet. Menj végig az alábbi négy ellenőrzésen sorrendben, és állj meg az első hibánál, mert az útvonalak szerkesztése a cím létezése előtt elrejti a valódi problémát.

Olvasd a hibát abban a sorrendben, ahogy a kliens végrehajtja

Az Android VpnService.Builder külön tartja a két fogalmat: addAddress() címet tesz arra az interfészre, amelyet az alkalmazás épít, addRoute() cél-előtagot ad hozzá, és establish() megtagadja az interfész létrehozását, amíg legalább egy cím hozzá nem lett adva. Az OpenVPN kliens a profilt és a szerver által küldött beállításokat pontosan ezekre a hívásokra képezi le, ezért az a kapcsolat, amely soha nem dolgoz fel címet, egyáltalán nem tudja felépíteni az interfészt.

Ezért fordulhat elő, hogy a naplósor, amelyet olvasol, útvonalat említ, miközben az ok egy lépéssel korábban van. A kliens csak az interfész létezése után ér el az útvonal-szakaszhoz; cím nélkül az útvonal-hívás azonnal meghiúsul vagy soha nem fut le. Amikor a napló azt mondja, nem tud útvonalat hozzáadni, kezdd a címmel, és ne az útvonal szintaxisával.

1. ellenőrzés: tesz-e a szerver címet a válaszba?

Egy útvonalazott OpenVPN-szolgáltatásnál a cím a szerver készletéből vagy ügyfelenkénti kiosztásból származik, és a topológia dönti el az alakját. Egy OpenVPN 2.4 vagy újabb szerveren az alhálózati topológiájú szolgáltatás így néz ki:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Ezzel az alakkal a szerver valami olyasmit küld, mint ifconfig 10.8.0.6 255.255.255.0. Egy régebbi topology net30 telepítés helyette partner-címet küld, például ifconfig 10.8.0.6 10.8.0.5, ezért a két modell között átvitt profil helyesnek tűnhet, miközben rossz hálózati maszkot hordoz.

Keresd meg a kliens kapcsolati naplójában a küldött beállításkészletet. Ha egyáltalán nincs benne ifconfig sor, a szerver soha nem küldött címet, vagy a kliens elutasította a beállítást. Az client-config-dir-t használó szerveren a tanúsítvány common name-je után elnevezett fájlnak léteznie kell, és tartalmaznia kell a kiosztást:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

2. ellenőrzés: megtartja-e a kliens a kapott címet?

A túl széles szűrő a második gyakori ok. A pull-filter az OpenVPN 2.4 és újabb változataiban létezik, és amikor több szűrő illeszkedik ugyanarra a beállításra, a legutolsó illeszkedő nyer, ezért a végére tett catch-all hiba nélkül eltávolítja a címet:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Szűkítsd a szűrőt arra a beállításra, amelytől valóban meg akarsz szabadulni, és hagyd békén a címet:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

A tanács, hogy kapcsold ki az összes pullt, általában olyantól jön, aki egyetlen útvonaltól akar megszabadulni. A route-nopull a szűkebb kapcsoló: megtartja az ifconfigot és a többi küldött beállítást, miközben elutasítja a küldött útvonalakat és a DHCP-szerű beállításokat. Akkor használd, ha valóban ezt akarod, és a cím kérdését külön válaszold meg.

3. ellenőrzés: a te dolgod-e beírni a címet?

A kézi címzés csak akkor jogos, ha az üzemeltető adja át az értéket. Ha magad írsz be egyet, annak a VPN kliens alhálózatából kell származnia, egyedinek kell lennie az aktív munkamenetek között, és meg kell felelnie a szerveren futó topológiának. Egy asztali híd vagy egy távoli LAN-on lévő gazdagép címének másolása mindkét okból meghiúsul: a telefon olyan címet követelne, amely már létezik máshol, és a hálózati átjárónak nem lenne visszaútja hozzá.

Az útvonalban szereplő távoli LAN-előtag célállomás, soha nem a telefon identitása. A 10.60.0.0/24 útvonala azt mondja, hogy azon a hálózaton az alagúton keresztül érsz el; semmit nem mond arról, melyik 10.60.0.x címet kellene a telefonnak birtokolnia, és a telefonnak egyiket sem kellene birtokolnia. A statikus kiosztások a szerver oldalára tartoznak, ahol nem ütközhetnek a dinamikus készlettel.

Két munkamenet egy identitáson ugyanazt az ütközést tárja fel. Ha ugyanaz a tanúsítvány kétszer csatlakozik, és a szerver mindkettőnek ugyanazt a fix címet küldi, a második munkamenet megkettőzi az elsőt, és a megoldás a külön identitás vagy külön kiosztás, nem a kliens oldali szerkesztés.

4. ellenőrzés: valami más foglalja az alagút helyét?

Az Android egyszerre csak egy aktív VPN-szolgáltatást engedélyez. Egy másik VPN-alkalmazás vagy egy mindig bekapcsolt VPN-bejegyzés, amelyet egy már nem működő profilhoz hagytak bekapcsolva, elveheti ezt a helyet, mielőtt az OpenVPN kliensed meghívja a establish()-t. Ekkor az interfész soha nem jelenik meg, pedig a profil érvényes, ezért bontsd a másik VPN-t, kapcsold ki a mindig bekapcsolt beállítást, és csatlakozz újra, mielőtt a profilhoz nyúlsz.

Az Ethernet-hidat követelő szolgáltatás a másik zsákutca. Egy root nélküli Android-alkalmazás IP-alagutat tud létrehozni, nem hidalt Ethernet-szegmenst, ezért semmilyen beírt cím nem teszi működőképessé a dev tap szervert; az üzemeltetőnek útvonalazott szolgáltatást kell kínálnia. Amikor jelented a problémát, add meg a kliens nevét és verzióját, a küldött beállításkészletet, a topológiát és azt a pontos lépést, ahol a címnek meg kellett volna jelennie.

Ha mind a négy ellenőrzés átmegy, és a cím jelen van, egyedi és helyesen maszkolt, az útvonal kérdése a szokásos lesz: mely előtagokat engedélyezi a szerver, és hogyan kell a kliensnek azokat behatárolnia. Jegyezd fel az alagút címét, hálózati maszkját és a topológiát, mielőtt bármi mást megváltoztatnál, mert ez a három érték az, amit az üzemeltetőnek a szerver nézetével össze kell vetnie.