VPN Android para Cisco IOS: o contrato a obter primeiro

O telefone tem de chegar a um gateway Cisco. Alguém já indicou o cliente a instalar. Esse é o extremo errado do processo, e é por isso que o túnel falha depois de uma hora a reescrever credenciais.

O que precisa primeiro é de um contrato de ligação: protocolo, autenticação, identidade, material de confiança, atribuição de endereços e encaminhamento, escrito por quem opera o gateway.

Obtenha-o por escrito e a escolha do cliente passa a ser uma consulta. Ignore-o e cada falha parece uma palavra-passe errada.

Faça o levantamento antes de instalar seja o que for

Envie ao responsável do gateway uma lista e peça respostas, não um nome de produto. Nove pontos cobrem por completo um perfil de acesso remoto:

1. O nome de anfitrião ou o endereço do gateway que o cliente deve marcar, e se é acessível do exterior.
2. O protocolo e a versão: IKEv2, outra geração de IPsec ou um serviço baseado em TLS.
3. A identidade de par que o gateway espera, e o que ele próprio apresenta em troca.
4. Material de confiança: que CA assina o certificado do gateway, ou se é usada uma chave pré-partilhada.
5. Autenticação do utilizador: certificado, nome de utilizador e palavra-passe EAP, ou chave pré-partilhada.
6. O conjunto de endereços onde o cliente fica, com máscara e gateway.
7. Os servidores DNS a usar dentro do túnel, e se o cliente os tem de aceitar.
8. Os prefixos de destino permitidos, e se o tráfego fora deles deve ser bloqueado.
9. As versões de cliente suportadas e as versões do sistema operativo do telefone, além de qualquer requisito de registo.

Dois desses pontos causam a maioria das falhas evitáveis. Sem o material de confiança não consegue validar o gateway, pelo que um cliente correto parece avariado. Sem os prefixos permitidos não distingue uma restrição de encaminhamento de um problema de serviço.

O nome do fornecedor não é um protocolo

O Cisco IOS e o IOS XE oferecem várias disposições de acesso remoto, e não partilham um único formato de transmissão. IKEv2 com um perfil ao estilo FlexVPN não é o mesmo serviço que uma configuração IKEv1 mais antiga, e um serviço de cliente baseado em TLS é ainda outro produto, muitas vezes noutra plataforma no mesmo ambiente.

Um cliente cujo nome menciona o fornecedor do router não prova nada. Pode implementar bem um desses serviços e nenhum dos outros. Pergunte qual serviço está configurado e depois confirme se a documentação do cliente refere esse serviço como suportado.

A própria documentação de IKEv2 da Cisco separa a proposta, a política, o perfil e o porta-chaves como objetos distintos. Essa estrutura é útil quando lê uma configuração que alguém lhe cola: diz-lhe qual objeto guarda as definições que importam para um telefone remoto, em vez de tratar o ficheiro inteiro como um bloco.

O que a pilha integrada do Android cobre

O Android expõe um perfil IKEv2/IPsec de plataforma através de Ikev2VpnProfile, com tipos de autenticação separados para chave pré-partilhada, certificado RSA e nome de utilizador e palavra-passe EAP. A referência de Ikev2VpnProfile é a autoridade sobre o que o construtor aceita, incluindo o nome de anfitrião do gateway e a CA raiz do servidor usada para o validar.

Essa API é uma declaração de capacidade, não uma promessa de compatibilidade. Diz que a plataforma consegue fazer IKEv2 com esses tipos de autenticação. Não diz que um determinado ecrã de definições de OEM expõe todos os campos, nem que um ficheiro de perfil exportado de outro produto será importado.

Também significa que a pilha integrada não o salva se o gateway executar um serviço que a plataforma não implementa. Nesse caso precisa do cliente do fornecedor que o operador suporta, instalado e configurado como o operador documenta, em vez de uma solução improvisada sobre um protocolo que o telefone não fala.

Teste pela ordem em que o contrato está escrito

Valide uma camada de cada vez e pare na primeira falha, porque os testes seguintes não fazem sentido enquanto os anteriores não passarem.

Confiança. Se o cliente rejeitar o certificado do gateway, nada mais importa. Confirme que a CA que lhe deram assina o certificado que o gateway apresenta e que o nome de anfitrião que marcou aparece nele. Mantenha a validação ativa; desativá-la transforma um problema de identidade num risco de interceção.

Autenticação. Credenciais rejeitadas e uma proposta que não corresponde produzem erros diferentes mas falhas de aspeto semelhante. O registo do gateway é o desempate: dirá se a proposta era aceitável antes de dizer algo sobre o utilizador.

Endereço e DNS. Confirme que o telefone recebeu um endereço do conjunto documentado e depois resolva um nome interno. Um túnel que sobe com endereço e sem resolvedor parece ligado e comporta-se como se nada funcionasse.

Alcance. Teste um destino permitido por endereço e depois por nome. Se o endereço funcionar e o nome não, voltou ao DNS. Se nenhum funcionar, compare o prefixo que está a testar com a lista permitida antes de tocar no cliente.

Modos de falha e o retrocesso

Mantenha o perfil de trabalho anterior exportado e documentado antes de mudar seja o que for, incluindo o alias da CA e o conjunto de endereços. O retrocesso passa a significar restaurar um perfil conhecido, não reconstruí-lo de memória durante uma interrupção.

Quando funcionar, registe as nove respostas do levantamento junto ao perfil. O próximo telefone, a próxima atualização do sistema e a próxima alteração do gateway passam a ser uma comparação com um documento em vez de mais uma tarde de suposições.