O Git trava sem a VPN? O OpenSSH marca os pacotes com IPQoS
O OpenSSH marca os seus pacotes com um valor de QoS por predefinição. Onde um caminho descarta essa marca, o push trava até um túnel mudar a rota que os pacotes seguem.
Um clone a partir do escritório funciona, o mesmo clone através de um hotspot do telemóvel funciona, e o mesmo clone a partir de uma rede de hotel fica pendurado até se ligar uma VPN. O aperto de mão SSH termina e a sessão fica silenciosa na primeira transferência real. Uma linha acrescentada à configuração do cliente cura o git e o ssh ao mesmo tempo. Quando uma única definição do cliente repara várias ferramentas de uma vez, a falha está naquilo que o cliente envia, não na ligação através da qual o envia.
Leia o sintoma como uma diferença de encaminhamento
Um túnel que cura um problema raramente é uma reparação. Troca a rota, o operador e os equipamentos intermédios, enquanto o portátil continua a produzir exatamente os mesmos pacotes. Se uma rota trata mal um cabeçalho e outra o deixa passar intacto, a diferença está na política do equipamento intermédio, não no cliente. Aqui o túnel é uma testemunha, não uma solução.
O ponto onde a sessão morre restringe ainda mais. Nada que falhe na resolução de nomes ou na troca de chaves se parece com isto. Uma sessão que se autentica, imprime um banner e depois congela na primeira escrita grande já provou que o encaminhamento, os nomes e as credenciais funcionam todos.
O cliente estampa um byte QoS em cada socket SSH
Toda a ligação OpenSSH desde a 7.8 transporta no cabeçalho IP um valor que os routers podem usar para priorizar o tráfego. As sessões de terminal recebem um valor e as cópias massivas outro, segundo a teoria de que uma pessoa a escrever merece melhor tratamento do que uma transferência de ficheiros. A maioria das redes ignora completamente a sugestão, e é por isso que passa despercebida durante anos. Uma minoria de controladores Wi-Fi, operadores móveis e concentradores VPN age sobre ela, e alguns fazem-no mal.
Quando esse valor é reescrito ou descartado a meio do fluxo, a ligação não falha, apenas deixa de avançar. As retransmissões sobem, a janela desaba e a aplicação não comunica nada porque nada devolveu um erro. Esse silêncio é a razão pela qual as pessoas descrevem o sintoma como um bloqueio e não como uma falha.
Confirme primeiro a versão do cliente com ssh -V. Qualquer versão a partir da 7.8 traz este comportamento por predefinição.
Três comandos que separam isto do MTU e do DNS
Dois casos semelhantes merecem ser excluídos antes de editar qualquer ficheiro de configuração. Uma falha de MTU deixa passar as trocas pequenas e congela no primeiro pacote grande, enquanto uma falha de nomes nunca produz uma sessão.
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 repete a operação que falha com a marca desligada, e uma execução bem-sucedida é a prova isolada mais forte de que dispõe. O segundo imprime a configuração que o cliente vai realmente aplicar a esse destino, o que apanha uma entrada obsoleta num ficheiro que tinha esquecido. O terceiro mostra o byte TOS nos dois sentidos enquanto a transferência está presa, e o padrão interessante é um valor na rota avariada e nenhum na que funciona.
Faça a captura no portátil e não no servidor, porque é o emissor que define o valor e qualquer dos sentidos o pode alterar. Compare uma rota que funciona e uma que falha com a mesma captura, e a diferença aparece sem adivinhar.
Coloque a exceção num único ficheiro, um anfitrião de cada vez
Uma exceção pertence ao lado do anfitrião a que se aplica, com um comentário que diga porque existe.
Host gitlab.example.internal
IPQoS none
# direct route rewrites the marking; the tunnel route passes it
O âmbito importa mais do que o valor em si. Uma entrada com caráter universal desliga o comportamento em todo o lado, deita fora uma sugestão que ajuda em redes bem comportadas e não deixa ninguém capaz de dizer quando apareceu. Uma entrada por anfitrião é legível, reversível e trivial de apagar depois de a rede estar reparada. Use o ficheiro do utilizador para uma solução pessoal e um ficheiro gerido quando toda uma frota precisa da mesma exceção.
Seja explícito quanto ao que a exceção não cobre. Aplica-se ao SSH, por isso um remoto HTTPS, um espelho de pacotes e um navegador ficam todos de fora, e uma falha em qualquer deles exige a sua própria prova. Numa cadeia através de um bastião, cada salto usa a configuração do cliente, e o salto que trava é o que vale a pena circunscrever.
Feche o ciclo com o responsável da rede
Entregue a descoberta como quatro factos: versão do cliente, rota testada, cliente VPN em uso e que sentido transportava a marca. Esses quatro bastam a um responsável de rede para reproduzir o tratamento e decidir se é deliberado.
Se a exceção não curar o bloqueio, remova-a. Uma solução que sobrevive a uma experiência falhada torna-se lenda, e a pessoa seguinte passa uma hora a provar que não faz nada. Se curar o bloqueio, o caminho continua errado para qualquer outra ferramenta que o atravesse, e a reparação pertence a quem opera o equipamento intermédio.
A alteração no cliente é um remendo com data de validade. Escreva essa data no comentário.