Android OpenVPN: afegiu una ruta privada sense fer root al telèfon

Necessiteu una subxarxa privada més, per exemple 10.60.0.0/24, que el perfil encara no inclou. En un portàtil afegiríeu una ruta i continuaríeu. A Android la VPN és una aplicació, el dispositiu tun pertany a aquesta aplicació i no hi ha cap taula d’encaminament que pugueu editar sense root. La ruta ha d’existir igualment, però entra al perfil que carrega el client i només funciona si l’altra banda hi està d’acord. Aquí teniu l’edició, la reconnexió, el costat del servidor i la reversió.

Abans de l’edició: què pot i què no pot fer una ruta

Una ruta respon una pregunta: quina interfície ha de portar el trànsit cap a aquesta destinació. No autoritza res. Si el propietari de la xarxa no ha acceptat que aquest telèfon arribi a aquesta subxarxa, una ruta correcta produeix una configuració que sembla correcta i una caiguda silenciosa a la passarel·la, i passareu la propera hora editant el fitxer equivocat.

Obteniu primer aquest acord, per escrit si la xarxa té propietari. Després anoteu què no feu: no assigneu al telèfon cap adreça dins d’aquella LAN, no canvieu l’oient del servidor i no trieu un lloc per nom d’amfitrió. Són quatre canvis diferents i només el primer és vostre.

Editeu el perfil que el client carrega realment

Per a un client compatible que importa text d’opcions OpenVPN corrent, l’addició és una línia:

route 10.60.0.0 255.255.255.0

Afegiu-la al cos del perfil, a prop de les altres directrius d’encaminament, i manteniu el punt final de l’operador, els certificats, la gestió de claus i les línies de verificació exactament com eren. No enganxeu un exemple antic sencer per manllevar una línia: la compressió, els camins absoluts i els xifratges obsolets viatgen amb ell i us costaran una sessió de depuració a part.

El pas que la gent s’salta és la propietat del fitxer. Si l’aplicació ha importat un perfil, la còpia que fa servir és de l’aplicació, i editar l’original baixat no canvia res. Feu servir l’editor admès pel client o torneu a importar el fitxer editat pel camí d’actualització, i confirmeu el nom del perfil actiu quan hi ha diversos noms semblants. Anoteu quin heu canviat.

Si el perfil ja porta route-nopull, no s’instal·la cap ruta del servidor i cada prefix que el telèfon necessita s’ha de llistar explícitament. És un disseny legítim, però vol dir que una línia omesa sembla exactament una negativa del servidor.

Reconnecteu i verifiqueu al dispositiu

Desconnecteu primer i després reconnecteu el perfil concret que heu editat, en lloc de deixar que l’aplicació restauri l’última sessió. Obriu el registre de connexió i confirmeu que el client ha llegit la línia nova; una directriu de ruta que la interfície ignora és un resultat habitual d’editar la còpia equivocada.

Proveu la destinació per adreça, no per nom. Una comprovació TCP a un port de servei conegut és més informativa que un ping, perquè molts amfitrions responen a ICMP mentre el port de servei està filtrat. Si l’adreça respon i un nom no, teniu una qüestió de resolutor i no d’encaminament.

Aquí també hi van dues comprovacions d’abast. Per-app VPN vol dir que una ruta d’adreça pot ser-hi mentre l’aplicació amb què proveu és fora del conjunt inclòs, així que proveu amb una aplicació que hi sigui realment. I un prefix IPv4 no diu res del camí IPv6; si el servei és de doble pila, afegiu la ruta IPv6 corresponent o espereu que el client prefereixi un camí que no volíeu.

Un resultat negatiu val la pena reconèixer-lo aviat: si una ruta de túnel complet ja cobreix 0.0.0.0/0, el prefix no falta i tornar-lo a afegir no canvia res. La cobertura duplicada no arregla una negativa del servidor ni una resposta absent.

Completeu el camí al servidor

Tres coses han de ser certes més enllà del telèfon. La passarel·la necessita una ruta cap a la destinació i permís per reenviar la font del telèfon cap allà. L’objectiu ha d’acceptar aquesta font i retornar les respostes per la passarel·la, o el disseny necessita traducció deliberada a la sortida. L’opció de ruta del manual d’OpenVPN cobreix la directriu del costat client; el reenviament i l’encaminament de retorn són ajustos separats en màquines separades.

Si la destinació és darrere d’un altre client VPN i no directament darrere de la passarel·la, el servidor necessita una iroute per a la subxarxa d’aquell parell. Aquesta directriu és del servidor i descriu quin client posseeix un prefix; un telèfon no la pot proporcionar des del seu perfil i cap edició al costat client la substitueix.

Comproveu el camí de retorn explícitament. Una resposta que surt per la ruta per defecte en lloc del túnel produeix el símptoma clàssic de mitja connexió: la connexió s’estableix en un sentit i no torna res. La traducció de font a la passarel·la és una solució legítima quan l’objectiu no pot encaminar de tornada, però és una decisió de política amb conseqüències pròpies.

Reversió i acceptació

Guardeu el perfil anterior abans d’editar-lo. Si el canvi empitjora les coses, restaureu aquella còpia pel mateix camí de reimportació, reconnecteu i confirmeu que torna el comportament antic; això confirma que heu canviat el que pensàveu. Una reversió que no restaura l’estat antic vol dir que l’aplicació guarda una tercera còpia que no heu trobat.

Accepteu el canvi quan es compleixin quatre coses, provades en aquest ordre després d’una reconnexió nova: la destinació respon al seu port de servei, el nom privat es resol si se n’espera un, HTTPS encara valida l’amfitrió previst, i tot funciona després d’un reinici o d’un canvi de Wi-Fi a mòbil. L’última comprovació és la que atrapa una ruta que només existeix fins que Android restableix el túnel.

• Confirmeu que el propietari de la xarxa permet la destinació abans de tocar res.
• Poseu la ruta al perfil que carrega el client, reimporteu i reconnecteu.
• Verifiqueu pel port de servei, dins de l’abast per-app, per a la família d’adreces correcta.
• Corregiu el reenviament, l’encaminament de retorn i la iroute al servidor, no al telèfon.
• Guardeu una còpia de reversió i torneu a provar després d’un reinici.