Redirection de port ou accès VPN : où va réellement le paquet

Deux conceptions, une application HTTPS, et le paquet emprunte un chemin différent dans chacune. Une redirection de port change où le paquet est livré et laisse le reste intact. Un VPN transporte d’abord ce paquet à l’intérieur d’un autre paquet, si bien que l’écouteur de l’application voit une autre source et une charge utile maximale plus petite. Le chiffrement dont les gens débattent est présent dans les deux cas, parce que l’application reste HTTPS ; ce qui change, c’est qui peut ouvrir une connexion et ce que le réseau intermédiaire peut observer. Cette distinction règle la plupart des questions pratiques.

La règle DNAT réécrit la destination et s’arrête là

Sur une passerelle Linux, publier un service signifie une règle dans la chaîne PREROUTING de la table nat, ou l’équivalent dans nftables. La règle correspond à l’adresse et au port publics, puis réécrit la destination vers l’adresse privée de l’application. L’adresse source, le port source et la charge utile restent intacts, et conntrack enregistre la correspondance pour que les réponses soient réécrites en sortie. Le comportement est le modèle traditionnel de traduction d’adresses décrit dans RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

L’écouteur de l’application n’apprend jamais que la connexion est arrivée par une traduction. Il voit la véritable adresse source du client, ce qui est utile pour les journaux d’accès et les limites de débit, et il répond à l’adresse privée parce que conntrack inverse la correspondance. Rien sur ce chemin ne déchiffre ni ne rechiffre : TLS fonctionne toujours entre le client et le certificat propre à l’application.

La règle fixe aussi les modes de défaillance que vous rencontrerez plus tard. Si la passerelle transfère mais que l’hôte de l’application n’a aucune route de retour vers le client, les réponses partent avec la mauvaise source et la poignée de main se bloque. Si une seconde règle correspond en premier, l’ordre décide du résultat, et iptables -t nat -L -n -v montre les compteurs qui prouvent quelle règle a pris le paquet.

Le tunnel emballe le paquet avant que l’écouteur ne le voie

Un VPN ne publie pas du tout l’application. Le client construit un paquet extérieur adressé à l’adresse publique de la passerelle, chiffre le paquet intérieur à l’intérieur, et la passerelle déchiffre et achemine le paquet intérieur vers la destination privée. Avec WireGuard, le transport extérieur est UDP, généralement sur un port élevé ; avec OpenVPN sur TCP 443, le paquet extérieur ressemble à du TLS pour tout ce qui surveille le chemin.

À l’intérieur du tunnel, le paquet intérieur conserve des adresses privées : l’adresse de tunnel du client, disons 10.8.0.6, et l’application à 10.20.30.40. L’écouteur voit donc une source issue du pool du tunnel, et chaque client partage cette passerelle comme prochain saut. Les journaux d’accès derrière un VPN montrent souvent la passerelle plutôt que l’utilisateur précisément pour cette raison, sauf si la passerelle préserve la source d’origine.

L’emballage coûte de l’espace d’en-tête, et c’est la seule différence au niveau du mécanisme qui ait une conséquence mesurable. Un en-tête IP extérieur plus UDP plus l’en-tête propre à WireGuard entament le MTU du chemin, donc les gros paquets doivent être fragmentés ou la pile TCP intérieure doit limiter son MSS. Un transfert qui fonctionne sur le chemin redirigé peut se bloquer sur le tunnel lorsqu’un équipement intermédiaire abandonne l’ICMP qui aurait signalé le MTU plus petit.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

L’exposition se décide à l’entrée, pas par le chiffrement

Les deux conceptions aboutissent au même écouteur TLS, donc les deux héritent du même certificat, des mêmes versions de protocole et de la même connexion applicative. Ce qui change, c’est qui est autorisé à commencer une poignée de main. Avec une redirection publique, tout hôte qui atteint 203.0.113.10:443 obtient une poignée de main TCP et un ClientHello TLS avant même que l’autorisation de votre application soit consultée. Avec un accès par tunnel uniquement, l’écouteur n’est joignable que depuis les adresses que la passerelle route dans le tunnel, et le SYN d’un inconnu meurt à la politique de la passerelle.

Cette différence concerne l’accessibilité, pas la confidentialité. Un service HTTPS redirigé n’est pas du texte en clair, et un VPN ne supprime pas le besoin d’authentification de l’application : l’admission au tunnel répond si un appareil peut envoyer des paquets dans ce réseau, tandis que l’application de fichiers répond si un utilisateur peut lire un document. Confondre les deux est la façon dont les équipes finissent avec un VPN qui donne tout le LAN et une application avec un seul mot de passe partagé.

Inspectez l’écouteur et la politique séparément, car l’un ou l’autre peut être plus large que vous ne le supposez :

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Si ss montre que l’écouteur est lié à 0.0.0.0, l’application est joignable partout où le routage et la politique de pare-feu le permettent, et la redirection n’est qu’une des façons d’entrer. Le lier à l’adresse privée, ou restreindre la plage source dans le pare-feu, est une décision distincte du choix d’un VPN, et c’est elle qui réduit réellement l’exposition.

Mesurez le chemin, pas l’étiquette

Quand quelqu’un affirme que la redirection est plus rapide, la comparaison honnête maintient tout le reste constant : même client, même réseau d’accès, même fichier, même configuration TLS, même hôte d’application. Lancez le transfert deux fois par chemin et notez le temps total, le nombre d’échecs et la réactivité, pas la sortie d’un test de débit sans rapport.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Ces chiffres séparent l’établissement de la connexion du temps de transfert, ce qui compte parce que les deux chemins diffèrent généralement en latence aller-retour et en MTU plutôt qu’en coût de chiffrement. Le travail TLS se fait aux extrémités dans les deux conceptions, et un tunnel ajoute encapsulation, un autre itinéraire et peut-être une passerelle plus chargée. Si le chemin du tunnel est plus long ou si sa passerelle est chargée, la différence appartient au chemin et non au mot chiffrement.

Choisissez la politique d’entrée dont le service a réellement besoin, puis décidez si une différence mesurée justifie de la changer. Une redirection publique convient à un service destiné à l’internet ouvert, avec des restrictions de source, TLS à jour et une surveillance devant. Un accès par tunnel uniquement convient à un outil interne dont les utilisateurs sont déjà inscrits, à condition que le routage de la passerelle et les autorisations de l’application soient tous deux plus étroits que tout le LAN.

Avant de déclarer la conception terminée, confirmez quatre choses : à quelle adresse l’écouteur est lié, quelle règle ou route admet le paquet, si le chemin de retour fonctionne depuis l’adresse réelle du client et si les grosses charges utiles survivent au MTU. Chacune de ces questions a une commande ci-dessus, et aucune n’est résolue par le mot sécurisé ni par un graphique de bande passante.