Exigences de ports VPN : trois lignes à écrire avant de comparer
Déterminez quelle question de port vous avez réellement : destination sortante, publication entrante ou transport propre du tunnel. Puis ne demandez que cela au fournisseur.
Les listes de ports des services VPN sont recopiées entre pages de comparaison sans le détail qui décide si elles comptent : qui lance la connexion. Une règle qui autorise TCP 443 en sortie ne dit rien sur la possibilité qu’un autre hôte atteigne un écouteur sur votre machine. Écrivez trois exigences distinctes avant de comparer un seul forfait, et marquez celles dont votre tâche a réellement besoin. La plupart des comparaisons se réduisent à une seule question courte dès que cette feuille existe.
Séparez l’exigence avant de lire la moindre liste de ports
Trois lignes couvrent presque tous les cas : atteindre une destination au-delà du tunnel, publier quelque chose pour que d’autres puissent se connecter vers l’intérieur, et transporter le tunnel lui-même. Chaque ligne échoue pour une raison différente, et une politique de fournisseur qui en satisfait une peut laisser les deux autres intactes. Classer votre tâche dans la bonne ligne prend cinq minutes et évite une discussion plus tard.
| Line | Who starts it | What can block it | Question for the provider |
|---|---|---|---|
| Outbound destination | Your application | Egress filter on the exit node | Is this protocol and port allowed to that destination? |
| Inbound publishing | A remote peer | No mapping, no public address, short lifetime | Which protocol, which external port, and how long does the mapping last? |
| Tunnel transport | Your client to the gateway | The access network drops that protocol | Does the client offer a fallback the local network permits? |
Les déclarations marketing brouillent les trois lignes à dessein. Une autorisation P2P décrit une politique de destination, une adresse dédiée décrit une adresse, et l’affirmation d’aucune restriction de ports signifie généralement que le forfait ne les énumère pas. Aucune de ces phrases ne répond aux autres.
Choisissez un flux concret et écrivez-le comme une phrase : initiateur, transport, port, famille d’adresses, direction. Un client de sauvegarde nocturne qui envoie vers un hôte distant est uniquement sortant. Un serveur de jeu sur votre bureau auquel des amis se connectent est entrant. Faire passer les deux par un seul tunnel signifie que la feuille a besoin des deux lignes, pas d’un compromis entre elles.
L’accès sortant échoue sur la politique de destination, pas sur le tunnel
Le trafic sortant à travers une passerelle qui traduit crée un état. Le premier paquet d’une adresse et d’un port internes construit une entrée de traduction, et les réponses y correspondent, ce qui est le comportement de mappage décrit dans RFC 3022. Ce mécanisme explique pourquoi un onglet de navigateur fonctionne généralement sans aucune demande de port.
Deux choses le cassent encore. Le nœud de sortie peut filtrer des destinations ou des numéros de port qu’il juge abusifs, et l’application peut écouter sur un port que la politique de sortie n’a jamais prévu. Posez la question du couple de destination plutôt que des règles entrantes, et attendez-vous à des réponses différentes pour TCP et UDP.
Mesurez avant de discuter. Exécutez ceci sur la machine qui se trouvera derrière le tunnel, une fois tunnel coupé et une fois tunnel monté :
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com
Les mêmes commandes, la même destination, deux états du tunnel, donnent à un opérateur une comparaison avant-après sur laquelle agir. Remplacez l’adresse de documentation par l’hôte dont vous avez réellement besoin ; l’important est que la comparaison se répète, pas qu’un chiffre paraisse impressionnant.
La publication entrante exige un mappage, une adresse et une durée de vie
Rien de l’extérieur ne peut lancer une connexion vers votre écouteur tant que quelque chose côté public ne sait pas où la livrer. Une réservation de port statique tenue par l’opérateur, un mappage demandé par le client via UPnP, NAT-PMP ou PCP, et une adresse publique routée sont trois produits différents avec trois limites différentes.
Posez cinq questions à n’importe lequel d’entre eux : quel protocole, quel port externe, si le port externe peut différer du local, quelle famille d’adresses il couvre, et combien de temps le mappage survit à une reconnexion. Une réservation liée à une session active disparaît quand cette session se termine, quoi qu’en dise la page du forfait.
Confirmez d’abord la moitié locale, car un écouteur mort et un chemin entrant bloqué se ressemblent de l’extérieur :
ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
Quand la requête locale renvoie 200 et qu’une requête depuis un réseau que vous ne contrôlez pas expire encore, la faille se situe côté public. C’est le moment d’annoncer le protocole et le port externe à l’opérateur plutôt que de décrire l’application par son nom.
Le transport propre du tunnel est une question distincte
Les ports du transporteur sont la plus petite partie du problème et la plus facile à vérifier. Les valeurs par défaut varient selon le protocole, et ce que le client peut négocier compte plus que n’importe quelle description de forfait.
| Client | Outer transport | Default port | When it helps |
|---|---|---|---|
| OpenVPN | UDP | 1194 | Default mode; needs outbound UDP to pass |
| OpenVPN | TCP | 443 | UDP is dropped and TCP 443 is not |
| WireGuard | UDP | 51820 | Short handshake; there is no TCP mode |
| IKEv2/IPsec | UDP | 500 and 4500 | Mobile clients; 4500 carries NAT traversal |
Un réseau qui jette l’UDP sortant acceptera un tunnel TCP 443 et refusera un tunnel UDP, donc un mode de repli appartient à la feuille d’exigences. Changer de transporteur ne déplace pas un port d’application à l’intérieur du tunnel et n’élargit pas une politique de destination ; ceux-là restent sur leurs propres lignes.
La fragmentation mérite une sonde pendant que vous y êtes, car un tunnel qui se connecte puis se bloque sur les gros transferts a généralement une MTU erronée plutôt qu’un port fermé :
ping -M do -s 1400 203.0.113.10 ping -M do -s 1372 203.0.113.10
Sous Windows, la même sonde est ping -f -l 1400 203.0.113.10. Réglez la MTU du tunnel sous la plus grande taille qui passe, puis retestez le transfert qui a échoué.
Vérifiez les trois lignes avant de payer un forfait
Mettez les trois lignes sur une page et remplissez chaque cellule d’un résultat mesuré plutôt que d’une promesse. Ces commandes produisent la moitié locale de cette page en une minute environ :
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10
Lisez la sortie comme une liste de contrôle. Le sortant fonctionne quand la destination répond avec le tunnel monté. L’entrant ne fonctionne que lorsqu’un hôte hors de votre réseau atteint l’écouteur sur le port externe. Le transporteur fonctionne quand la poignée de main se termine sur un protocole que votre réseau d’accès autorise.
Deux habitudes gardent la feuille honnête. Notez la date et la version du client à côté de chaque résultat, car les politiques des fournisseurs et les valeurs par défaut des clients bougent toutes les deux. Demandez ensuite le mappage le plus étroit qui serve le flux, car une demande d’ouvrir tout obtient généralement un refus ou une vente additionnelle plutôt qu’une réponse technique.