OpenVPN pe Android nu adaugă o rută fără adresă de tunel

Profilul dumneavoastră OpenVPN pe Android nu adaugă o rută pentru că telefonul nu are nicio adresă pe interfața virtuală, așa că nu există nimic spre care o rută să poată indica. Rutele răspund doar la întrebarea încotro trebuie să meargă pachetele. Adresa de tunel răspunde la întrebarea cine este telefonul în interiorul tunelului, iar clientul trebuie să furnizeze una înainte ca interfața să poată exista. Parcurgeți cele patru verificări de mai jos în ordine și opriți-vă la primul eșec, pentru că editarea rutelor înainte de a exista adresa ascunde problema reală.

Citiți eșecul în ordinea în care clientul îl execută

VpnService.Builder din Android ține cele două concepte separate: addAddress() pune o adresă pe interfața pe care aplicația o construiește, addRoute() adaugă un prefix de destinație, iar establish() refuză să creeze interfața până când nu a fost adăugată cel puțin o adresă. Un client OpenVPN mapează profilul și opțiunile trimise de server exact pe aceste apeluri, așa că o conexiune care nu analizează niciodată o adresă nu poate construi deloc interfața.

De aceea linia de jurnal pe care o citiți poate numi o rută în timp ce cauza se află cu un pas mai devreme. Clientul ajunge la etapa de rută abia după ce interfața există; fără adresă, apelul de rută eșuează imediat sau nu rulează niciodată. Când jurnalul spune că nu poate adăuga o rută, începeți cu adresa și nu cu sintaxa rutei.

Verificarea 1: pune serverul o adresă în răspuns?

Într-un serviciu OpenVPN cu rutare, adresa provine din pool-ul serverului sau dintr-o alocare pe client, iar topologia decide ce formă are. Pe un server OpenVPN 2.4 sau mai nou, un serviciu cu topologie de subrețea arată așa:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Cu această formă serverul trimite ceva de genul ifconfig 10.8.0.6 255.255.255.0. O instalare mai veche cu topology net30 trimite în schimb o adresă de partener, de exemplu ifconfig 10.8.0.6 10.8.0.5, așa că un profil mutat între cele două modele poate părea corect în timp ce poartă masca de rețea greșită.

Căutați în jurnalul de conexiune al clientului setul de opțiuni trimise. Dacă nu conține nicio linie ifconfig, serverul nu a trimis niciodată o adresă sau clientul a refuzat opțiunea. Pe un server care folosește client-config-dir, fișierul numit după common name-ul certificatului trebuie să existe și să conțină alocarea:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Verificarea 2: păstrează clientul adresa primită?

Un filtru prea larg este a doua cauză obișnuită. pull-filter există în OpenVPN 2.4 și versiunile mai noi, iar când mai multe filtre se potrivesc pe aceeași opțiune câștigă ultimul care se potrivește, așa că un catch-all pus la final elimină adresa fără eroare:

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

Îngustați filtrul la opțiunea de care chiar vreți să scăpați și lăsați adresa în pace:

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

Sfatul de a dezactiva toate pull-urile vine de obicei de la cineva care vrea să scape de o singură rută. route-nopull este comutatorul mai îngust: păstrează ifconfig și celelalte opțiuni trimise, refuzând în schimb rutele trimise și opțiunile de tip DHCP. Folosiți-l când asta este într-adevăr ce doriți, și rezolvați separat întrebarea adresei.

Verificarea 3: adresa este a dumneavoastră de scris?

Adresarea manuală este legitimă doar când operatorul vă înmânează valoarea. Dacă scrieți una singuri, ea trebuie să provină din subrețeaua clientului VPN, să fie unică între sesiunile active și să corespundă topologiei pe care o rulează serverul. Copierea adresei unui bridge de desktop sau a unui gazdă din LAN-ul îndepărtat eșuează pe ambele planuri: telefonul ar revendica o adresă care există deja în altă parte, iar gateway-ul nu ar avea nicio cale de întoarcere către ea.

Prefixul LAN-ului îndepărtat dintr-o rută este o destinație, niciodată identitatea telefonului. O rută pentru 10.60.0.0/24 spune să ajungeți la acea rețea prin tunel; nu spune nimic despre ce adresă 10.60.0.x ar trebui să aibă telefonul, iar telefonul nu ar trebui să aibă niciuna dintre ele. Alocările statice aparțin părții serverului, unde nu pot intra în conflict cu pool-ul dinamic.

Două sesiuni pe o singură identitate expun aceeași coliziune. Dacă același certificat se conectează de două ori și serverul trimite o adresă fixă ambelor, a doua sesiune o duplică pe prima, iar soluția este identități separate sau alocări separate, nu o modificare pe partea clientului.

Verificarea 4: altceva ocupă locul tunelului?

Android permite un singur serviciu VPN activ o dată. O altă aplicație VPN, sau o intrare de VPN mereu activă lăsată pornită pentru un profil care nu mai funcționează, poate ocupa acel loc înainte ca clientul dumneavoastră OpenVPN să apeleze establish(). Atunci interfața nu apare niciodată deși profilul este valid, așa că deconectați cealaltă VPN, opriți setarea de mereu activ și reconectați înainte de a atinge profilul.

Un serviciu care insistă pe puntea Ethernet este celălalt drum înfundat. O aplicație Android fără root poate crea un tunel IP, nu un segment Ethernet punte, așa că nicio adresă pe care o scrieți nu va face un server dev tap să funcționeze; operatorul trebuie să ofere un serviciu cu rutare. Când raportați problema, includeți numele și versiunea clientului, setul de opțiuni trimise, topologia și pasul exact în care adresa ar fi trebuit să apară.

Dacă toate cele patru verificări trec și adresa este prezentă, unică și mascată corect, întrebarea despre rută devine cea obișnuită: ce prefixe autorizează serverul și cum ar trebui clientul să le delimiteze. Notați adresa tunelului, masca de rețea și topologia înainte de a schimba orice altceva, pentru că aceste trei valori sunt cele pe care operatorul trebuie să le compare cu vederea serverului.