Déclenchement de port ou redirection de port pour un serveur VPN à domicile
Le déclenchement ouvre une correspondance après le trafic sortant ; la redirection mappe le port pour de bon. Un serveur VPN à domicile a besoin de la seconde, limitée au véritable écouteur.
La redirection de port et le déclenchement de port se trouvent dans le même menu sur la plupart des routeurs domestiques, et c’est pourquoi on les traite comme deux façons de faire un seul travail. La redirection est une règle statique : une connexion entrante vers un port WAN est traduite vers une adresse et un port internes fixes, que quelque chose d’autre se produise ou non. Le déclenchement est conditionnel : le routeur surveille le trafic sortant et n’ouvre une correspondance entrante qu’après la sortie d’une connexion correspondante. Un serveur VPN attend que quelqu’un d’autre se connecte d’abord, donc cette condition est précisément la seule chose qu’il ne peut jamais remplir.
Deux règles aux cycles de vie différents
Le NAT IPv4 est à état. Quand un hôte interne envoie un paquet vers l’extérieur, le routeur crée une correspondance pour que les réponses retrouvent leur chemin ; un paquet entrant qui ne correspond à aucune correspondance est abandonné, et c’est ce comportement qui garde un poste non corrigé hors d’internet. La redirection est une entrée de traduction permanente ajoutée à la main. Le déclenchement est un trou temporaire gardé par un motif de trafic.
La différence pratique est le temps. Une redirection existe du moment où elle est enregistrée jusqu’à ce que quelqu’un la supprime. Une correspondance déclenchée existe après le déclenchement et se ferme sur un minuteur d’inactivité, mesuré en minutes sur du matériel grand public, ou immédiatement au redémarrage.
Ni l’une ni l’autre n’est plus sûre dans l’absolu. Une redirection expose un port en continu ; un déclencheur ne l’expose qu’après un trafic sortant précis. Pour un service qui doit accepter le premier paquet d’un inconnu, une seule des deux correspond au travail.
Pourquoi le déclenchement ne publiera pas un serveur
Un serveur VPN est passif par conception. Le pair, qu’il s’agisse d’un portable dans un café ou d’un téléphone sur données mobiles, envoie le premier paquet, et le routeur n’a aucune correspondance pour lui. Rien à l’intérieur n’a lancé de trafic vers le port de déclenchement, donc la règle ne se déclenche jamais et la connexion meurt avant que la poignée de main ne commence.
Là où le déclenchement semble fonctionner, autre chose génère du trafic sur le port de déclenchement : un client sur le LAN, une sonde de supervision ou les propres vérifications sortantes du serveur. La correspondance s’ouvre alors pour ce seul hôte et se ferme quand le trafic s’arrête, donc le pair externe suivant échoue de nouveau tandis que le premier succès reste dans le journal et ressemble à une preuve.
Le déclenchement est aussi généralement mono-hôte. Beaucoup d’implémentations ne laissent qu’un seul appareil interne détenir la correspondance à la fois, ce qui est exactement faux pour un serveur censé répondre à plusieurs pairs. La fonction a été conçue pour des applications qui ouvrent une connexion de contrôle vers l’extérieur et attendent des données entrantes sur un second port, et elle correspond encore à cette forme.
Ce qu’une redirection mappe réellement
Une redirection est une entrée de traduction : port et protocole WAN vers adresse et port internes. Il lui faut un écouteur déjà en cours d’exécution à l’autre bout, et il faut que l’adresse interne reste en place. Un bail DHCP qui passe à une autre machine envoie chaque tunnel au mauvais hôte, silencieusement, alors créez la réservation avant la règle.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
Le protocole compte plus que le formulaire ne le suggère. OpenVPN sur UDP a besoin d’une redirection UDP, WireGuard a besoin d’UDP, et les données IPsec arrivent en ESP, protocole IP 50, qui n’a aucun port du tout. Un formulaire de redirection qui n’accepte que TCP ou UDP ne peut pas l’exprimer, donc IPsec a besoin d’un passthrough ou d’une correspondance statique un-pour-un au lieu d’une règle de port.
La couche au-dessus de votre routeur
Une redirection ne contrôle que la traduction qui vous appartient. Si l’adresse WAN n’est pas la vôtre, ce qui est le cas derrière un NAT d’opérateur où les abonnés partagent 100.64.0.0/10 comme décrit dans RFC 6598, la connexion entrante n’atteint jamais votre routeur parce que le fournisseur a traduit en premier. Aucune règle de votre appareil ne peut corriger cet ordre.
Le double NAT est le même problème en miniature. Votre routeur redirige vers le routeur du FAI, qui n’a aucune règle correspondante et abandonne le paquet. Soit vous ajoutez la règle sur l’appareil extérieur, soit vous mettez l’appareil extérieur en mode pont et laissez le vôtre garder l’adresse publique.
C’est pourquoi le test doit venir de l’extérieur. Un test depuis le même LAN via l’adresse publique dépend de la prise en charge du hairpin NAT et peut réussir ou échouer pour des raisons sans rapport avec la règle ; un téléphone sur données mobiles, ou un ami sur un autre réseau, est la vérification la plus propre.
Limitez la règle, puis vérifiez les deux moitiés
Redirigez un port vers une adresse. Une plage ajoutée parce que les premières tentatives ont échoué est la façon dont les interfaces d’administration finissent sur internet, et l’écouteur VPN n’a pas besoin de la page d’administration du routeur publiée à côté.
Gardez tout ce qui protégeait déjà cet écouteur : identité par certificat ou clé, pare-feu de l’hôte, versions à jour des paquets. Une redirection laisse entrer un paquet ; l’authentification décide si le paquet devient un tunnel, et ce sont deux défaillances distinctes quand quelque chose ne va pas.
La vérification a deux moitiés. La poignée de main doit aboutir depuis un réseau externe, puis une ressource privée derrière le serveur doit répondre par le tunnel. La redirection admet la connexion du tunnel et rien de plus ; le routage et l’autorisation pour 10.8.0.0/24 sont un autre réglage sur un autre écran.
Décidez avec trois questions
Trois questions tranchent le choix plus vite que n’importe quel tableau comparatif :
- Quelque chose se connecte-t-il de l’extérieur, comme premier paquet ? Alors utilisez la redirection, ou un relais. Le déclenchement ne peut pas s’ouvrir sans trafic sortant qui n’existera jamais.
- Le trou doit-il survivre au temps d’inactivité ? Alors utilisez la redirection, car une correspondance déclenchée se ferme selon son propre calendrier.
- L’adresse WAN est-elle à vous pour la publier ? Si non, corrigez la couche du dessus avant de modifier la moindre règle.
Si la réponse aux trois est non, ce qui est le cas d’un portable qui compose lui-même vers un fournisseur commercial, aucune des deux règles n’est nécessaire. Un client derrière NAT fonctionne parce qu’il crée lui-même la correspondance à état, et cela couvre la plupart des gens qui lisent une page sur la redirection de port à minuit.