OpenVPN et HTTPS sur le port 443 : à qui appartient l’écoute ?
TCP et UDP 443 sont des sockets distinctes. Partager un seul listener TCP exige un propriétaire, et le partage de port d’OpenVPN est un arrangement étroit, pas un tour de proxy.
Deux services peuvent tous deux répondre sur le port 443 sans jamais entrer en concurrence, car un listener est déterminé par le transport, l’adresse et le port ensemble, et non par le seul numéro. Placez un serveur web et OpenVPN sur une même machine, et la seule question qui mérite une première réponse est quel socket chaque processus demande au noyau. Écrivez cette liste avant de modifier une configuration, et la plupart des erreurs « adresse déjà utilisée » s’expliquent d’elles-mêmes. Tout ce qui suit la liste est un choix entre un listener UDP, un socket TCP partagé ou un frontal qui route selon le protocole.
Commencez par le socket que demande chaque processus
Un bind réussit ou échoue sur ce triplet, donc deux démons ne se heurtent que lorsque les trois parties coïncident. C’est pourquoi un site web sur TCP 443 coexiste indéfiniment avec un listener OpenVPN sur UDP 443, et pourquoi déplacer l’un d’eux vers une seconde adresse locale sur le même hôte met aussi fin au débat. Lisez les listeners vivants plutôt que les fichiers censés les créer, car un include obsolète ou un fichier unit oublié survit à la modification dont vous vous souvenez.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Exécutez ss -lntup en root et lisez chaque ligne qui mentionne 443, y compris les entrées IPv6. Un listener v6 générique accepte généralement aussi le trafic v4, et c’est ainsi qu’un listener oublié garde le port occupé après que vous avez changé le fichier que vous croyiez responsable. Si un nom de processus vous surprend, restreignez la sortie avec ss -lntup 'sport = :443' avant de toucher à quoi que ce soit.
Basculez le tunnel en UDP quand le réseau le permet
Un listener UDP contourne entièrement la collision et constitue souvent la réparation la plus courte, puisqu’aucun socket n’est partagé et qu’aucun produit supplémentaire n’entre dans le chemin. Ce n’est pas gratuit. Certains réseaux clients écartent UDP 443 sans envoyer de reset, si bien que le tunnel cesse de s’établir au lieu d’échouer au bind, et l’utilisateur signale un VPN hors service sans aucune erreur à lire. Un listener UDP survit aussi à un redémarrage de la couche web, ce qui compte sur une machine dont le site est souvent redéployé. Testez depuis le réseau où se trouvent les utilisateurs, car un shell sur le serveur ne prouve que le serveur s’atteint lui-même.
Changez le transport dans la configuration du serveur et dans le profil du client en même temps. Un profil qui demande encore TCP bouclera sur des reconnexions face à un listener uniquement UDP, et cela ressemble à une panne réseau jusqu’à ce que vous compariez les deux fichiers.
Laissez le processus VPN posséder TCP 443 et transmettez le reste
Community OpenVPN en mode serveur TCP lit les premiers octets d’une connexion entrante et transmet tout ce qui n’est pas son propre protocole à un backend HTTPS, ce à quoi sert la directive port-share. Le backend est un serveur web ordinaire avec TLS activé, nommé par hôte et port dans cette directive plutôt que par une URL.
port-share 10.0.0.5 8080
Sur une machine où le site détient une seconde adresse privée, cette ligne envoie le trafic non-VPN vers 10.0.0.5:8080, donc l’hôte virtuel HTTPS doit y être lié et le pare-feu doit autoriser le saut local. Le serveur web doit terminer TLS lui-même, car les octets qui arrivent sont la poignée de main d’origine du navigateur et rien entre les deux ne les a déchiffrés. Pointez la directive vers un listener HTTP simple et le navigateur reçoit une erreur de méthode invalide, qui se lit comme un site cassé plutôt que comme un backend mal placé. La directive n’existe qu’en mode serveur TCP, et un listener UDP n’a aucun flux à inspecter.
Comme le processus VPN accepte chaque connexion, l’application web voit la requête transmise arriver depuis l’une des adresses de l’hôte lui-même au lieu du visiteur. Tout ce qui a besoin de la vraie adresse du client dépend du support du protocole PROXY dans le backend ou d’un frontal qui l’ajoute. Déplacer le backend vers une autre adresse locale ne ramène pas l’adresse du visiteur ; cela change seulement laquelle des adresses de l’hôte le site enregistre. Notez cette limite dans les notes de déploiement avant qu’un rapport d’analytique ne pose la question.
Un proxy inverse est le mauvais outil ; un routeur de couche quatre non
Un proxy inverse HTTP termine TLS pour pouvoir lire les requêtes, ce qui signifie qu’il ne peut pas laisser passer un flux OpenVPN intact. Un routeur de couche quatre qui transmet selon le SNI ou l’inspection du premier paquet peut se placer devant les deux, à condition de ne pas terminer la session dont dépend le VPN. Les deux appareils se ressemblent sur un schéma et se comportent tout autrement au socket.
L’Access Server commercial fournit ses propres réglages de partage de port, et ceux-ci ne correspondent pas un pour un à la directive communautaire. Identifiez le produit et la version avant d’adapter un guide écrit pour l’autre. Un réglage copié et silencieusement ignoré est pire que pas de réglage, car la liste des listeners reste plausible ensuite.
Testez le site web et le tunnel comme deux chemins séparés
Chargez le site et connectez le tunnel, puis relisez la liste des listeners pour voir quel processus possède 443 maintenant. Une page qui se charge ne prouve rien sur le VPN, et un tunnel qui se connecte ne prouve rien sur le site, même si les deux utilisent le même numéro. Les trois commandes ci-dessous vérifient le socket partagé, le chemin web et le service VPN dans cet ordre.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Comparez l’adresse du client dans le journal d’accès du backend avec celle du journal du VPN au même instant. Si le site enregistre chaque visiteur comme l’hôte lui-même, la transmission fonctionne et la gestion de l’adresse non. Si les deux journaux restent muets, le frontal n’a jamais remis la connexion. Dans un cas comme dans l’autre, la liste des listeners tranche qui accepte le socket, et c’est le fait à confirmer avant de modifier un autre fichier.
Laissez cette carte des listeners à côté de la configuration pour que la prochaine personne qui touche à 443 sache quel processus accepte et où est allé l’autre protocole. Confirmez la propriété après le changement plutôt que de faire confiance à ce que la modification était censée faire.