proto udp ou tcp-client : lequel votre serveur entend-il ?

Un profil qui fonctionnait le mois dernier expire désormais, et quelqu’un propose de remplacer proto udp par proto tcp-client. Parfois c’est le bon geste, et parfois cela produit un client qui se connecte à un port où rien n’écoute, parce que le serveur n’a jamais été configuré pour l’autre transport. La directive décrit comment votre extrémité parle ; elle ne peut pas créer d’écouteur à l’autre bout. Lisez le profil et le serveur ensemble avant de modifier l’un ou l’autre.

Lisez le transport utilisé par la connexion sélectionnée

Un profil peut contenir plusieurs entrées remote, et chacune peut nommer son propre transport. Le client les parcourt dans l’ordre, donc la ligne que vous voyez en premier n’est pas forcément celle qui s’applique.

Trouvez l’entrée réellement essayée, puis lisez son transport. L’ordre compte, car le client ne passe pas silencieusement à la suivante. Certaines compilations n’essaient l’entrée suivante qu’après un délai d’expiration, si bien qu’une alternative fonctionnelle en bas du fichier est atteinte quelques secondes plus tard que prévu. Surveillez dans le journal le point de terminaison essayé au lieu de supposer que la première ligne l’a emporté.

Si le fichier contient une ligne proto près du haut et plusieurs entrées remote en dessous, cette ligne est la valeur par défaut de tout remote qui ne la remplace pas. Une modification locale de la valeur par défaut ne fait rien pour une entrée remote qui nomme son propre transport.

grep -nE '^(remote|proto)\b' client.ovpn

UDP et TCP ne sont pas un réglage de vitesse

UDP envoie des datagrammes sans construire de flux ordonné, donc le trafic propre du tunnel n’est pas enveloppé dans un second transport fiable. TCP vous offre un chemin à travers les réseaux qui abandonnent ou bloquent UDP, au prix d’une retransmission imbriquée qui peut faire paraître pire une liaison sujette aux pertes.

C’est un compromis d’accessibilité, pas un classement universel. Le bon choix est celui que le réseau devant le client autorise. Un chemin qui abandonne UDP sur le port VPN ne négociera jamais, quelle que soit la qualité du profil. Testez le chemin, puis choisissez le transport.

Choisir entre eux sur la seule base d’une mesure est une erreur, car la réponse dépend de ce que le réseau devant vous permet. Un hôtel ou un proxy d’entreprise peut autoriser le TCP sortant sur 443 et rien d’autre, ce qui explique pourquoi les fournisseurs proposent cette variante. Cela reste une connexion OpenVPN sur ce port, pas une session HTTPS, même si le numéro de port est le familier.

Ce que tcp-client signifie réellement

La directive côté client nomme l’extrémité qui initie une connexion TCP. Le côté serveur utilise sa propre forme d’écoute, et copier le mot du client dans une configuration serveur produit un écouteur qui attend d’être appelé plutôt qu’un qui accepte.

Correspondre signifie que les deux extrémités s’accordent sur le transport, pas qu’elles partagent la même chaîne.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Demandez au serveur sur quoi il écoute avant de supposer que le profil est faux. Un écouteur UDP n’apparaît pas dans une liste de sockets TCP, et l’inverse est vrai aussi, donc regardez la vue propre au protocole plutôt qu’une vue générique.

Quand le profil s’importe mais ne se connecte jamais

Un profil importé qui expire immédiatement échoue généralement avant toute authentification. Le paquet part vers un port sans écouteur, ou le réseau l’abandonne silencieusement.

Testez le chemin de la manière la plus simple possible : connectez-vous au même hôte et au même port avec le transport que le profil revendique, depuis le même réseau que le client qui échoue.

Si un test UDP n’obtient rien et qu’un test TCP se connecte, le serveur propose l’autre transport et le profil est simplement obsolète. Si aucun ne répond, le problème se situe en amont du choix de transport et aucune modification du profil n’y remédiera. Distinguer ces deux cas prend une minute et évite une heure de débogage de certificats qui n’a jamais été pertinente.

Notez le transport qui fonctionne

Une fois qu’une combinaison fonctionne, notez-la avec le serveur, le port et le protocole, et précisez depuis quel réseau elle a été testée.

Sinon, la prochaine personne à rencontrer un délai d’expiration refera la même expérience dans l’autre sens, et peut-être modifiera un serveur qui était correct.

Si le fournisseur publie les deux variantes, conservez les deux fichiers et étiquetez-les selon le réseau auquel ils conviennent. Deux profils clairement nommés évitent le mélange accidentel d’un transport client avec un écouteur serveur qui n’a jamais été configuré pour lui.