Plusieurs remote OpenVPN : liste de bascule, pas d’agrégation de liens

Deux lignes remote dans un même profil ressemblent à une seconde voie ; ce sont une seconde tentative. Quand le premier endpoint cesse de répondre, le client passe au suivant et la session ne s’élargit pas. Nommez la liste failover tôt, sinon vous réglerez le mauvais bouton.

Ce qu’une liste de remote vous apporte

Traitez le profil comme un ensemble ordonné de tentatives, pas comme un réservoir de capacité. Chaque entrée a son tour pour monter le tunnel, et la session vit sur celle qui a répondu. Une liste plus longue améliore vos chances de connexion, pas la taille du tuyau.

La vraie agrégation est une autre machine. Répartir un flux sur plusieurs chemins demande un logiciel aux deux extrémités pour diviser et réassembler le trafic dans l’ordre.

Un fournisseur qui promet des tunnels plus rapides avec plus de serveurs vend ce second modèle, pas une liste plus longue. Si le client ne fait qu’essayer les endpoints à tour de rôle, cinq entrées changent vos chances et rien d’autre. Observez une panne : la session tombe et revient ailleurs, ce que le journal affiche comme un nouvel endpoint, jamais comme un tuyau plus large.

Les blocs qui gardent les réglages avec un seul endpoint

Une ligne remote simple porte une adresse, parfois un port et un protocole. Quand un endpoint a besoin d’un proxy, ou d’un transport que le reste du fichier n’utilise pas, mettez ces réglages dans un bloc de connexion qui les garde avec lui. Les blocs en ligne fonctionnent aussi dans un seul fichier .ovpn, et c’est ainsi que la plupart des profils sont livrés.

Tout ce qui est hors d’un bloc sert de valeur par défaut aux entrées qui ne le remplacent pas. C’est pourquoi un bloc construit et quatre remote simples se comportent d’une manière que la liste d’adresses ne peut pas expliquer.

Supprimer un bloc que vous ne reconnaissez pas n’est pas cosmétique. L’endpoint auquel il appartenait retombe sur les valeurs par défaut du fichier, qui peuvent être un transport différent de celui sur lequel il écoute. Retirez le mauvais emballage et une entrée échoue pendant que les autres fonctionnent, si bien que cela ressemble à un mauvais serveur plutôt qu’à un profil cassé. Lisez chaque remote avec son transport, son port et son proxy avant de modifier.

Ordre des nouvelles tentatives et coût de remote-random

L’ordre compte, car chaque entrée morte coûte du temps avant la tentative suivante. Placez l’endpoint voulu en premier et traitez le reste comme des solutions de repli classées.

remote-random mélange l’ordre de départ, ce qui répartit la charge entre serveurs équivalents et se retourne contre vous quand un endpoint est clairement principal. Quoi qu’il en soit, journalisez l’endpoint choisi par le client ; le nom du profil ne dit rien quand une connexion semble lente. Un grep de la ligne de lien dans un journal détaillé montre où la session a atterri.

Mélanger les opérateurs casse la déclaration de confiance

Un profil est aussi une affirmation d’identité : ces adresses sont le service que vous vouliez joindre, et le certificat épinglé lui appartient. Verser des serveurs publics gratuits dans ce fichier casse l’affirmation : leurs certificats et le vôtre décrivent des services différents. Le résultat habituel est un échec d’identité, ou des identifiants proposés à un hôte hors du réseau de votre fournisseur. Gardez les alternatives dans l’ensemble que votre opérateur distribue, avec des identifiants et du matériel de confiance concordants.

Si vous avez besoin d’endpoints de deux fournisseurs, c’est du routage, pas une modification de profil. Réglez cela au-dessus du tunnel, où vous pouvez dire quel trafic prend quel chemin.

Tester chaque entrée au lieu de supposer

Après une mise à jour de profil approuvée, connectez-vous délibérément à chaque endpoint requis et confirmez quel transport est monté. Une exécution détaillée le rend visible. Lancez openvpn --config office.ovpn --verb 4 et lisez la ligne de lien pour l’adresse attendue. Vérifiez ensuite les ressources derrière le tunnel ; une entrée peut terminer la poignée de main et malgré tout ne vous router nulle part.

Le failover a besoin de son propre test plutôt que d’un espoir. Bloquez le premier endpoint en laboratoire, lancez le client et mesurez le temps qu’il met à passer au suivant. Une longue liste derrière une première entrée lente est pire qu’une courte qui démarre bien.

Revérifiez la liste dès que l’opérateur la modifie. Un ensemble importé n’est utile que tant que ses entrées existent et parlent le transport que décrivent vos blocs. Le manuel OpenVPN 2.6 couvre ici les directives remote, connection et random-order, et c’est la version à consulter quand la syntaxe fait doute.