¿Git se bloquea sin la VPN? OpenSSH marca los paquetes con IPQoS

Un clon desde la oficina funciona, el mismo clon por un punto de acceso del móvil funciona, y el mismo clon desde una red de hotel se cuelga hasta que se activa una VPN. El saludo SSH termina y la sesión se queda muda en la primera transferencia real. Una línea añadida a la configuración del cliente cura git y ssh a la vez. Cuando un solo ajuste del cliente repara varias herramientas de golpe, el fallo está en lo que envía el cliente, no en el enlace por el que lo envía.

Lea el síntoma como una diferencia de enrutamiento

Un túnel que cura un problema rara vez es una reparación. Cambia la ruta, el operador y los equipos intermedios, mientras el portátil sigue produciendo exactamente los mismos paquetes. Si una ruta trata mal una cabecera y otra la deja pasar intacta, la diferencia está en la política del equipo intermedio, no en el cliente. Aquí el túnel es un testigo, no una solución.

El punto donde muere la sesión lo acota más. Nada que falle en la resolución de nombres o en el intercambio de claves se parece a esto. Una sesión que se autentica, imprime un banner y luego se congela en la primera escritura masiva ya ha demostrado que el enrutamiento, los nombres y las credenciales funcionan.

El cliente estampa un byte QoS en cada socket SSH

Toda conexión OpenSSH desde la 7.8 lleva un valor en la cabecera IP que los routers pueden usar para priorizar el tráfico. Las sesiones de terminal reciben un valor y las copias masivas otro, con la teoría de que una persona que teclea merece mejor trato que una transferencia de archivos. La mayoría de las redes ignoran por completo la pista, y por eso pasa desapercibida durante años. Una minoría de controladores Wi-Fi, operadores móviles y concentradores VPN actúa sobre ella, y algunos lo hacen mal.

Cuando ese valor se reescribe o se descarta en mitad del flujo, la conexión no falla, deja de avanzar. Las retransmisiones suben, la ventana se derrumba y la aplicación no informa de nada porque nada dio error. Ese silencio es la razón por la que la gente describe el síntoma como un cuelgue y no como un fallo.

Confirme primero la versión del cliente con ssh -V. Cualquier versión en la 7.8 o superior trae este comportamiento de serie.

Tres comandos que separan esto del MTU y del DNS

Dos casos parecidos merecen descartarse antes de editar cualquier archivo de configuración. Un fallo de MTU deja pasar los intercambios pequeños y se congela en el primer paquete grande, mientras que un fallo de nombres nunca llega a producir una sesión.

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

El primer comando repite la operación que falla con la marca desactivada, y una ejecución correcta es la prueba individual más sólida disponible. El segundo imprime la configuración que el cliente aplicará realmente a ese destino, lo que detecta una entrada obsoleta en un archivo que había olvidado. El tercero muestra el byte TOS en ambos sentidos mientras la transferencia está atascada, y el patrón interesante es un valor en la ruta rota y ninguno en la que funciona.

Haga la captura en el portátil y no en el servidor, porque el emisor fija el valor y cualquiera de los dos sentidos puede alterarlo. Compare una ruta que funciona y una que falla con la misma captura, y la diferencia aparece sin adivinar.

Ponga la excepción en un solo archivo, un host a la vez

Una excepción pertenece junto al host al que se aplica, con un comentario que diga por qué existe.

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

El alcance importa más que el valor en sí. Una entrada comodín desactiva el comportamiento en todas partes, tira una pista que ayuda en redes bien educadas y no deja a nadie capaz de decir cuándo apareció. Una entrada por host es legible, reversible y trivial de borrar una vez reparada la red. Use el archivo de usuario para un apaño personal y un archivo gestionado cuando toda una flota necesite la misma excepción.

Sea explícito sobre lo que la excepción no cubre. Se aplica a SSH, así que un remoto HTTPS, un espejo de paquetes y un navegador quedan fuera, y un fallo en cualquiera de ellos necesita su propia evidencia. En una cadena a través de un bastión, cada salto usa la configuración del cliente, y el salto que se atasca es el que merece acotarse.

Cierre el círculo con el responsable de la red

Entregue el hallazgo como cuatro hechos: versión del cliente, ruta probada, cliente VPN en uso y qué sentido llevaba la marca. Esos cuatro bastan para que el responsable de la red reproduzca el trato y decida si es deliberado.

Si la excepción no cura el bloqueo, elimínela. Un apaño que sobrevive a un experimento fallido se convierte en leyenda, y la siguiente persona pasa una hora demostrando que no hace nada. Si sí cura el bloqueo, la ruta sigue siendo mala para cualquier otra herramienta que la cruce, y la reparación corresponde a quien opera el equipo intermedio.

El cambio en el cliente es un parche con fecha de caducidad. Escriba esa fecha en el comentario.