OpenVPN ou IKEv2 : quatre vérifications avant de choisir un protocole

Le choix entre OpenVPN et IKEv2 est généralement débattu comme une question de protocole, et ce cadrage gâche la décision. Ce qui la tranche, c’est de savoir si votre serveur et vos appareils prennent en charge le même profil complet, et si ce profil survit à la façon dont vous passez d’un réseau à l’autre. Les deux piles ne se traduisent pas l’une en l’autre : un fichier OVPN n’est pas un profil IKEv2 avec une autre syntaxe. Quatre vérifications, menées dans l’ordre, répondent à la question plus vite que n’importe quel tableau de fonctionnalités.

Un client manquant met fin au débat

Windows et macOS fournissent un client IKEv2, donc un profil IKEv2 n’y coûte rien de plus à déployer et hérite des options de provisionnement que le système d’exploitation expose déjà. OpenVPN sur les mêmes machines signifie un client tiers à installer, à mettre à jour et à soutenir, et ce client doit accepter chaque option que le profil utilise. Comptez les plateformes que vous devez couvrir avant de comparer quoi que ce soit d’autre, car une plateforme sans client fonctionnel n’est pas un point de comparaison du tout.

Sous Windows, une commande liste les profils qui existent déjà et indique de quel type est chacun. Le nom qu’elle affiche est celui que les vérifications suivantes utilisent.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

L’invitation à installer un client est la vraie réponse pour la colonne OpenVPN sur ces plateformes, et c’est une tâche de déploiement et non une limite du protocole. Aucun des deux montages n’élimine les contrôles de confiance, la vérification d’identité ni la maintenance. Demandez comment les profils sont distribués, comment les identifiants sont renouvelés et comment un appareil perdu est retiré avant de vous engager. Une installation simple peut encore cacher un processus de récupération que personne ne veut exécuter le week-end.

La mobilité est un réglage commun, pas une promesse du protocole

IKEv2 peut utiliser MOBIKE lorsque les deux extrémités le prennent en charge et l’activent, ce qui permet à un client de garder son tunnel pendant que son adresse change. RFC 4555 définit l’extension, et la formulation conditionnelle compte : un serveur qui ignore la capacité renégocie à la place. Le résultat peut sembler identique lors d’un transfert de fichier et très différent lors d’un appel en direct.

Testez la transition qui vous importe vraiment, avec quelque chose en marche que vous pouvez observer. Gardez ping -t <internal-host> en fonctionnement sous Windows, ou le simple ping ailleurs, puis passez du Wi-Fi au cellulaire et guettez les trous. Une défaillance MOBIKE apparaît dans le journal du client comme une réauthentification complète plutôt qu’une mise à jour silencieuse de l’adresse. Ce que vous mesurez, c’est si le tunnel survit au changement, pas si le protocole annonce la prise en charge.

Les clients OpenVPN se reconnectent selon le comportement de leur plateforme et les minuteries du profil, donc le même test peut produire une interruption de forme différente. Comparez l’événement qui compte pour vos utilisateurs, pas l’étiquette sur le protocole.

Les identifiants appartiennent au service, pas à la pile

Les certificats et les autres modes de connexion appartiennent au service qui termine la connexion. Une demande de mot de passe dans un client ne dit rien de la compatibilité avec un autre, et un profil qui fonctionne face à une autre passerelle ne dit rien de celle-ci. Gardez les règles d’identité du serveur intactes pendant que vous comparez les deux piles. Changer de protocole avant d’avoir identifié la panne produit généralement un second profil incompatible.

Inspectez l’identifiant que le client présentera avant d’accuser l’un ou l’autre protocole, car un certificat expiré ou mal émis échoue de la même manière dans les deux cas. La sortie ci-dessous montre le sujet, l’émetteur et les dates de validité sans lire la clé privée.

openssl x509 -in client.crt -noout -subject -issuer -dates

Pour une connexion d’entreprise, utilisez la méthode que l’entreprise publie et cessez de traiter la comparaison comme une expérience. Si vous comparez les deux pour vous-même, vérifiez d’abord si les deux options aboutissent à une seule passerelle, car ce seul détail décide de la part de votre résultat qui concerne le protocole. Un refus qui nomme l’identifiant est un problème d’identifiant, et aucun changement de protocole ne le réparera.

Vérifiez ce que le tunnel route réellement

Après connexion, confirmez que la route dont vous avez besoin existe et que les noms se résolvent. Un profil prévu pour des ressources internes peut laisser la navigation ordinaire sur le chemin local par conception, et c’est une décision de politique et non une panne. L’important est de savoir si les destinations que votre équipe utilise sont joignables via le tunnel.

Deux commandes couvrent la route et la recherche de noms sous Windows. Les équivalents sous Linux sont ip route show default et resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Un tunnel qui monte et ne route rien d’utile est un résultat courant lorsqu’un profil a été copié entre services, et un test de connectivité générique ne le montrera pas parce que l’interface est active. Testez la ressource que vos utilisateurs ouvrent en premier, pas une adresse publique que n’importe quel chemin peut atteindre. Si le nom se résout vers une adresse publique alors que la route pointe dans le tunnel, la réponse DNS et la route relèvent de décisions différentes et les deux doivent être corrigées.

Pesez la maintenance après les vérifications

Aucun des deux protocoles n’est plus maintenable dans l’absolu. La maintenance dépend de qui exploite la passerelle, de la façon dont les profils atteignent les appareils et de la rapidité avec laquelle un appareil perdu perd l’accès. Un client simple en extrémité peut se trouver devant un serveur plus difficile à exploiter, et l’inverse arrive aussi. Demandez lequel des deux votre équipe peut maintenir en fonctionnement après le départ de la personne qui l’a construit.

Choisissez la connexion prise en charge qui couvre le travail, puis testez-la contre l’accès dont vous avez réellement besoin plutôt que contre une liste de fonctionnalités. Notez sur quelle passerelle chaque option aboutit, car deux passerelles différentes font de la comparaison une question de routes autant que de protocoles. Répétez les quatre vérifications sur l’appareil que vous porterez réellement, et gardez le profil qui y passe.