Le HTTPS d'un conteneur se bloque sur un VPN d'entreprise ? Testez la branche DTLS

Dans un conteneur derrière un VPN d'entreprise, le DNS résout, la page de connexion se charge, un point de contrôle de santé répond, puis une requête HTTPS se bloque jusqu'au délai d'expiration. Reconstruire l'image et modifier les variables du proxy ne change rien, car la partie en panne n'est pas dans l'image. Le client s'authentifie sur un transport et déplace les données en volume sur un autre, et seul le second est cassé.

Deux transports, un symptôme déroutant

Un client d'entreprise basé sur TLS s'authentifie généralement sur une connexion TLS ordinaire, puis négocie un second canal de données basé sur UDP pour la session. Quand cette seconde branche fonctionne, le débit et la latence s'améliorent. Quand elle est filtrée ou ne passe pas par le chemin, tout ce qui précède le transfert en volume réussit et le transfert lui-même s'arrête, ce qui correspond exactement au schéma ci-dessus.

Un conteneur ne change pas cette négociation ; il change le chemin que prennent les paquets extérieurs. L'hôte traduit le flux du conteneur, si bien que les datagrammes UDP partent d'un port source différent de la socket locale du client et reviennent par une entrée de traduction qui expire sur un délai bien plus court qu'un flux TCP établi. Si le tunnel fonctionne sur l'hôte et échoue dans le conteneur, comparez ces deux flux avant d'accuser l'application. Cette comparaison tranche plus que n'importe quelle reconstruction d'image.

Décidez par l'expérience, pas par l'intuition

L'expérience la moins coûteuse désactive le canal de données UDP et rejoue la requête. Utilisez le client en ligne de commande plutôt que l'enveloppe de bureau, pour que l'option s'applique vraiment : openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Si la requête qui bloquait aboutit maintenant, la branche DTLS était le problème et le reste était du bruit.

Confirmez le résultat dans les deux sens depuis le même conteneur : une requête en volume avec l'option et une sans. Un changement de comportement qui suit l'option est une preuve ; une page qui finit par se charger n'en est pas une.

Si l'option corrige le problème, décidez pourquoi

Trois conditions produisent le même symptôme et appellent des réponses différentes. Le chemin peut filtrer UDP entièrement, ce qui fait de l'option la bonne réponse permanente pour ce réseau. Le chemin peut autoriser UDP mais abandonner les gros datagrammes, ce qui pointe vers le MTU plutôt que vers le filtrage. Ou le chemin peut être assez lossy pour que la branche UDP fasse moins bien que TCP, ce qui est une décision de capacité et non de joignabilité.

Distinguez-les avant de documenter un contournement. Le filtrage survit à toutes les tailles de paquet, les problèmes de MTU n'apparaissent qu'au-dessus d'un seuil, et la perte se manifeste par des retransmissions et un délai variable plutôt que par un blocage net. Chaque test resserre la cause sans changer la configuration du client.

Vérifiez la taille des paquets avant de garder le contournement

Si la taille est la cause, l'interface du tunnel accepte des paquets que le chemin ne peut pas transporter, et le problème revient sur n'importe quel transport dès que les charges utiles grossissent. Comparez les interfaces : ip link show tun0 sur l'hôte, puis docker network inspect bridge pour lire le MTU consigné dans les options réseau. Un pont de conteneur encore à 1500 octets sous un tunnel qui transporte moins, c'est le constat habituel.

Sondez vers le haut depuis une taille connue comme bonne avec un test de non-fragmentation dans le tunnel, puis abaissez le MTU du réseau du conteneur ou limitez le MSS TCP sur le tunnel. L'une ou l'autre correction rend souvent le chemin UDP de nouveau utilisable et supprime le besoin de l'option, ce qui est le meilleur résultat quand le filtrage n'est pas la cause.

Décidez ce que vous acceptez d'échanger

Canal de données désactivé, le tunnel transporte sa charge dans une connexion TCP. Sur un chemin propre, c'est simplement plus lent ; sur un chemin avec pertes, un seul segment perdu retarde tout ce qui suit et la retransmission extérieure entre en concurrence avec l'intérieure. Cet échange convient au développement interactif et aux petits appels d'API, et convient mal aux transferts en volume ou aux sessions longues sur des liens mobiles.

Quelle que soit l'option choisie, notez quel transport le tunnel a fini par utiliser et pourquoi. Un conteneur qui dépend silencieusement d'une option ajoutée par quelqu'un des mois plus tôt est la prochaine panne, et la personne qui la déboguer ne saura pas si l'option était un contournement pour le filtrage ou un reste d'une expérience sur le MTU.