SSL VPN legado no IOS: pacote, perfil, gateway e sessão

Você encontra um instalador de cliente na flash do roteador e conclui que o SSL VPN está configurado. Isso é um componente entre quatro, e os três restantes decidem se alguém consegue conectar. No SSL VPN legado do IOS as peças são objetos distintos: o pacote de cliente do headend, um perfil de cliente opcional, o gateway WebVPN que encerra o TLS e o contexto mais a política de grupo que guardam a autenticação e as configurações de sessão. Perca uma delas e a falha parece a mesma vista de fora.

O exemplo de configuração de SSL VPN do IOS da Cisco, montado sobre IOS 15.3 com AnyConnect 3.1, é útil justamente porque mantém esses objetos separados. Leia-o como descrição daquela implementação mais antiga, não como recomendação para implantar aquelas versões.

Primeiro, o pacote: o que ele é e o que não é

O pacote do headend fornece software de cliente para uma plataforma. Ele não é o perfil nem o listener, e um arquivo parado na flash prova apenas que alguém enviou alguma coisa. Não prova que uma sessão algum dia o usou, que a plataforma corresponde ao dispositivo do usuário ou que o gateway o referencia.

Confirme o nome exato do arquivo, a plataforma a que ele se destina e onde a configuração aponta para ele. Um pacote Windows não diz nada sobre celulares, e um arquivo enviado que nenhum objeto do gateway menciona é armazenamento, não configuração. Um pacote que corresponde à plataforma mas nunca é associado ao serviço não será oferecido a nenhum usuário. Nem aquele cujo nome de arquivo difere do valor que a configuração espera.

Segundo, o perfil: configurações, não software

Um perfil de cliente opcional carrega configurações que um administrador prepara separadamente, como listas de servidores ou preferências do cliente. Confundi-lo com um instalador é comum porque ambos chegam como arquivos de nomes parecidos. Se a implantação espera um perfil, sua ausência muda o que o cliente faz depois de conectar, não se ele conecta.

Inventarie os dois artefatos e registre a qual deles o gateway realmente se refere. Essa única linha evita uma classe de chamados em que duas pessoas discutem arquivos diferentes.

Terceiro, o listener e a identidade TLS

O objeto do gateway define o endereço e a porta que o mundo externo alcança e o certificado apresentado durante o handshake. Um navegador que alcança a página do portal, um cliente que conclui a autenticação e uma aplicação que alcança um servidor privado são três observações distintas, e só a primeira é um teste de listener. Quando o handshake falha, nada adiante importa ainda, então verifique a cadeia de certificados e o nome antes de editar qualquer política.

Anote a identidade esperada em algum lugar. Um certificado renovado ou substituído é o motivo mais frequente de uma implantação que funcionava no mês passado parar de funcionar neste.

Quarto, o contexto e a política com seu template virtual

O contexto e a política de grupo ligam a autenticação ao comportamento da sessão: pool de endereços, rotas divididas, DNS e quais redes internas o usuário pode alcançar. O exemplo documentado liga seu contexto a um template virtual que fornece o comportamento de interface por sessão, e esses objetos do lado do servidor existem independentemente de qualquer coisa que o usuário baixe.

Quando um usuário autentica mas não alcança nada, a falha geralmente está aqui, não no cliente. Compare o pool, as rotas entregues ao cliente e a ACL que permite o tráfego adiante, e verifique-os contra o que o usuário relata, não contra o que o projeto pretendia.

Verifique em ordem e pare na primeira falha

Percorra os quatro componentes na ordem em que uma conexão os encontra: listener, autenticação, política e então o comportamento do cliente. Confirme o TLS com a identidade esperada, autentique uma conta sabidamente boa, leia o endereço e as rotas atribuídos na sessão e só depois compare a plataforma do cliente com o pacote. Parar na primeira falha mantém uma única variável em jogo, e é a diferença entre um conserto e um palpite.

Para um celular ou qualquer cliente fora daquele exemplo histórico de desktop, obtenha o contrato real de cliente e gateway suportados em vez de supor que o fluxo Windows se generaliza. Mudar um protocolo solicitado não transformará um perfil IKEv2 neste serviço SSL VPN, e instalar um pacote de desktop não demonstra nada sobre suporte móvel.