O HTTPS do contêiner trava numa VPN corporativa? Teste a perna DTLS

Dentro de um contêiner atrás de uma VPN corporativa, o DNS resolve, a página de login carrega, um endpoint de saúde responde e então uma requisição HTTPS trava até estourar o tempo limite. Reconstruir a imagem e mudar variáveis de proxy não altera nada, porque a parte que falha não está na imagem. O cliente autentica-se por um transporte e move dados em volume por outro, e só o segundo está quebrado.

Dois transportes, um sintoma confuso

Um cliente corporativo baseado em TLS normalmente autentica-se por uma conexão TLS comum e depois negocia um segundo canal de dados baseado em UDP para a sessão. Quando essa segunda perna funciona, a vazão e a latência melhoram. Quando é filtrada ou não cabe no caminho, tudo antes da transferência em volume dá certo e a transferência em si para, que é exatamente o padrão acima.

Um contêiner não muda essa negociação; muda o caminho que os pacotes externos percorrem. O host traduz o fluxo do contêiner, então os datagramas UDP saem de uma porta de origem diferente do socket local do cliente e voltam por uma entrada de tradução que expira num temporizador bem mais curto que um fluxo TCP estabelecido. Se o túnel funciona no host e falha no contêiner, compare esses dois fluxos antes de culpar a aplicação. Essa comparação resolve mais do que qualquer reconstrução de imagem.

Decida por experimento, não por intuição

O experimento mais barato desativa o canal de dados UDP e repete a requisição. Use o cliente de linha de comando em vez do invólucro de desktop, para que a flag seja realmente aplicada: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Se a requisição que travava agora conclui, a perna DTLS era o problema e o resto era ruído.

Confirme o resultado nos dois sentidos a partir do mesmo contêiner: uma requisição em volume com a flag e outra sem. Uma mudança de comportamento que segue a flag é evidência; uma página que acaba carregando não é.

Se a flag corrige, decida por quê

Três condições produzem o mesmo sintoma e pedem respostas diferentes. O caminho pode filtrar UDP por completo, o que faz da flag a resposta permanente correta para essa rede. O caminho pode permitir UDP mas descartar datagramas grandes, o que aponta para MTU e não para filtragem. Ou o caminho pode ter perdas suficientes para a perna UDP render pior que TCP, o que é uma decisão de capacidade e não de alcançabilidade.

Distinga-as antes de documentar uma gambiarra. A filtragem sobrevive a qualquer tamanho de pacote, problemas de MTU só aparecem acima de um limiar e a perda se manifesta como retransmissão e atraso variável, não como um travamento limpo. Cada teste estreita a causa sem mudar a configuração do cliente.

Verifique o tamanho do pacote antes de manter a gambiarra

Se a causa é o tamanho, a interface do túnel aceita pacotes que o caminho não consegue carregar, e o problema volta em qualquer transporte assim que as cargas crescem. Compare as interfaces: ip link show tun0 no host, depois docker network inspect bridge para ler o MTU registrado nas opções de rede. Uma ponte de contêiner ainda em 1500 bytes sob um túnel que carrega menos é o achado habitual.

Sonde para cima a partir de um tamanho bom conhecido com um teste de não fragmentação dentro do túnel, depois baixe o MTU da rede do contêiner ou limite o MSS do TCP no túnel. Qualquer das duas correções costuma tornar o caminho UDP utilizável de novo e remove a necessidade da flag, que é o melhor resultado quando a filtragem não é a causa.

Decida o que você aceita trocar

Com o canal de dados desativado, o túnel carrega sua carga dentro de uma conexão TCP. Num caminho limpo isso é apenas mais lento; num com perdas, um único segmento perdido atrasa tudo o que vem atrás e a retransmissão externa compete com a interna. Essa troca serve para desenvolvimento interativo e chamadas de API pequenas, e combina mal com transferências em volume ou sessões longas por links móveis.

Qualquer que seja a opção escolhida, registre qual transporte o túnel acabou usando e por quê. Um contêiner que depende em silêncio de uma flag que alguém adicionou meses atrás é a próxima queda, e quem for depurá-la não saberá se a flag era uma gambiarra para filtragem ou um resto de experimento de MTU.