VPN Android vers Cisco IOS : le contrat à obtenir d'abord

Le téléphone doit joindre une passerelle Cisco. Quelqu'un a déjà nommé le client à installer. C'est le mauvais bout du processus, et c'est pourquoi le tunnel échoue après une heure à ressaisir des identifiants.

Ce qu'il vous faut d'abord, c'est un contrat de connexion : protocole, authentification, identité, matériel de confiance, attribution d'adresses et routage, rédigé par celui qui exploite la passerelle.

Obtenez-le par écrit et le choix du client devient une simple recherche. Omettez-le et chaque panne ressemble à un mauvais mot de passe.

Faites la collecte avant d'installer quoi que ce soit

Envoyez au propriétaire de la passerelle une liste et demandez des réponses, pas un nom de produit. Neuf points couvrent complètement un profil d'accès distant :

1. Le nom d'hôte ou l'adresse de la passerelle que le client doit appeler, et si elle est joignable de l'extérieur.
2. Le protocole et la version : IKEv2, une autre génération d'IPsec ou un service basé sur TLS.
3. L'identité de pair attendue par la passerelle, et ce qu'elle présente en retour.
4. Le matériel de confiance : quelle CA signe le certificat de la passerelle, ou si une clé pré-partagée est utilisée.
5. L'authentification utilisateur : certificat, nom d'utilisateur et mot de passe EAP, ou clé pré-partagée.
6. Le pool d'adresses dans lequel le client atterrit, avec masque et passerelle.
7. Les serveurs DNS à utiliser dans le tunnel, et si le client doit les accepter.
8. Les préfixes de destination autorisés, et si le trafic hors de ceux-ci doit être bloqué.
9. Les versions de client prises en charge et les versions du système d'exploitation du téléphone, plus toute exigence d'enrôlement.

Deux de ces points causent la plupart des pannes évitables. Sans le matériel de confiance, vous ne pouvez pas valider la passerelle, si bien qu'un client correct semble défaillant. Sans les préfixes autorisés, vous ne pouvez pas distinguer une restriction de routage d'un problème de service.

Le nom du fournisseur n'est pas un protocole

Cisco IOS et IOS XE offrent plusieurs dispositions d'accès distant, et elles ne partagent pas un même format de transmission. IKEv2 avec un profil de type FlexVPN n'est pas le même service qu'une configuration IKEv1 plus ancienne, et un service client basé sur TLS est encore un autre produit, souvent sur une autre plateforme dans le même environnement.

Un client dont le nom cite le fournisseur du routeur ne prouve donc rien. Il peut bien implémenter l'un de ces services et aucun des autres. Demandez quel service est configuré, puis vérifiez que la documentation du client nomme ce service comme pris en charge.

La documentation IKEv2 de Cisco sépare la proposition, la politique, le profil et le porte-clés comme des objets distincts. Cette structure est utile quand vous lisez une configuration que quelqu'un vous colle : elle vous dit quel objet détient les réglages qui comptent pour un téléphone distant, au lieu de traiter tout le fichier comme un bloc.

Ce que couvre la pile intégrée d'Android

Android expose un profil IKEv2/IPsec de plateforme via Ikev2VpnProfile, avec des types d'authentification distincts pour une clé pré-partagée, un certificat RSA et un nom d'utilisateur et mot de passe EAP. La référence Ikev2VpnProfile fait autorité sur ce que le constructeur accepte, y compris le nom d'hôte de la passerelle et la CA racine du serveur utilisée pour le valider.

Cette API est une déclaration de capacité, pas une promesse de compatibilité. Elle dit que la plateforme sait faire IKEv2 avec ces types d'authentification. Elle ne dit pas qu'un écran de réglages OEM donné expose chaque champ, ni qu'un fichier de profil exporté d'un autre produit sera importé.

Cela signifie aussi que la pile intégrée ne vous sauvera pas si la passerelle exploite un service que la plateforme n'implémente pas. Dans ce cas, il vous faut le client du fournisseur pris en charge par l'opérateur, installé et configuré comme l'opérateur le documente, plutôt qu'un contournement bâti sur un protocole que le téléphone ne parle pas.

Testez dans l'ordre où le contrat est écrit

Validez une couche à la fois et arrêtez-vous au premier échec, car les tests suivants n'ont pas de sens tant que les précédents ne passent pas.

Confiance. Si le client rejette le certificat de la passerelle, rien d'autre n'importe. Confirmez que la CA qui vous a été donnée signe le certificat présenté par la passerelle, et que le nom d'hôte que vous avez appelé y figure. Laissez la validation active ; la désactiver transforme un problème d'identité en risque d'interception.

Authentification. Des identifiants rejetés et une proposition incompatible produisent des erreurs différentes mais des pannes d'apparence similaire. Le journal de la passerelle tranche : il dira si la proposition était acceptable avant de dire quoi que ce soit sur l'utilisateur.

Adresse et DNS. Confirmez que le téléphone a reçu une adresse du pool documenté, puis résolvez un nom interne. Un tunnel qui monte avec une adresse et sans résolveur paraît connecté et se comporte comme si rien ne fonctionnait.

Accessibilité. Testez une destination autorisée par adresse, puis par nom. Si l'adresse fonctionne et pas le nom, vous êtes de retour au DNS. Si ni l'un ni l'autre ne fonctionne, comparez le préfixe testé à la liste autorisée avant de toucher au client.

Modes de défaillance et le retour arrière

Gardez le profil de travail précédent exporté et documenté avant de changer quoi que ce soit, y compris l'alias de la CA et le pool d'adresses. Le retour arrière consiste alors à restaurer un profil connu, non à le reconstruire de mémoire pendant une interruption.

Quand cela fonctionne, notez les neuf réponses de la collecte à côté du profil. Le prochain téléphone, la prochaine mise à jour du système et le prochain changement de passerelle deviennent une comparaison avec un document au lieu d'un autre après-midi de suppositions.