VPN de Android a Cisco IOS: el contrato que hay que obtener primero

El teléfono tiene que llegar a una puerta de enlace Cisco. Alguien ya ha nombrado el cliente que hay que instalar. Ese es el extremo equivocado del proceso, y por eso el túnel falla tras una hora de volver a teclear credenciales.

Lo que necesita primero es un contrato de conexión: protocolo, autenticación, identidad, material de confianza, asignación de direcciones y enrutamiento, escrito por quien administra la puerta de enlace.

Consígalo por escrito y la elección del cliente se convierte en una consulta. Omítalo y cada fallo parecerá una contraseña incorrecta.

Haga la recogida antes de instalar nada

Envíe al responsable de la puerta de enlace una lista y pida respuestas, no un nombre de producto. Nueve puntos cubren por completo un perfil de acceso remoto:

1. El nombre de host o la dirección de la puerta de enlace a la que debe marcar el cliente, y si es accesible desde fuera.
2. El protocolo y la versión: IKEv2, otra generación de IPsec o un servicio basado en TLS.
3. La identidad de par que espera la puerta de enlace y lo que ella misma presenta.
4. Material de confianza: qué CA firma el certificado de la puerta de enlace o si se usa una clave precompartida.
5. Autenticación de usuario: certificado, nombre de usuario y contraseña EAP o una clave precompartida.
6. El grupo de direcciones en el que cae el cliente, con máscara y puerta de enlace.
7. Los servidores DNS que se usarán dentro del túnel y si el cliente debe aceptarlos.
8. Los prefijos de destino permitidos y si el tráfico fuera de ellos debe bloquearse.
9. Las versiones de cliente admitidas y las versiones del sistema operativo del teléfono, además de cualquier requisito de alta.

Dos de esos puntos causan la mayoría de los fallos evitables. Sin el material de confianza no puede validar la puerta de enlace, así que un cliente correcto parece averiado. Sin los prefijos permitidos no puede distinguir una restricción de enrutamiento de un problema de servicio.

El nombre del fabricante no es un protocolo

Cisco IOS e IOS XE ofrecen varias disposiciones de acceso remoto y no comparten un mismo formato de transmisión. IKEv2 con un perfil estilo FlexVPN no es el mismo servicio que una configuración IKEv1 más antigua, y un servicio de cliente basado en TLS es todavía otro producto, a menudo en otra plataforma dentro del mismo entorno.

Por tanto, un cliente cuyo nombre menciona al fabricante del router no demuestra nada. Puede implementar bien uno de esos servicios y ninguno de los demás. Pregunte qué servicio está configurado y después compruebe si la documentación del cliente nombra ese servicio como admitido.

La propia documentación de IKEv2 de Cisco separa la propuesta, la política, el perfil y el llavero como objetos distintos. Esa estructura resulta útil cuando lee una configuración que alguien le pega: le dice qué objeto contiene los ajustes que importan para un teléfono remoto, en lugar de tratar todo el archivo como un solo bloque.

Qué cubre la pila integrada de Android

Android expone un perfil IKEv2/IPsec de plataforma mediante Ikev2VpnProfile, con tipos de autenticación separados para una clave precompartida, un certificado RSA y nombre de usuario y contraseña EAP. La referencia de Ikev2VpnProfile es la autoridad sobre lo que acepta el constructor, incluido el nombre de host de la puerta de enlace y la CA raíz del servidor usada para validarlo.

Esa API es una declaración de capacidad, no una promesa de compatibilidad. Dice que la plataforma puede hacer IKEv2 con esos tipos de autenticación. No dice que una pantalla de ajustes de OEM concreta exponga todos los campos, ni que un archivo de perfil exportado de otro producto vaya a importarse.

También significa que la pila integrada no le salvará si la puerta de enlace ejecuta un servicio que la plataforma no implementa. En ese caso necesita el cliente del fabricante que admite el operador, instalado y configurado como documenta el operador, en lugar de una solución improvisada sobre un protocolo que el teléfono no habla.

Pruebe en el orden en que está escrito el contrato

Valide una capa cada vez y deténgase en el primer fallo, porque las pruebas posteriores no tienen sentido hasta que pasen las anteriores.

Confianza. Si el cliente rechaza el certificado de la puerta de enlace, nada más importa. Confirme que la CA que le dieron firma el certificado que presenta la puerta de enlace y que el nombre de host que marcó aparece en él. Mantenga la validación activada; desactivarla convierte un problema de identidad en un riesgo de interceptación.

Autenticación. Unas credenciales rechazadas y una propuesta que no coincide producen errores distintos pero fallos de aspecto similar. El registro de la puerta de enlace es el desempate: dirá si la propuesta era aceptable antes de decir nada sobre el usuario.

Dirección y DNS. Confirme que el teléfono recibió una dirección del grupo documentado y después resuelva un nombre interno. Un túnel que sube con una dirección y sin resolutor parece conectado y se comporta como si nada funcionara.

Alcance. Pruebe un destino permitido por dirección y luego por nombre. Si la dirección funciona y el nombre no, vuelve a estar en DNS. Si no funciona ninguno, compare el prefijo que prueba con la lista permitida antes de tocar el cliente.

Modos de fallo y la reversión

Mantenga el perfil de trabajo anterior exportado y documentado antes de cambiar nada, incluido el alias de la CA y el grupo de direcciones. Entonces la reversión significa restaurar un perfil conocido, no reconstruirlo de memoria durante una interrupción.

Cuando funcione, anote las nueve respuestas de la recogida junto al perfil. El próximo teléfono, la próxima actualización del sistema y el próximo cambio de puerta de enlace pasan a ser una comparación con un documento en lugar de otra tarde de conjeturas.