Android OpenVPN: adăugarea unei rute private fără rootarea telefonului
Adaugă o rută în profilul pe care Android îl încarcă efectiv, apoi verifică dacă serverul o permite. Ghid pentru modificare, reconectare și patru verificări.
Ai nevoie de încă o subrețea privată — să zicem 10.60.0.0/24 — pe care profilul nu o conține acum. Pe un laptop ai adăuga o rută și ai merge mai departe. Pe Android, VPN-ul este o aplicație, dispozitivul tun aparține acelei aplicații și nu există un tabel de rutare pe care să îl editezi fără root. Ruta trebuie totuși să existe, dar intră în profilul pe care îl încarcă clientul și funcționează doar dacă cealaltă parte este de acord. Iată modificarea, reconectarea, partea de server și revenirea.
Înainte de modificare: ce poate și ce nu poate face o rută
O rută răspunde la o singură întrebare: ce interfață trebuie să transporte traficul către această destinație. Nu autorizează nimic. Dacă proprietarul rețelei nu a fost de acord ca acest telefon să ajungă în acea subrețea, o rută corectă produce o configurație care arată corect și o renunțare silențioasă la gateway, iar următoarea oră o petreci editând fișierul greșit.
Obține mai întâi acordul, în scris dacă rețeaua are un proprietar. Apoi notează ce nu faci: nu atribui telefonului o adresă în acel LAN, nu schimbi listenerul serverului și nu alegi un site după numele gazdă. Sunt patru modificări diferite și doar prima este a ta.
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
Editează profilul pe care clientul îl încarcă efectiv
Pentru un client compatibil care importă text obișnuit de opțiuni OpenVPN, adaosul este o singură linie:
route 10.60.0.0 255.255.255.0Adaug-o în corpul profilului, lângă celelalte directive de rutare, și păstrează endpointul, certificatele, gestionarea cheilor și liniile de verificare ale operatorului exact cum erau. Nu lipi un exemplu vechi întreg ca să împrumuți o linie: compresia, căile absolute de fișier și setările cipher învechite călătoresc cu el și te vor costa o sesiune separată de depanare.
Pasul pe care oamenii îl ratează este proprietatea fișierului. Dacă aplicația a importat un profil, copia pe care o folosește este a aplicației, iar editarea originalului descărcat nu schimbă nimic. Folosește editorul suportat al clientului sau reimportă fișierul editat pe calea de actualizare și confirmă numele profilului activ când există mai multe nume similare. Notează pe care l-ai schimbat.
Dacă profilul conține deja route-nopull, nu se instalează nicio rută de la server și fiecare prefix de care telefonul are nevoie trebuie listat explicit. Este un design legitim, dar înseamnă că o linie omisă arată exact ca un refuz al serverului.
Reconectează și verifică pe dispozitiv
Deconectează-te mai întâi, apoi reconectează-te exact la profilul pe care l-ai editat, în loc să lași aplicația să restaureze ultima sesiune. Deschide jurnalul de conexiune și confirmă că clientul a analizat noua linie; o directivă de rutare ignorată de interfață este un rezultat obișnuit al editării copiei greșite.
Testează destinația după adresă, nu după nume. O verificare TCP către un port de serviciu cunoscut spune mai mult decât un ping, pentru că multe gazde răspund la ICMP în timp ce portul de serviciu este filtrat. Dacă adresa răspunde și un nume nu, ai o întrebare de resolver și nu de rutare, iar secțiunea următoare nu este pentru tine.
Aici intră și două verificări de domeniu. VPN per aplicație înseamnă că o rută de adresă poate exista în timp ce aplicația cu care testezi este în afara setului inclus, așa că testează cu o aplicație care este efectiv înăuntru. Iar un prefix IPv4 nu spune nimic despre calea IPv6; dacă serviciul este dual-stack, adaugă ruta IPv6 corespunzătoare sau așteaptă-te ca clientul să prefere o cale pe care nu ai intenționat-o.
Un rezultat negativ merită recunoscut devreme: dacă o rută full-tunnel acoperă deja 0.0.0.0/0, prefixul nu lipsește și adăugarea lui din nou nu schimbă nimic. Acoperirea dublă nu repară un refuz din partea serverului sau un răspuns lipsă.
Termină calea pe server
Trei lucruri trebuie să fie adevărate dincolo de telefon. Gatewayul are nevoie de o rută către destinație și de permisiunea de a trimite sursa telefonului spre ea. Ținta trebuie să accepte acea sursă și să returneze răspunsurile prin gateway, altfel designul are nevoie de traducere deliberată la ieșire. Opțiunea route din manualul OpenVPN acoperă directiva din partea clientului; forwardarea și rutarea de retur sunt setări separate pe mașini separate.
Dacă destinația se află în spatele altui client VPN și nu direct în spatele gatewayului, serverul are nevoie de un iroute pentru subrețeaua acelui peer. Acea directivă aparține serverului și descrie care client deține un prefix; un telefon nu o poate furniza din propriul profil, iar nicio cantitate de editare pe partea clientului nu o înlocuiește.
Verifică explicit calea de retur. Un răspuns care iese pe ruta implicită în loc de tunel produce simptomul clasic de jumătate deschis: conexiunea este stabilită într-o direcție și nimic nu se întoarce. Traducerea sursei pe gateway este o corecție legitimă când ținta nu poate ruta înapoi, dar este o decizie de politică cu consecințele ei.
Revenire și acceptare
Păstrează profilul anterior înainte de a-l edita. Dacă modificarea înrăutățește situația, restaurează acea copie pe aceeași cale de reimportare, reconectează-te și confirmă că comportamentul vechi revine — asta confirmă că ai schimbat ceea ce credeai că schimbi. O revenire care nu restaurează starea veche înseamnă că aplicația păstrează o a treia copie pe care nu ai găsit-o.
Acceptă modificarea când patru lucruri sunt valabile, testate în această ordine după o reconectare proaspătă: destinația răspunde pe portul ei de serviciu, numele privat se rezolvă dacă este așteptat, HTTPS validează în continuare numele de gazdă dorit și totul funcționează încă după o repornire sau o trecere de la Wi-Fi la rețeaua mobilă. Ultima verificare este cea care prinde o rută care există doar până când Android restabilește tunelul.
- Confirmă că proprietarul rețelei permite destinația înainte de a edita orice.
- Pune ruta în profilul pe care clientul îl încarcă, apoi reimportă și reconectează.
- Verifică prin portul de serviciu, în domeniul per aplicație, pentru familia de adrese corectă.
- Corectează forwardarea, rutarea de retur și iroute pe server, nu pe telefon.
- Păstrează o copie de revenire și retestează după o repornire.