Un port OpenVPN, trois services : pourquoi les ports internes comptent

Une session SSH, une application web et une résolution de nom peuvent partager une seule connexion VPN sans se disputer les ports. Le client établit un flux chiffré unique vers la passerelle, et chaque conversation applicative voyage à l'intérieur. À l'extérieur, seuls le transport et le port propres au tunnel sont visibles. À l'intérieur, chaque service conserve son propre port et a toujours besoin de sa propre autorisation.

Ce que transporte le flux extérieur, et ce qu'il cache

Le client enveloppe chaque paquet dans le transport du tunnel avant qu'il ne quitte la machine. Ce flux extérieur possède un unique port de destination, fixé lors de la configuration du VPN. À l'intérieur de l'enveloppe, chaque paquet d'origine conserve l'adresse et le port du service qu'il vise. La passerelle retire l'enveloppe et route selon l'en-tête interne, si bien que la destination voit un client ordinaire arriver depuis le réseau.

Une capture sur l'interface WAN montre donc une conversation, pas trois. Les ports internes n'apparaissent qu'après la décapsulation. C'est pourquoi une seule ouverture de pare-feu peut transporter SSH, HTTPS et DNS en même temps.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

La documentation TUN/TAP couvre la transmission par laquelle un périphérique TUN routé fait passer les paquets IP entre le noyau et un processus en espace utilisateur. C'est cette transmission qui rend l'en-tête interne visible pour le code de routage et de pare-feu de la passerelle. Elle explique aussi pourquoi le port extérieur ne dit rien sur les services autorisés.

Le transfert NAT appartient à l'écouteur, pas aux applications

Une passerelle auto-hébergée derrière un NAT IPv4 a besoin d'une seule traduction entrante : l'adresse et le port publics mappés sur l'écouteur VPN. Aucune règle n'est requise pour SSH, HTTPS ou DNS simplement parce que les utilisateurs du tunnel les atteignent. Publier ces ports exposerait des services que le tunnel protège déjà. La règle de transfert décrit l'accessibilité de l'écouteur, pas une autorisation pour quoi que ce soit à l'intérieur.

L'inverse est vrai aussi. Ouvrir le port du tunnel n'expose rien d'autre, donc un service joignable uniquement par le tunnel garde sa surface publique fermée. Cette séparation est généralement la raison même de garder le service privé.

C'est la politique interne qui décide réellement de l'accès

Le chiffrement protège le chemin ; il n'autorise pas une destination. Les routes du client choisissent quels préfixes entrent dans le tunnel, la politique de transfert de la passerelle décide si les paquets peuvent en sortir, et le pare-feu de la destination plus la connexion décident si le service répond. Le DNS est le cas le plus clair : transporter des requêtes ne fait pas qu'un résolveur les accepte depuis votre pool de clients. Chaque couche peut dire non indépendamment.

Testez chaque service séparément à travers le tunnel. Une résolution réussie ne dit rien sur le port web, et une requête web réussie ne dit rien sur SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Quand le tunnel est actif et que tout échoue, lisez d'abord la table de routage du client. Quand un service échoue alors que les autres fonctionnent, la défaillance se situe à cette destination. Ces deux observations désignent des responsables différents, et les mélanger fait perdre du temps.

WireGuard trace la même ligne

WireGuard nomme son écouteur extérieur avec ListenPort, et une application interne utilise toujours le port de service dont elle a besoin. AllowedIPs est un ensemble de préfixes routés, pas une liste de ports de service autorisés. Le lire comme une liste d'autorisation de ports produit des règles qui ne correspondent pas à ce que fait le tunnel. Le nommage diffère ; le découpage en couches non.

Autorisez le service dans la politique d'entrée locale lorsqu'il s'exécute sur le point de terminaison lui-même, ou dans la politique de transfert lorsqu'il se trouve derrière ce point de terminaison. La distinction décide quel jeu de règles voit le paquet.

La forme générale est un transport extérieur avec de nombreuses conversations internes. Les produits qui ont besoin de plusieurs échanges extérieurs, ou d'un autre protocole IP, rappellent que le schéma à port public unique décrit cette conception et non tout VPN.