OpenVPN derrière stunnel : transmettez l'enveloppe, pas le port 1194

Placez une enveloppe TLS devant OpenVPN et le déploiement gagne une seconde écoute, dont une seule devrait jamais faire face à internet. Quand le tunnel fonctionne depuis la même machine et échoue depuis l'extérieur, la redirection vise généralement la mauvaise des deux. Ce qui doit s'aligner est une chaîne : la règle publique atteint l'enveloppe, et la connexion backend propre à l'enveloppe atteint la vraie socket VPN. Quatre sauts portent cette chaîne, et n'importe lequel peut terminer l'enquête trop tôt.

Deux sockets, deux propriétaires, dont une publique

L'enveloppe termine TLS pour la connexion extérieure et transmet le flux d'octets déchiffré à une écoute OpenVPN TCP simple. Ce sont des sockets distinctes avec des fichiers de configuration distincts, donc modifier l'une laisse l'autre intacte et toujours apparemment saine. Cela signifie aussi que les deux peuvent diverger dès que l'une change sans l'autre.

Travailler depuis la machine elle-même ne prouve donc que très peu de choses sur le chemin public. Une connexion directe au port natif saute l'enveloppe, une connexion à l'enveloppe sur son adresse LAN saute la traduction, et seule la disposition complète côté client exerce ce que fait un utilisateur extérieur. Les noms doivent aussi être lus avec soin, car localhost désigne l'hôte qui exécute ce composant précis et non l'hôte sur lequel vous tapez par hasard. Gardez cette distinction dans vos notes, car un test enregistré sans le saut qu'il couvrait invite à comparer deux choses différentes.

Où arrive réellement la redirection

La chaîne se retient plus facilement comme quatre sauts que comme trois numéros de port, car le même numéro peut signifier des choses différentes à chaque extrémité. Lisez le tableau ligne par ligne : chaque ligne est une socket qui doit accepter une connexion puis ouvrir la suivante. Quand une ligne vise le mauvais pair, le symptôme de la dernière colonne est ce que l'utilisateur signale.

Une règle qui vise le port VPN natif au lieu de l'enveloppe saute entièrement la terminaison TLS, ce qui est la version la plus courante de cette erreur : le client ouvre une poignée de main avec une écoute qui attend le cadrage OpenVPN, si bien que la connexion peut s'ouvrir puis se bloquer. Vérifiez le port traduit dans le fichier de configuration de l'enveloppe plutôt que de mémoire, car la prochaine personne à modifier ce fichier a peut-être choisi un autre numéro. Les deux commandes ci-dessous montrent les deux faces de cette question à la fois.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

L'adresse de liaison qui vous refuse

Une ligne accept liée à 127.0.0.1 ne répond qu'à l'hôte lui-même, donc une redirection qui arrive sur l'adresse LAN ne peut pas se connecter et le client voit un refus qui ressemble à un problème de filtre de paquets. Regardez la socket avant de toucher au pare-feu, car la socket est la réponse la moins coûteuse. Soit vous liez l'enveloppe à l'interface visée par la redirection, soit vous la gardez sur loopback et faites en sorte que la redirection atteigne loopback par quelque chose qui fonctionne vraiment. Ce sont deux conceptions, et chacune a besoin de sa propre règle.

Les mélanger, c'est ainsi qu'une enveloppe fonctionnelle devient inaccessible depuis l'extérieur alors que chaque fichier semble correct. La vérification ci-dessous tient en une commande, et elle répond à une question qu'une revue des règles du pare-feu ne peut pas. Si la sortie montre une adresse loopback alors que la redirection vise l'adresse LAN, la correction relève de la ligne accept et non du filtre de paquets.

ss -lntp '( sport = :8443 )'

Ce que le test local a réellement prouvé

Un succès enregistré sans le saut qu'il couvrait n'est pas une preuve sur les autres sauts. Notez quelle adresse le test a utilisée et quel processus a répondu. Répétez ensuite depuis l'extérieur du réseau plutôt que depuis un téléphone sur le même Wi-Fi, car le comportement d'épingle varie selon les routeurs et une connexion qui n'a jamais quitté le LAN peut satisfaire un client sans que la redirection soit du tout impliquée. Seule cette seconde tentative exerce le chemin qu'emprunte un inconnu.

Quand la tentative échoue, suivez une seule connexion dans les deux journaux : les lignes d'acceptation et de connexion de l'enveloppe, puis le journal de session du démon VPN. La première frontière qui n'enregistre rien est l'endroit du prochain changement. Une fois qu'OpenVPN compare les options de pair, jugez ces messages selon les règles de cette implémentation. Un avertissement d'incohérence de link-mtu n'est pas automatiquement fatal, épingler link-mtu à 1500 ne prouve pas que la fragmentation s'est arrêtée, et la négociation de chiffrement relève de la configuration interne d'OpenVPN et non de la redirection du routeur.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Ces sondes couvrent la socket backend et le journal de l'enveloppe, ce qui sépare un backend refusé d'une poignée de main rejetée. Exécutez-les pendant qu'une seule tentative est en cours et non après. Les horodatages d'une seule tentative sont ce qui rend la comparaison fiable.

Deux identités, deux ordres de défaillance

Le certificat externe appartient à l'enveloppe et l'identité interne appartient à OpenVPN, et ils peuvent venir d'autorités différentes. Désactiver l'une ou l'autre vérification pour qu'un chemin paraisse sain échange une protection réelle contre un résultat cosmétique. Conservez les deux vérifications et déboguez-les dans l'ordre, car la séquence des messages nomme la couche : un problème de certificat de l'enveloppe apparaît avant toute négociation d'option VPN, tandis qu'une défaillance d'identité interne n'apparaît qu'une fois le flux établi.

Le manuel de stunnel définit précisément accept, connect et le mode client, et ces sections répondent à la question de la socket plus vite que deviner. Quand vous ne pouvez toujours pas dire quelle couche a répondu, lisez le certificat que présente le port public avec la commande ci-dessous. Un certificat d'enveloppe dans la sortie signifie que la redirection a atteint l'enveloppe, et le silence ou une erreur de protocole signifie que non. Cette seule distinction fait gagner plus de temps que toute autre vérification ici.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer