VPN sur le routeur ou redirection de port : laquelle gagne ?

Le routeur termine le VPN lui-même, et une ancienne règle de redirection envoie toujours le même port UDP vers une machine du réseau local. Une seule des deux peut être le vrai point de terminaison, et le noyau n’arbitre pas. La traduction de destination réécrit le paquet avant que le service local soit consulté, si bien que le processus VPN attend un trafic déjà envoyé ailleurs. La tâche consiste à déterminer qui possède le port, puis à faire concorder les règles.

Un port, deux propriétaires revendiqués

Un serveur VPN exécuté dans le routeur a besoin d’une autorisation entrante qui mène à sa propre socket. Une entrée NAT de destination pour le même port mène ailleurs entièrement : vers une adresse du réseau local et une décision de redirection. Ce sont des points de terminaison différents, avec des journaux différents et des modes de défaillance différents. L’indice habituel est qu’une famille d’adresses fonctionne et l’autre non, parce que l’entrée restante a été écrite pour une seule famille et n’a jamais été revue.

Notez la revendication avant d’éditer : famille, adresse externe, transport, port et cible traduite.

La traduction passe avant la vérification locale

Le NAT de destination change la cible du paquet à l’étape de pré-routage, avant que le noyau choisisse entre livraison locale et redirection. Dès que la cible est un hôte du réseau local, le paquet prend le chemin de la redirection. Les règles d’entrée pour la socket du routeur ne sont jamais consultées, d’où le journal VPN vide pendant que le client expire.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Cet ordre est tout le mécanisme, et les interfaces des appareils le cachent derrière des cases à cocher sans le changer. Le propriétaire de la destination décide toujours du chemin que prend un paquet.

Si l’hôte du réseau local est le point de terminaison prévu, la redirection est correcte et le routeur ne devrait pas aussi écouter sur ce port.

Gardez une correspondance et supprimez l’autre

Listez les entrées NAT pour ce port et cette famille et choisissez le survivant :

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Une entrée TCP portant le même numéro est sans rapport avec une panne UDP, et les traiter comme un seul objet conduit à supprimer la mauvaise règle. Quand la socket locale doit gagner, le propriétaire de la correspondance conflictuelle supprime ou réécrit cette entrée, et l’autorisation entrante pour le port du routeur reste en place. Les redirections sans rapport, le chemin de gestion et une copie du jeu de règles devraient tous survivre au changement.

Si le VPN vit sur un hôte séparé, la redirection est le bon objet. Un service dans un conteneur ou une machine virtuelle peut avoir besoin d’un port publié même quand la boîte s’appelle routeur, donc suivez la socket et son espace de noms plutôt que l’étiquette sur le boîtier.

Confirmez le propriétaire depuis l’extérieur

Testez chaque famille séparément, car une connexion IPv6 qui se termine sur le routeur ne dit rien d’une connexion IPv4 qu’une règle obsolète redirige. Lisez le journal du service récepteur pour voir quel point de terminaison a répondu, et considérez le message de succès du client comme une preuve faible. Un nouveau flux est nécessaire pour un test significatif. Envoyez une sonde depuis un hôte externe avec nc -zvu 203.0.113.7 1194 et lisez le journal du gagnant avec journalctl -u openvpn@server -n 20. L’écouteur du routeur journalise la connexion lui-même, tandis qu’un hôte du réseau local la journalise dans son propre service.

Le suivi des connexions maintient les flux existants sur leur correspondance d’origine, si bien qu’une session établie peut survivre à la règle que vous venez de corriger.

Une fois que le point de terminaison prévu répond avec ses contrôles d’identité habituels, testez une ressource privée derrière le tunnel. Atteindre l’écouteur externe n’est que le premier saut ; le routage interne et l’autorisation applicative sont des résultats distincts.