Android OpenVPN: engadir unha ruta privada sen rootear o teléfono
Engade unha ruta dentro do perfil que Android carga de verdade e despois comproba que o servidor a permite. Guía da edición, da reconexión e de catro comprobacións.
Necesitas unha subrede privada máis — digamos 10.60.0.0/24 — que o perfil non inclúe agora mesmo. Nun portátil engadirías unha ruta e seguirías. En Android a VPN é unha aplicación, o dispositivo tun pertence a esa aplicación e non hai táboa de rutas que poidas editar sen root. A ruta ten que existir igualmente, pero vai dentro do perfil que carga o cliente, e só funciona se o outro extremo está de acordo. Aquí están a edición, a reconexión, o lado do servidor e a reversión.
Antes da edición: que pode e que non pode facer unha ruta
Unha ruta responde a unha pregunta: que interface debe levar o tráfico cara a este destino. Non autoriza nada. Se o propietario da rede non aceptou que este teléfono poida chegar a esa subrede, unha ruta correcta produce unha configuración que parece correcta e un descarte silencioso na pasarela, e pasarás a hora seguinte editando o ficheiro equivocado.
Consegue ese acordo primeiro, por escrito se a rede ten propietario. Despois anota o que non estás facendo: non lle asignas ao teléfono un enderezo dentro desa LAN, non cambias o listener do servidor e non elixes un sitio por nome de host. Son catro cambios distintos e só o primeiro é teu.
| 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 |
Edita o perfil que o cliente carga de verdade
Para un cliente compatible que importa texto de opcións OpenVPN normal, a adición é unha liña:
route 10.60.0.0 255.255.255.0Engádea ao corpo do perfil, preto das outras directivas de encamiñamento, e deixa o endpoint, os certificados, o manexo de claves e as liñas de verificación do operador exactamente como estaban. Non pegues un exemplo antigo enteiro para tomar prestada unha liña: a compresión, as rutas de ficheiro absolutas e os axustes de cifrado obsoletos viaxan con el e custaranche unha sesión de depuración aparte.
O paso que a xente se salta é a propiedade do ficheiro. Se a aplicación importou un perfil, a copia que usa é da aplicación, e editar o orixinal descargado non cambia nada. Usa o editor compatible do cliente, ou volve importar o ficheiro editado pola ruta de actualización, e confirma o nome do perfil activo cando existan varios nomes parecidos. Anota cal cambiaches.
Se o perfil xa leva route-nopull, non se instala ningunha ruta do servidor e cada prefixo que o teléfono necesita debe listarse explicitamente. É un deseño lexítimo, pero significa que unha liña omitida se ve exactamente igual que unha negativa do servidor.
Reconecta e verifica no dispositivo
Desconecta primeiro e logo reconecta o perfil concreto que editaches, en lugar de deixar que a aplicación restaure a última sesión. Abre o rexistro de conexión e confirma que o cliente analizou a nova liña; unha directiva de ruta que o frontend ignora é un resultado habitual de editar a copia equivocada.
Proba o destino por enderezo, non por nome. Unha comprobación TCP a un porto de servizo coñecido informa máis que un ping, porque moitos hosts responden a ICMP mentres o porto de servizo está filtrado. Se o enderezo responde e un nome non, tes unha cuestión de resolver e non de encamiñamento, e a sección seguinte non é para ti.
Aquí tamén corresponden dúas comprobacións de alcance. O VPN por aplicación significa que pode haber unha ruta de enderezo mentres a aplicación coa que probas está fóra do conxunto incluído, así que proba cunha aplicación que estea realmente dentro. E un prefixo IPv4 non di nada sobre a ruta IPv6; se o servizo é dual-stack, engade a ruta IPv6 correspondente ou espera que o cliente prefira unha ruta que non pretendías.
Un resultado negativo convén recoñecelo cedo: se unha ruta de túnel completo xa cobre 0.0.0.0/0, o prefixo non falta e engadilo outra vez non cambia nada. A cobertura duplicada non repara unha denegación do servidor nin unha resposta ausente.
Termina o camiño no servidor
Tres cousas deben ser certas máis alá do teléfono. A pasarela necesita unha ruta ao destino e permiso para reenviar a orixe do teléfono cara a el. O obxectivo debe aceptar esa orixe e devolver as respostas pola pasarela, ou o deseño necesita unha tradución deliberada na saída. A opción route do manual de OpenVPN cobre a directiva do lado do cliente; o reenvío e o encamiñamento de retorno son axustes separados en máquinas separadas.
Se o destino está detrás doutro cliente VPN en lugar de directamente detrás da pasarela, o servidor necesita unha iroute para a subrede dese par. Esa directiva é propiedade do servidor e describe que cliente posúe un prefixo; un teléfono non pode achegala desde o seu propio perfil, e ningunha cantidade de edición no cliente a substitúe.
Comproba o camiño de retorno de forma explícita. Unha resposta que sae pola ruta por defecto en lugar do túnel produce o síntoma clásico de medio aberto: a conexión establécese nunha dirección e non volve nada. A tradución de orixe na pasarela é unha corrección lexítima cando o obxectivo non pode encamiñar de volta, pero é unha decisión de política coas súas propias consecuencias.
Reversión e aceptación
Garda o perfil anterior antes de editalo. Se o cambio empeora as cousas, restaura esa copia pola mesma ruta de reimportación, reconecta e confirma que volve o comportamento antigo: iso confirma que cambiaches o que crías ter cambiado. Unha reversión que non restaura o estado antigo significa que a aplicación garda unha terceira copia que non atopaches.
Acepta o cambio cando se cumpran catro cousas, probadas nesta orde tras unha reconexión nova: o destino responde no seu porto de servizo, o nome privado resolve se se espera un, HTTPS segue validando o nome de host previsto e todo segue funcionando tras un reinicio ou un cambio de Wi-Fi a rede móbil. A última comprobación é a que detecta unha ruta que só existe ata que Android restablece o túnel.
- Confirma que o propietario da rede permite o destino antes de editar nada.
- Pon a ruta no perfil que carga o cliente e logo reimporta e reconecta.
- Verifica por porto de servizo, dentro do alcance por aplicación, para a familia de enderezos correcta.
- Corrixe o reenvío, o encamiñamento de retorno e a iroute no servidor, non no teléfono.
- Garda unha copia de reversión e volve probar tras un reinicio.