Axuste de MSS de TCP nunha pasarela Linux IPsec: que corrixe

O ping funciona, o SSH funciona, unha páxina pequena cárgase e, daquela, cada resposta grande queda colgada ata esgotar o tempo. O patrón clásico apunta ao tamaño do paquete e non á accesibilidade: a ruta transporta o apretón de mans e os primeiros kilobytes, e despois un segmento de tamaño completo desaparece. Nunha pasarela Linux IPsec, unha regra TCP MSS adoita ser a solución, pero só se entende o que cambia e onde está realmente o paquete que toca. A orde de abaixo segue o paquete desde o síntoma ata a colocación da regra, para que poida deter cando a explicación deixe de encaixar.

O síntoma que suxire MSS

TCP negocia un tamaño máximo de segmento no apretón de mans. Se ese valor é maior do que a ruta pode transportar tras a encapsulación, o emisor segue producindo segmentos que nunca chegan, e a conexión atasca tras o primeiro intercambio. As respostas pequenas caben; as grandes non.

A retroalimentación ICMP pode rescatar a conexión mediante o descubrimento do MTU da ruta, e un devasado que descarta esas mensaxes converte o atasco nun burato negro silencioso. Por iso o mesmo túnel funciona para unha aplicación e falla para outra sen ningunha diferenza evidente na configuración.

Que fai unha regra TCPMSS e que non fai

A regra reescribe a opción MSS nos paquetes do apretón de mans TCP ao seu paso. Non fixa o MTU da interface do túnel, non cambia a política IPsec e, nos núcleos actuais, só baixa un valor anunciado en lugar de subir un que xa é menor. Ademais só toca TCP; as cargas UDP, o comportamento de DNS e os selectores de tráfico negociados quedan fóra do seu alcance.

Como o cambio ocorre durante o apretón de mans, unha conexión existente establecida antes da regra conserva o seu valor antigo. Probe cunha conexión nova e espere que o primeiro intento tras o cambio sexa o que lle diga algo. Nada da regra chega a unha conexión que xa está aberta. Por iso unha corrección aplicada no medio dun incidente pode parecer que non fixo absolutamente nada.

Poña a regra na ruta TCP interior

Nunha pasarela Linux baseada en políticas, o paquete reenviado segue parecendo TCP normal cando o ve o devasado. A política IPsec decide que o paquete será protexido; o devasado non ve unha cabeceira ESP para o fluxo interior, así que comparar con ESP aquí describe un paquete completamente distinto. Esa discordancia é a razón de que algunhas regras parezan correctas e nunca coincidan.

En termos de iptables, a regra pertence á táboa mangle na ruta de reenvío, restrinxida aos paquetes do apretón de mans: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. O número é un exemplo, non unha constante universal; deríveo do custo de encapsulación e do MTU real da ruta. Un equivalente de nftables fixa o tamaño máximo de segmento nunha cadea forward ou postrouting.

Manteña as regras de escoita externas para IKE e ESP separadas das regras de reenvío internas. Unha soa regra que tenta autorizar tanto o fluxo da aplicación como o protocolo externo acaba sen coincidir de forma fiable con ningún dos dous.

Respecte o propietario do devasado e a orde de NAT

Se UFW xestiona o devasado do host, engada os cambios de mangle e reenvío mediante a súa configuración persistente compatible en lugar de escribir un comando que desaparece na seguinte recarga. Unha regra inserida na táboa equivocada ou despois dunha regra terminal non ten efecto, e a táboa activa ocúltallo.

A tradución de orixe é unha decisión aparte que a miúdo interactúa con esta. Unha excepción colocada antes dunha regra xeral de masquerade evita que o tráfico protexido perda a orixe que esixe a súa política; non repara un problema de tamaño, e unha regra de tamaño non repara un problema de tradución.

Verifique de forma estreita e logo detéñase

Abra unha conexión nova ao servizo que falla e observe tanto a aplicación como os contadores da regra. Se o atasco desaparece, ten probas sobre esa ruta TCP con esa encapsulación. Non ten probas de que encaixe cada protocolo VPN, de que estea arranxada cada aplicación UDP nin de que un servizo concreto augas arriba fose a causa orixinal.

Deixe que a retroalimentación de tamaño por ICMP siga funcionando onde a política o permita, e trate con coidado o axuste automático baseado no MTU da ruta cando a ruta IPsec externa non está representada pola ruta interior. Canto máis estreita sexa a conclusión, máis fácil será diagnosticar o seguinte incidente.