¿Git bloquéase sen a VPN? OpenSSH marca os paquetes con IPQoS

Un clon desde a oficina funciona, o mesmo clon por un punto de acceso do móbil funciona, e o mesmo clon desde unha rede de hotel colgase ata que se activa unha VPN. O aperto de mans SSH remata e a sesión queda muda na primeira transferencia real. Unha liña engadida á configuración do cliente cura git e ssh á vez. Cando un só axuste do cliente arranxa varias ferramentas de golpe, o fallo está no que envía o cliente, non na ligazón pola que o envía.

Lea o síntoma como unha diferenza de encamiñamento

Un túnel que cura un problema raramente é unha reparación. Cambia a ruta, o operador e os equipos intermedios, mentres o portátil segue producindo exactamente os mesmos paquetes. Se unha ruta trata mal unha cabeceira e outra a deixa pasar intacta, a diferenza está na política do equipo intermedio, non no cliente. Aquí o túnel é unha testemuña, non unha solución.

O punto onde morre a sesión acótao máis. Nada que falle na resolución de nomes ou no intercambio de chaves se parece a isto. Unha sesión que se autentica, imprime un banner e despois conxélase na primeira escritura masiva xa demostrou que o encamiñamento, os nomes e as credenciais funcionan.

O cliente estampa un byte QoS en cada socket SSH

Cada conexión OpenSSH desde a 7.8 leva un valor na cabeceira IP que os routers poden usar para priorizar o tráfico. As sesións de terminal reciben un valor e as copias masivas outro, coa teoría de que unha persoa que teclea merece mellor trato que unha transferencia de ficheiros. A maioría das redes ignoran por completo a pista, e por iso pasa desapercibida durante anos. Unha minoría de controladores Wi-Fi, operadores móbiles e concentradores VPN actúan sobre ela, e algúns fano mal.

Cando ese valor se reescribe ou se descarta no medio do fluxo, a conexión non falla, deixa de avanzar. As retransmisións soben, a xanela derrúbase e a aplicación non informa de nada porque nada deu erro. Ese silencio é a razón pola que a xente describe o síntoma como un colgue e non como un fallo.

Confirme primeiro a versión do cliente con ssh -V. Calquera versión na 7.8 ou superior trae este comportamento de serie.

Tres comandos que separan isto do MTU e do DNS

Dous casos parecidos merecen descartarse antes de editar calquera ficheiro de configuración. Un fallo de MTU deixa pasar os intercambios pequenos e conxélase no primeiro paquete grande, mentres que un fallo de nomes nunca chega a producir unha sesión.

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

O primeiro comando repite a operación que falla coa marca desactivada, e unha execución correcta é a proba individual máis sólida dispoñible. O segundo imprime a configuración que o cliente aplicará realmente a ese destino, o que detecta unha entrada obsoleta nun ficheiro que esquecera. O terceiro mostra o byte TOS en ambos os sentidos mentres a transferencia está atascada, e o patrón interesante é un valor na ruta rota e ningún na que funciona.

Faga a captura no portátil e non no servidor, porque o emisor fixa o valor e calquera dos dous sentidos pode alteralo. Compare unha ruta que funciona e unha que falla coa mesma captura, e a diferenza aparece sen adiviñar.

Poña a excepción nun só ficheiro, un host á vez

Unha excepción pertence xunto ao host ao que se aplica, cun comentario que diga por que existe.

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

O alcance importa máis que o valor en si. Unha entrada comodín desactiva o comportamento en todas partes, tira unha pista que axuda en redes ben educadas e non deixa a ninguén capaz de dicir cando apareceu. Unha entrada por host é lexible, reversible e trivial de borrar unha vez reparada a rede. Use o ficheiro de usuario para unha solución persoal e un ficheiro xestionado cando toda unha flota necesite a mesma excepción.

Sexa explícito sobre o que a excepción non cobre. Aplícase a SSH, así que un remoto HTTPS, un espello de paquetes e un navegador quedan fóra, e un fallo en calquera deles necesita a súa propia evidencia. Nunha cadea a través dun bastión, cada salto usa a configuración do cliente, e o salto que se atasca é o que paga a pena acoutar.

Peche o círculo co responsable da rede

Entregue o achado como catro feitos: versión do cliente, ruta probada, cliente VPN en uso e que sentido levaba a marca. Eses catro abondan para que o responsable da rede reproduza o trato e decida se é deliberado.

Se a excepción non cura o colgue, elimínea. Unha solución que sobrevive a un experimento fallido convértese en lenda, e a seguinte persoa pasa unha hora demostrando que non fai nada. Se si cura o colgue, a ruta segue sendo mala para calquera outra ferramenta que a cruce, e a reparación corresponde a quen opera o equipo intermedio.

O cambio no cliente é un parche con data de caducidade. Escriba esa data no comentario.