Port source du client face au listener du serveur dans un flux VPN
Comparez les deux numéros de port d'un tunnel : le listener fixe du serveur et la source éphémère du client, et comment la traduction du routeur s'insère entre eux.
Deux numéros apparaissent dans la même conversation, et aucun des deux n'est faux. Le journal du serveur montre le listener qui offre le service, l'ordinateur portable montre la socket qui a envoyé le datagramme, et un routeur intermédiaire peut réécrire le second en sortie. Comparer les extrémités de la conversation est plus utile que comparer les chiffres. La comparaison ci-dessous tient séparés le listener, la socket du client et la source traduite, parce qu'ils répondent à des questions différentes.
Deux numéros qui décrivent des extrémités opposées
Le port configuré du serveur est la destination que le client appelle. Il est fixé par la politique, figure dans le profil et doit être ouvert côté serveur. Le port source du client est choisi localement, généralement dans la plage éphémère, et existe pour que la réponse ait où atterrir. Il peut changer à chaque reconnexion, et rien dans la conception ne dépend de sa stabilité.
Un routeur intermédiaire peut réécrire cette source dans sa propre correspondance 'NAT'. C'est pourquoi le numéro observé sur le serveur n'a souvent aucun rapport avec celui choisi par l'ordinateur portable.
Où le numéro source change en sortie
Prenez un exemple IPv4 inventé : un client derrière un routeur qui traduit, un serveur avec un seul listener 'UDP' et un unique datagramme qui traverse les deux. Le tableau nomme chaque extrémité et ce qui lui arrive, plutôt que de rejouer le paquet en trois points d'observation.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
La destination est constante sur chaque ligne, et seule l'identité de la source change. Exigences d'UDP NAT distinguent une adresse et un port internes de la correspondance externe, ce qui est exactement l'écart entre la deuxième et la troisième ligne. Un routeur peut conserver le port source du client ou en choisir un autre ; la conservation n'est pas quelque chose qu'une application doit supposer.
Lisez les trois extrémités depuis les hôtes eux-mêmes
Les listes ci-dessous viennent de trois machines différentes et, ensemble, montrent toute la conversation. Exécutez la première sur le serveur, la deuxième sur le client et la troisième là où la correspondance existe. Une seule ligne de journal ne montre jamais les trois.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194La première liste prouve que le serveur est lié au port du service et indique quel processus le possède. La deuxième montre la socket locale du client et la destination qu'il a appelée. La troisième montre la correspondance créée par le routeur, et c'est le seul endroit où la source traduite apparaît. Lisez-les dans cet ordre et les deux numéros cessent de sembler contradictoires.
Ce qu'une reconnexion change, et ce qu'elle ne change pas
Certains routeurs conservent le port source du client lorsqu'il est libre, d'autres en attribuent un différent à chaque fois. Les deux comportements sont normaux, et une application qui exige le premier se cassera sur le second. Un changement de correspondance après une reconnexion ou un changement de réseau n'est pas une panne du serveur : le client ouvre une nouvelle socket, le routeur attribue ce qu'il a, et le serveur voit une nouvelle source sur le même listener. Ce qui serait une panne, c'est d'attendre du serveur qu'il accepte du trafic adressé à un port client arbitraire.
Les clients OpenVPN de la communauté obtiennent ce comportement grâce à nobind, qui laisse le système d'exploitation choisir le port local ; le port distant vient toujours du profil. Le lier explicitement est un choix délibéré, pas une exigence du protocole. Le serveur continue d'offrir une extrémité pendant que les clients choisissent leurs propres identités locales.
Étiquetez les couches séparément dans l'enregistrement
À l'intérieur du tunnel se déroule une seconde conversation avec ses propres ports. Une requête HTTPS portée par le tunnel a pour destination TCP 443, tandis que la connexion chiffrée extérieure utilise UDP 1194, si bien que changer le port source extérieur ne change rien au service intérieur.
Même à la couche extérieure, le protocole compte. UDP 1194 et TCP 1194 sont des extrémités différentes, et un listener 'TCP' ne recevra jamais un datagramme UDP parce que le numéro correspond. Lorsque vous documentez un déploiement, étiquetez le listener du serveur, la socket du client et la source traduite comme trois choses distinctes, et ajoutez le transport à chacune.
Ensuite, laissez la politique suivre les rôles. Le serveur ouvre le transport prévu sur son listener et authentifie toujours le pair ; le pare-feu du client admet les réponses à son propre échange sortant sans publier de service entrant. Un filtre sans état a besoin de la direction de retour écrite explicitement, et c'est la raison pratique pour laquelle la distinction compte au-delà des schémas soignés.