VPN de Android a Cisco IOS: o contrato que hai que obter primeiro

O teléfono ten que chegar a unha pasarela Cisco. Alguén xa nomeou o cliente que hai que instalar. Ese é o extremo equivocado do proceso, e por iso o túnel falla tras unha hora de volver teclear credenciais.

O que necesita primeiro é un contrato de conexión: protocolo, autenticación, identidade, material de confianza, asignación de enderezos e encamiñamento, escrito por quen xestiona a pasarela.

Consígao por escrito e a elección do cliente convértese nunha consulta. Omíteo e cada fallo parecerá un contrasinal incorrecto.

Faga a recollida antes de instalar nada

Enhvíe ao responsable da pasarela unha lista e pida respostas, non un nome de produto. Nove puntos cobren por completo un perfil de acceso remoto:

1. O nome de host ou o enderezo da pasarela á que debe marcar o cliente, e se é accesible desde fóra.
2. O protocolo e a versión: IKEv2, outra xeración de IPsec ou un servizo baseado en TLS.
3. A identidade de par que espera a pasarela e o que ela mesma presenta.
4. Material de confianza: que CA asina o certificado da pasarela ou se se usa unha clave precompartida.
5. Autenticación de usuario: certificado, nome de usuario e contrasinal EAP ou unha clave precompartida.
6. O grupo de enderezos no que cae o cliente, con máscara e pasarela.
7. Os servidores DNS que se usarán dentro do túnel e se o cliente debe aceptalos.
8. Os prefixos de destino permitidos e se o tráfico fóra deles debe bloquearse.
9. As versións de cliente admitidas e as versións do sistema operativo do teléfono, ademais de calquera requisito de alta.

Dous deses puntos causan a maioría dos fallos evitables. Sen o material de confianza non pode validar a pasarela, así que un cliente correcto parece avariado. Sen os prefixos permitidos non pode distinguir unha restrición de encamiñamento dun problema de servizo.

O nome do fabricante non é un protocolo

Cisco IOS e IOS XE ofrecen varias disposicións de acceso remoto e non comparten un mesmo formato de transmisión. IKEv2 cun perfil estilo FlexVPN non é o mesmo servizo que unha configuración IKEv1 máis antiga, e un servizo de cliente baseado en TLS é aínda outro produto, a miúdo noutra plataforma dentro do mesmo contorno.

Por tanto, un cliente cuxo nome menciona o fabricante do router non demostra nada. Pode implementar ben un deses servizos e ningún dos demais. Pregunte que servizo está configurado e despois comprobe se a documentación do cliente nomea ese servizo como admitido.

A propia documentación de IKEv2 de Cisco separa a proposta, a política, o perfil e o chaveiro como obxectos distintos. Esa estrutura resulta útil cando le unha configuración que alguén lle pega: dille que obxecto contén os axustes que importan para un teléfono remoto, en lugar de tratar todo o ficheiro como un só bloque.

Que cobre a pila integrada de Android

Android expón un perfil IKEv2/IPsec de plataforma mediante Ikev2VpnProfile, con tipos de autenticación separados para unha clave precompartida, un certificado RSA e nome de usuario e contrasinal EAP. A referencia de Ikev2VpnProfile é a autoridade sobre o que acepta o construtor, incluído o nome de host da pasarela e a CA raíz do servidor usada para validalo.

Esa API é unha declaración de capacidade, non unha promesa de compatibilidade. Di que a plataforma pode facer IKEv2 con eses tipos de autenticación. Non di que unha pantalla de axustes de OEM concreta expoña todos os campos, nin que un ficheiro de perfil exportado doutro produto vaia importarse.

Tamén significa que a pila integrada non o salvará se a pasarela executa un servizo que a plataforma non implementa. Nese caso necesita o cliente do fabricante que admite o operador, instalado e configurado como documenta o operador, en lugar dunha solución improvisada sobre un protocolo que o teléfono non fala.

Probe na orde na que está escrito o contrato

Valide unha capa cada vez e detéñase no primeiro fallo, porque as probas posteriores non teñen sentido ata que pasen as anteriores.

Confianza. Se o cliente rexeita o certificado da pasarela, nada máis importa. Confirme que a CA que lle deron asina o certificado que presenta a pasarela e que o nome de host que marcou aparece nel. Manteña a validación activada; desactivala converte un problema de identidade nun risco de interceptación.

Autenticación. Unhas credenciais rexeitadas e unha proposta que non coincide producen erros distintos pero fallos de aspecto similar. O rexistro da pasarela é o desempate: dirá se a proposta era aceptable antes de dicir nada sobre o usuario.

Enderezo e DNS. Confirme que o teléfono recibiu un enderezo do grupo documentado e despois resolva un nome interno. Un túnel que sobe cun enderezo e sen resolvedor parece conectado e compórtase coma se nada funcionase.

Alcance. Probe un destino permitido por enderezo e logo por nome. Se o enderezo funciona e o nome non, volve estar en DNS. Se non funciona ningún, compare o prefixo que proba coa lista permitida antes de tocar o cliente.

Modos de fallo e a reversión

Manteña o perfil de traballo anterior exportado e documentado antes de cambiar nada, incluído o alias da CA e o grupo de enderezos. Entón a reversión significa restaurar un perfil coñecido, non reconstruílo de memoria durante unha interrupción.

Cando funcione, anote as nove respostas da recollida xunto ao perfil. O próximo teléfono, a próxima actualización do sistema e o próximo cambio de pasarela pasan a ser unha comparación cun documento en lugar doutra tarde de conxecturas.