Les ports UDP fixes peuvent éviter la redirection de ports, mais pas tous les NAT

Deux routeurs domestiques, aucun port redirigé, et un VPN qui se connecte parfois quand même. UDP le permet, parce que un pare-feu admettra un paquet qu'il peut faire correspondre à un flux que la machine a déjà lancé. C'est une astuce conditionnelle, pas une fonctionnalité, et les conditions sont faciles à énoncer une fois qu'on sait ce que le pare-feu compare. Elles sont aussi la raison pour laquelle des profils identiques se comportent différemment sur des réseaux différents.

La comparaison que fait un pare-feu

Chaque datagramme sortant crée une entrée éphémère : adresse source, port source, adresse de destination, port de destination. Tout ce qui arrive et correspond à l'entrée est traité comme une réponse et laissé passer. Les règles d'entrée n'entrent pas en jeu.

La question n'est donc pas de savoir si le pare-feu laisse entrer le pair. Elle est de savoir si le paquet du pair ressemble à la réponse que l'entrée attend. Changez un champ de ce quadruplet et le paquet devient un étranger. C'est pourquoi une configuration qui fonctionne peut casser quand seul le numéro de port change, et pourquoi le même port peut marcher sur un routeur et échouer sur le suivant.

Fixez le port source local, et le même numéro apparaît des deux côtés de l'échange. C'est tout le mécanisme, et cela explique pourquoi l'astuce est fragile plutôt que mystérieuse.

Épingler un port à chaque extrémité

Le port UDP par défaut d'OpenVPN est 1194, et lport fixe le port source depuis lequel il envoie. Épinglez les deux pairs et le quadruplet sortant de chacun pointe vers un port sur lequel l'autre écoute :

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

Cela ne fonctionne que tant qu'aucun routeur entre eux ne réécrit le port source. Quand des paquets apparaissent dans une capture mais qu'aucun tunnel ne monte, la réécriture est le premier suspect.

Où le quadruplet cesse de correspondre

Un NAT qui mappe par destination attribue à chaque pair un port externe différent. L'adresse qu'on a dit à votre pair d'utiliser n'est pas celle qui l'atteint, donc le paquet entrant ne correspond à rien et est silencieusement écarté.

La traduction opérateur, le NAT empilé et la randomisation des ports finissent tous de la même façon. Tout boîtier intermédiaire qui réécrit les ports en laissant les adresses tranquilles aussi.

Les transports de flux sont plus mal lotis. Une poignée de main TCP est suivie étape par étape, donc un VPN basé sur TCP ne peut pas être percé de cette façon du tout et a besoin d'un écouteur quelque part sur le chemin.

Un côté échoue généralement en premier

En pratique, les deux réseaux se comportent rarement de la même façon. Un routeur peut fournir un mappage prévisible tandis que l'autre distribue des ports par destination, et le résultat est une configuration qui fonctionne entre deux foyers et échoue depuis un réseau mobile. Les rapports qui se contredisent décrivent généralement deux paires de routeurs différentes. Aucun des deux auteurs n'a tort, et aucun des deux résultats ne se généralise.

Déterminez quel côté a abandonné le paquet avant de toucher aux profils. Des captures aux deux extrémités tranchent en une tentative : les datagrammes qui quittent A et n'atteignent jamais B signifient que le flux a été réécrit en transit, tandis que ceux qui arrivent à B sans qu'aucune réponse ne revienne signifient que le pare-feu ne les a pas acceptés comme liés.

Deux pairs avec des adresses IPv6 publiques contournent tout le problème. Sans traduction, il n'y a rien à faire correspondre, donc une règle de pare-feu nommant les pairs suffit et la conception cesse de dépendre du comportement du routeur.

Quand arrêter d'essayer

Un hôte avec une adresse publique est la réponse fiable. Il peut terminer le tunnel pour les deux pairs, ou simplement les aider à découvrir l'adresse externe actuelle de l'autre, et les deux arrangements fonctionnent quoi que fassent les NAT. Une couche superposée gérée offre la même coordination si la politique le permet.

Aucune de ces solutions n'a besoin d'un pare-feu désactivé. Couper la protection pour gagner la connexion directe écarte la raison pour laquelle la tentative directe était attrayante, et laisse la machine ouverte pendant toute la durée du test.

Essayez d'abord l'arrangement direct, puis notez ce que vous avez vu. Le comportement du NAT et la capture qui l'a montré valent plus que la paire de ports que vous avez fini par utiliser, car le prochain réseau sera différent. Le manuel d'OpenVPN 2.6 documente lport et les options remote dont cela dépend.