O HTTPS do contedor colga nunha VPN corporativa? Proba a pata DTLS

Dentro dun contedor detrás dunha VPN corporativa, o DNS resólvese, a páxina de inicio de sesión carga, un punto de comprobación de saúde responde e despois unha petición HTTPS colga ata esgotar o tempo de espera. Reconstruír a imaxe e cambiar as variables do proxy non cambia nada, porque a parte que falla non está na imaxe. O cliente autentícase por un transporte e move datos masivos por outro, e só o segundo está roto.

Dous transportes, un síntoma confuso

Un cliente corporativo baseado en TLS adoita autenticarse por unha conexión TLS normal e despois negocia unha segunda canle de datos baseada en UDP para a sesión. Cando esa segunda pata funciona, melloran o rendemento e a latencia. Cando se filtra ou non cabe pola ruta, todo o anterior á transferencia masiva ten éxito e a transferencia en si detense, que é exactamente o patrón anterior.

Un contedor non cambia esa negociación; cambia a ruta que toman os paquetes exteriores. O host traduce o fluxo do contedor, así que os datagramas UDP saen desde un porto de orixe distinto ao socket local do cliente e volven por unha entrada de tradución que caduca cun temporizador moito máis curto que un fluxo TCP establecido. Se o túnel funciona no host e falla no contedor, compara eses dous fluxos antes de culpar a aplicación. Ese comparación aclara máis que calquera reconstrución da imaxe.

Decide con experimentos, non con intuición

O experimento máis barato desactiva a canle de datos UDP e repite a petición. Usa o cliente de liña de ordes en lugar do envoltorio de escritorio, para que a opción se aplique de verdade: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Se a petición que colgaba agora se completa, a pata DTLS era o problema e o resto era ruído.

Confirma o resultado en ambos sentidos desde o mesmo contedor: unha petición masiva coa opción e outra sen ela. Un cambio de comportamento que segue a opción é evidencia; unha páxina que acaba cargando non o é.

Se a opción o arranxa, decide por que

Tres condicións producen o mesmo síntoma e esixen respostas distintas. A ruta pode filtrar UDP por completo, o que converte a opción na resposta permanente correcta para esa rede. A ruta pode permitir UDP pero descartar datagramas grandes, o que apunta ao MTU e non ao filtrado. Ou a ruta pode ter suficientes perdas como para que a pata UDP renda peor que TCP, o que é unha decisión de capacidade e non de alcanzabilidade.

Distingue entre elas antes de documentar unha solución alternativa. O filtrado sobrevive a calquera tamaño de paquete, os problemas de MTU só aparecen por riba dun limiar e a perda maniféstase como retransmisión e atraso variable, non como un colgado limpo. Cada proba acouta a causa sen cambiar a configuración do cliente.

Comproba o tamaño do paquete antes de manter a solución alternativa

Se a causa é o tamaño, a interface do túnel acepta paquetes que a ruta non pode levar, e o problema volve en calquera transporte en canto medran as cargas útiles. Compara as interfaces: ip link show tun0 no host, despois docker network inspect bridge para ler o MTU rexistrado nas opcións de rede. Unha ponte de contedor que segue en 1500 bytes baixo un túnel que leva menos é o achado habitual.

Sondar cara arriba desde un tamaño bo coñecido cunha proba de non fragmentación dentro do túnel, despois baixa o MTU da rede do contedor ou limita o MSS de TCP no túnel. Calquera das dúas correccións adoita facer que a ruta UDP volva ser utilizábel e elimina a necesidade da opción, que é o mellor resultado cando o filtrado non é a causa.

Decide que estás disposto a trocar

Coa canle de datos desactivada, o túnel leva a súa carga dentro dunha conexión TCP. Nunha ruta limpa iso é só máis lento; nunha con perdas, un só segmento perdido atrasa todo o que vai detrás e a retransmisión exterior compite coa interior. Ese intercambio encaixa co desenvolvemento interactivo e as chamadas de API pequenas, e encaixa mal con transferencias masivas ou sesións longas por enlaces móbiles.

Calquera que sexa a opción que elixas, anota que transporte acabou usando o túnel e por que. Un contedor que depende en silencio dunha opción que alguén engadiu hai meses é a próxima caída, e quen a depure non saberá se a opción era unha solución alternativa para o filtrado ou un resto dun experimento de MTU.