Pourquoi de nombreuses connexions d’applications partagent une seule session OpenVPN

Imaginez un navigateur qui charge une page HTTPS pendant qu’un client SSH atteint un autre serveur et qu’un résolveur répond à une requête, le tout via une seule session OpenVPN. Sur l’interface physique, vous voyez une conversation ; à l’intérieur du tunnel, vous en voyez trois. Les deux vues sont correctes, et savoir pourquoi fait la différence entre une capture utile et une capture déroutante. Suivez un flux intérieur de la socket jusqu’au câble et l’empilement cesse d’être abstrait.

Une conversation extérieure, de nombreux flux intérieurs

Chaque application ouvre sa propre socket, et le noyau lui attribue un quintuplet composé de l’adresse source, du port source, de l’adresse de destination, du port de destination et du protocole. Ces quintuplets existent avant qu’un tunnel n’intervienne. Le routage décide ensuite qu’ils sortent tous par le périphérique tunnel, si bien que le paquet remis à OpenVPN porte encore les en-têtes d’origine à l’intérieur. OpenVPN chiffre ce paquet intérieur et enveloppe le résultat dans une seule conversation UDP ou TCP extérieure avec le pair. La conversation extérieure est donc unique, tandis que les flux qu’elle contient sont aussi nombreux que les applications se sont ouvertes.

Rien ne s’effondre. Les quintuplets intérieurs survivent de bout en bout, et c’est pourquoi le côté distant distingue encore les trois flux.

Le port qui reste figé

Ce qui reste constant, c’est le quintuplet extérieur : votre adresse, le port local que le client a lié, l’adresse du pair et le port de service configuré. C’est ce quintuplet qu’un pare-feu ou un NAT sur le chemin doit autoriser, et c’est celui qu’une capture sur le lien montant montrera. C’est aussi celui qui change après une reconnexion ou un changement de réseau, car le client peut lier un autre port local. Un tunnel n’implique pas un port source figé pour toujours.

Ce sont les ports intérieurs qui importent aux extrémités. Un flux HTTPS conserve le port de destination 443 à l’intérieur du tunnel, même si le transport extérieur occupe le port configuré par l’opérateur. Les extrémités applicatives n’apprennent jamais l’existence du port extérieur.

Ce que la décapsulation change à l’extrémité distante

Chez le pair, la couche extérieure est retirée, et le paquet intérieur est ce qui reste. À partir de là, le transfert et la politique d’accès s’appliquent à la destination et au protocole intérieurs. Le serveur web reçoit toujours une connexion HTTPS, le démon SSH reçoit toujours SSH, et le résolveur reçoit toujours une requête.

C’est pourquoi une règle qui autorise le transport extérieur n’est pas la même règle que l’autorisation d’un service interne. La première décrit un chemin ; la seconde décrit une autorisation.

Un TCP extérieur signifie un seul flux, pas une seule connexion

Lorsque le transport extérieur est UDP, le sort de chaque flux intérieur est indépendant : un datagramme perdu affecte un transfert jusqu’à sa propre retransmission. Lorsque le transport extérieur est TCP, tous les flux intérieurs partagent un seul flux d’octets fiable.

Ce flux partagé est la partie que les gens manquent. La récupération a lieu une fois, pour tout, si bien qu’un seul segment perdu retarde le trafic de chaque application multiplexée à l’intérieur. Il reste de nombreuses connexions aux extrémités et une seule connexion sur le câble, et c’est sur le câble que vit l’effet de tête de file. Le nombre de ports en écoute ne vous dit rien de tout cela, et c’est pourquoi compter les ports est une mauvaise façon de raisonner sur les performances d’un tunnel.

Décrivez votre propre configuration avec précision

Nommez le trafic intérieur choisi et le transport extérieur précis qui le porte, plutôt que de dire que la machine envoie tout par un seul port. Les services locaux, un second tunnel et l’autre famille d’adresses créent tous des flux qui n’entrent jamais dans cette conversation. Une capture sur le lien montant montre le quintuplet extérieur ; une capture à l’intérieur du tunnel montre les quintuplets intérieurs.

Prenez les deux, et mettez les horodatages côte à côte. Si vous devez prouver quelle application a généré quel flux intérieur, la table des sockets de l’hôte est le meilleur instrument, car elle associe directement les ports aux processus. Notez ensuite le quintuplet extérieur que vous avez observé et le moment où vous l’avez observé, car la capture suivante après une reconnexion peut légitimement afficher d’autres chiffres.