OpenVPN remote-random : ordre mélangé, un seul tunnel

L’hypothèse est que l’ajout de remote-random transforme un profil en réserve tournante, de sorte que chaque connexion sorte d’une adresse différente. Ce que la directive fait réellement, c’est mélanger la liste des remotes une fois, lorsque le client commence à se connecter, puis les essayer dans ce nouvel ordre. Le tunnel qui finit par monter aboutit toujours à un seul point de terminaison et y reste pendant toute la durée de la session.

Cette différence compte à la fois pour les tests et pour les affirmations de confidentialité.

Ce que l’option change au moment de la connexion

Un profil client peut contenir plusieurs lignes remote, chacune avec son propre nom d’hôte et son port. Sans la directive, elles sont essayées dans l’ordre du fichier ; avec elle, la liste est permutée une fois au début de la session et la première adresse qui répond l’emporte. Les autres restent des solutions de repli pour cette tentative, et non des chemins parallèles. Un profil ne comportant qu’un seul remote ne donne rien à mélanger à la directive, et c’est le moyen le plus rapide de voir si elle peut avoir de l’importance.

Le manuel d’OpenVPN documente l’option comme influant sur l’ordre des tentatives de connexion, et c’est exactement la portée à attendre dans le comportement.

Une reconnexion démarre un nouveau cycle de sélection, si bien qu’une session ultérieure peut aboutir ailleurs. Le tunnel actif ne bouge pas tant qu’il est monté.

Mythe : chaque requête obtient un nouveau serveur

Une fois établi, le tunnel achemine tout le trafic de cette session vers le pair choisi. Il n’y a pas de resélection par requête, et la directive n’est pas un répartiteur de charge pour les connexions individuelles : elle mélange des candidats, elle ne répartit pas les paquets. Chaque application qui partage ce tunnel partage le même pair. Tout ce qu’un navigateur rapporte sur sa sortie appartient à la session, pas à une requête individuelle.

Si un test montre deux sorties différentes, cherchez deux sessions distinctes plutôt qu’une option astucieuse. Cette distinction explique aussi pourquoi un test de navigateur et un test de téléchargement peuvent diverger lorsqu’une reconnexion a eu lieu entre les deux.

À quoi sert remote-random-hostname

Une seconde directive au nom similaire change le nom d’hôte utilisé pour la résolution, pas l’ordre de la liste des remotes. Elle existe pour les déploiements où un nom se résout en plusieurs adresses via un DNS à tourniquet, et elle ne doit être utilisée que lorsque le service est conçu pour cela. Seule l’étape de résolution change ; l’ordre de la liste des candidats, non.

L’activer parce que les noms semblent liés est une erreur courante. Un certificat générique ou une configuration DNS qui n’attend pas le nom modifié échouera simplement à résoudre ou à valider.

Lisez le point de terminaison sélectionné dans le journal

Notez quel pair une session a réellement utilisé avant de tirer des conclusions. La sortie détaillée nomme l’adresse essayée, et le profil lui-même montre combien de candidats existent. Comparez ce nombre à l’adresse du journal avant d’accuser le mélange.

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

Pour une comparaison de performances, figez le point de terminaison en mettant les autres remotes en commentaire, afin que la variable testée soit le protocole ou le client plutôt que le chemin. Pour une question de confidentialité, évaluez l’identité du service et sa journalisation dans leur ensemble ; un premier choix mélangé n’efface pas les cookies, ne supprime pas la connexion au compte et ne rend pas deux opérateurs équivalents.

Gardez ensemble le matériel de confiance fourni et l’ensemble de points de terminaison pris en charge. Le remélange ne change que l’ordre dans lequel cet ensemble est essayé.