Git se bloque sans le VPN ? OpenSSH marque les paquets avec IPQoS

Un clone depuis le bureau fonctionne, le même clone via un partage de connexion mobile fonctionne, et le même clone depuis un réseau d'hôtel se bloque jusqu'à ce qu'un VPN soit activé. La poignée de main SSH se termine et la session se tait dès le premier transfert réel. Une ligne ajoutée à la configuration du client guérit git et ssh ensemble. Quand un seul réglage client répare plusieurs outils d'un coup, la faute est dans ce que le client envoie, pas dans le lien par lequel il l'envoie.

Lisez le symptôme comme une différence de routage

Un tunnel qui guérit un problème est rarement une réparation. Il échange la route, l'opérateur et les boîtiers intermédiaires, tandis que le portable continue de produire exactement les mêmes paquets. Si une route traite mal un en-tête et qu'une autre le laisse passer intact, la différence tient à la politique du boîtier intermédiaire, pas au client. Ici le tunnel est un témoin, pas une solution.

Le point où la session meurt resserre encore. Rien de ce qui échoue à la résolution de noms ou à l'échange de clés ne ressemble à cela. Une session qui s'authentifie, imprime une bannière puis se fige au premier gros transfert a déjà prouvé que le routage, les noms et les identifiants fonctionnent.

Le client estampille un octet QoS sur chaque socket SSH

Chaque connexion OpenSSH depuis la 7.8 porte dans l'en-tête IP une valeur que les routeurs peuvent utiliser pour prioriser le trafic. Les sessions de terminal reçoivent une valeur et les copies massives une autre, selon la théorie qu'un humain qui tape mérite un meilleur traitement qu'un transfert de fichier. La plupart des réseaux ignorent complètement l'indice, ce qui explique qu'il passe inaperçu pendant des années. Une minorité de pilotes Wi-Fi, d'opérateurs mobiles et de concentrateurs VPN agissent dessus, et certains le font mal.

Quand cette valeur est réécrite ou rejetée en cours de flux, la connexion n'échoue pas, elle cesse de progresser. Les retransmissions grimpent, la fenêtre s'effondre, et l'application ne signale rien parce que rien n'a produit d'erreur. Ce silence est la raison pour laquelle les gens décrivent le symptôme comme un blocage et non comme une panne.

Confirmez d'abord la version du client avec ssh -V. Toute version à partir de la 7.8 porte ce comportement par défaut.

Trois commandes qui séparent cela du MTU et du DNS

Deux cas ressemblants méritent d'être écartés avant de modifier un fichier de configuration. Une panne de MTU laisse passer les petits échanges et se fige au premier gros paquet, tandis qu'une panne de noms ne produit jamais de session.

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

La première commande répète l'opération qui échoue avec le marquage désactivé, et une exécution réussie est la preuve isolée la plus forte disponible. La deuxième imprime la configuration que le client appliquera réellement à cette destination, ce qui attrape une entrée périmée dans un fichier que vous aviez oublié. La troisième montre l'octet TOS dans les deux sens pendant que le transfert est bloqué, et le motif intéressant est une valeur sur la route cassée et aucune sur celle qui fonctionne.

Faites la capture sur le portable et non sur le serveur, car l'émetteur fixe la valeur et chaque sens peut la modifier. Comparez une route qui fonctionne et une qui échoue avec la même capture, et la différence apparaît sans deviner.

Placez l'exception dans un seul fichier, un hôte à la fois

Une exception a sa place à côté de l'hôte auquel elle s'applique, avec un commentaire qui dit pourquoi elle existe.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

La portée compte plus que la valeur elle-même. Une entrée générique désactive le comportement partout, jette un indice qui aide sur les réseaux bien élevés et ne laisse personne capable de dire quand elle est apparue. Une entrée par hôte est lisible, réversible et triviale à supprimer une fois le réseau réparé. Utilisez le fichier utilisateur pour un contournement personnel et un fichier géré quand toute une flotte a besoin de la même exception.

Soyez explicite sur ce que l'exception ne couvre pas. Elle s'applique à SSH, donc un dépôt distant HTTPS, un miroir de paquets et un navigateur restent en dehors, et une panne dans l'un d'eux exige sa propre preuve. Sur une chaîne passant par un bastion, chaque saut utilise la configuration du client, et le saut qui se bloque est celui qui vaut la peine d'être circonscrit.

Bouclez la boucle avec le responsable du réseau

Transmettez la trouvaille comme quatre faits: version du client, route testée, client VPN utilisé et quel sens portait le marquage. Ces quatre suffisent à un responsable réseau pour reproduire le traitement et décider s'il est délibéré.

Si l'exception ne guérit pas le blocage, retirez-la. Un contournement qui survit à une expérience ratée devient une légende, et la personne suivante passe une heure à prouver qu'il ne fait rien. S'il guérit le blocage, le chemin reste mauvais pour tout autre outil qui le traverse, et la réparation revient à qui exploite le boîtier intermédiaire.

Le changement côté client est un pis-aller avec une date d'expiration. Écrivez cette date dans le commentaire.