OpenVPN en Android non engade unha ruta sen enderezo de túnel

O teu perfil OpenVPN en Android non engade unha ruta porque o teléfono non ten ningún enderezo na interface virtual, así que non hai nada ao que unha ruta poida apuntar. As rutas só responden a onde deben ir os paquetes. O enderezo de túnel responde quen é o teléfono dentro do túnel, e o cliente debe fornecer un antes de que a interface poida existir. Percorre as catro comprobacións seguintes en orde e detente no primeiro fallo, porque editar rutas antes de que exista o enderezo agocha o problema real.

Le o fallo na orde en que o executa o cliente

O VpnService.Builder de Android mantén os dous conceptos separados: addAddress() pon un enderezo na interface que constrúe a aplicación, addRoute() engade un prefixo de destino e establish() négase a crear a interface ata que se engadiu polo menos un enderezo. Un cliente OpenVPN asigna o perfil e as opcións que empuxa o servidor exactamente a esas chamadas, así que unha conexión que nunca analiza un enderezo non pode construír a interface en absoluto.

Por iso a liña de rexistro que estás a ler pode nomear unha ruta mentres a causa está un paso antes. O cliente só chega á fase de ruta despois de que exista a interface; sen enderezo, a chamada de ruta falla de inmediato ou nunca se executa. Cando o rexistro di que non pode engadir unha ruta, comeza polo enderezo e non pola sintaxe da ruta.

Comprobación 1: pon o servidor un enderezo na resposta?

Nun servizo OpenVPN enrutado o enderezo procede do conxunto do servidor ou dunha asignación por cliente, e a topoloxía decide que forma ten. Nun servidor OpenVPN 2.4 ou posterior, un servizo con topoloxía de subrede ten este aspecto:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Con esa forma o servidor empuxa algo como ifconfig 10.8.0.6 255.255.255.0. Un despregamento anterior con topology net30 empuxa no seu lugar un enderezo de par, por exemplo ifconfig 10.8.0.6 10.8.0.5, así que un perfil movido entre os dous modelos pode parecer correcto mentres leva a máscara de rede incorrecta.

Busca no rexistro de conexión do cliente o conxunto de opcións empuxadas. Se non contén ningunha liña ifconfig, o servidor nunca enviou un enderezo ou o cliente rexeitou a opción. Nun servidor que usa client-config-dir, o ficheiro nomeado segundo o common name do certificado debe existir e levar a asignación:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Comprobación 2: conserva o cliente o enderezo que recibiu?

Un filtro demasiado amplo é a segunda causa habitual. pull-filter existe en OpenVPN 2.4 e posteriores, e cando varios filtros coinciden coa mesma opción gaña o último que coincide, así que un catch-all final elimina o enderezo sen erro:

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

Estreita o filtro á opción que realmente queres eliminar e deixa o enderezo en paz:

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

O consello de desactivar todos os pull adoita vir de alguén que quere desfacerse dunha soa ruta. route-nopull é o interruptor máis estreito: conserva ifconfig e as demais opcións empuxadas mentres rexeita as rutas empuxadas e as opcións tipo DHCP. Úsao cando iso sexa de verdade o que queres, e responde a cuestión do enderezo por separado.

Comprobación 3: o enderezo é teu para escribilo?

O direccionamento manual só é lexítimo cando o operador che entrega o valor. Se escribes un ti mesmo, ten que vir da subrede do cliente VPN, ser único entre as sesións activas e coincidir coa topoloxía que executa o servidor. Copiar o enderezo dunha ponte de escritorio ou dun equipo da LAN remota falla por ambos motivos: o teléfono reclamaría un enderezo que xa existe noutro sitio, e a pasarela non tería camiño de volta cara a el.

O prefixo da LAN remota nunha ruta é un destino, nunca a identidade do teléfono. Unha ruta para 10.60.0.0/24 di chega a esa rede polo túnel; non di nada sobre que enderezo 10.60.0.x debería ter o teléfono, e o teléfono non debería ter ningún deles. As asignacións estáticas pertencen ao lado do servidor, onde non poden chocar co conxunto dinámico.

Dúas sesións cunha mesma identidade expoñen a mesma colisión. Se o mesmo certificado se conecta dúas veces e o servidor empuxa un enderezo fixo a ambas, a segunda sesión duplica a primeira, e a solución son identidades distintas ou asignacións distintas en lugar dunha edición no cliente.

Comprobación 4: hai algo máis ocupando o oco do túnel?

Android permite un só servizo VPN activo á vez. Outra aplicación VPN, ou unha entrada de VPN sempre activa deixada habilitada para un perfil que xa non funciona, pode ocupar ese oco antes de que o teu cliente OpenVPN chame a establish(). Entón a interface nunca aparece aínda que o perfil sexa válido, así que desconecta a outra VPN, desactiva o axuste de sempre activa e volve conectar antes de tocar o perfil.

Un servizo que esixe ponte Ethernet é o outro camiño sen saída. Unha aplicación Android sen root pode crear un túnel IP, non un segmento Ethernet con ponte, así que ningún enderezo que escribas fará funcionar un servidor dev tap; o operador ten que ofrecer un servizo enrutado. Cando informes do problema, inclúe o nome e a versión do cliente, o conxunto de opcións empuxadas, a topoloxía e o paso exacto no que debería ter aparecido o enderezo.

Se as catro comprobacións pasan e o enderezo está presente, é único e ten a máscara correcta, a cuestión da ruta pasa a ser a habitual: que prefixos autoriza o servidor e como debe limitelos o cliente. Anota o enderezo do túnel, a súa máscara de rede e a topoloxía antes de cambiar calquera outra cousa, porque eses tres valores son os que o operador necesita comparar coa vista do servidor.