Android OpenVPN no afegeix ruta sense adreça de túnel

El teu perfil OpenVPN a Android no afegeix cap ruta perquè el telèfon no té adreça a la interfície virtual, i per tant la ruta no té a on apuntar. Les rutes només diuen on han d’anar els paquets. L’adreça de túnel diu qui és el telèfon dins del túnel, i el client n’ha de proporcionar una abans que la interfície pugui existir. Fes les quatre comprovacions d’abaix en ordre i atura’t al primer error, perquè editar rutes abans que existeixi l’adreça amaga el problema real.

Llegeix el error en l’ordre en què el client l’executa

VpnService.Builder a Android manté els dos conceptes separats: addAddress() posa una adreça a la interfície que l’aplicació està construint, addRoute() afegeix un prefix de destí, i establish() es nega a crear la interfície fins que s’hagi afegit com a mínim una adreça. El client OpenVPN mapifica el perfil i les opcions que envia el servidor exactament a aquestes crides, així que una connexió que no llegeix cap adreça no pot construir la interfície.

Per això la línia de registre que llegeixes pot esmentar una ruta mentre la causa és un pas abans. El client arriba a la fase de ruta només quan la interfície existeix; sense adreça, la crida falla de seguida o no s’executa mai. Quan el registre diu que no pot afegir una ruta, comença per l’adreça i no per la sintaxi de la ruta.

Comprovació 1: el servidor posa una adreça a la resposta?

En un servei OpenVPN encaminat, l’adreça ve del pool del servidor o d’una assignació per client, i la topologia decideix la seva forma. En un servidor OpenVPN 2.4 o posterior, un servei amb topologia de subxarxa es veu així:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Amb aquesta forma el servidor envia una cosa com ifconfig 10.8.0.6 255.255.255.0. Un desplegament més antic amb topology net30 envia en canvi una adreça d’igual, per exemple ifconfig 10.8.0.6 10.8.0.5, així que un perfil mogut entre els dos models pot semblar correcte i portar una màscara de xarxa equivocada.

Busca al registre de connexió del client el conjunt d’opcions enviades. Si no hi ha cap línia ifconfig, el servidor no ha enviat mai cap adreça o el client ha rebutjat l’opció. En un servidor que fa servir client-config-dir, el fitxer que porta el nom comú del certificat ha d’existir i contenir l’assignació:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Comprovació 2: conserva el client l’adreça que se li ha donat?

Un filtre massa ampli és la segona causa habitual. pull-filter existeix des d’OpenVPN 2.4 i posteriors, i quan diversos filtres coincideixen amb la mateixa opció guanya l’últim, així que un filtre final que ho atrapa tot elimina l’adreça sense cap error:

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

Estreny el filtre fins a l’opció que realment vols treure i deixa l’adreça tranquil·la:

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

El consell de desactivar tots els pull sol venir d’algú que vol treure@s una sola ruta. route-nopull és l’interruptor més estret: manté ifconfig i la resta d’opcions enviades i només rebutja les rutes enviades i les opcions DHCP. Fes-lo servir quan això és realment el que vols i respon la pregunta de l’adreça per separat.

Comprovació 3: l’adreça és teva per escriure-la?

L’adreçament manual només és legítim quan l’operador et dona el valor. Si n’escrius una tu mateix, ha de venir de la subxarxa del client VPN, ser única entre les sessions actives i coincidir amb la topologia que executa el servidor. Copiar l’adreça d’un pont d’escriptori o d’un equip de la LAN remota falla per dos motius: el telèfon reclamaria una adreça que ja existeix en un altre lloc, i la passarel·la no tindria camí de tornada cap a ella.

El prefix de la LAN remota en una ruta és una destinació, mai la identitat del telèfon. Una ruta per a 10.60.0.0/24 diu arriba a aquesta xarxa pel túnel; no diu quina adreça 10.60.0.x ha de tenir el telèfon, i el telèfon no n’ha de tenir cap. Les assignacions estàtiques van a la banda del servidor, on no xoquen amb el pool dinàmic.

Dues sessions sobre una identitat mostren el mateix xoc. Si el mateix certificat es connecta dues vegades i el servidor envia una adreça fixa a tots dos, la segona sessió duplica la primera, i la solució són identitats o assignacions separades, no una edició al client.

Comprovació 4: hi ha alguna altra cosa ocupant l’espai del túnel?

Android només permet un servei VPN actiu alhora. Una altra aplicació VPN, o una entrada always-on que s’ha quedat activada per a un perfil que ja no funciona, pot ocupar aquest lloc abans que el teu client OpenVPN cridi establish(). Llavors la interfície no apareix mai encara que el perfil sigui vàlid, així que desconnecta l’altre VPN, apaga l’always-on i torna a connectar abans de tocar el perfil.

Un servei que insisteix en un pont Ethernet és l’altre carreró sense sortida. Una aplicació Android sense root pot crear un túnel IP, però no un segment Ethernet pontat, així que cap adreça que escriguis farà funcionar un servidor amb dev tap; l’operador ha d’oferir un servei encaminat. Quan reportis el problema, inclou el nom i la versió del client, el conjunt d’opcions enviades, la topologia i el pas exacte on l’adreça hauria d’haver aparegut.

Si les quatre comprovacions passen i l’adreça hi és, és única i està ben emmascarada, la pregunta de la ruta es torna l’habitual: quins prefixos autoritza el servidor i com els ha d’abastar el client. Anota l’adreça del túnel, la seva màscara i la topologia abans de canviar res més, perquè aquests tres valors són el que l’operador necessita comparar amb la vista del servidor.