MSS clamping nunha pasarela VPN: que arranxa e que non
O clamping reescribe o MSS nos handshakes TCP para que os segmentos caiban no túnel. Nunca arranxa UDP nin unha comprobación path-MTU rota. Tres comprobacións, por orde.
As peticións pequenas funcionan, as descargas grandes colgan e alguén suxire MSS clamping. Esa suxestión acerta con suficiente frecuencia como para merecer unha proba na orde correcta, e falla coa suficiente como para facerlle perder unha tarde se a aplica ás cegas. As tres comprobacións de abaixo separan un problema real de tamaño TCP dun problema de UDP, dun descubrimento path-MTU roto e dun clamp que nunca ve o handshake que debería reescribir.
Empece pola forma do fallo
Un fallo de tamaño ten sinatura: a conexión establécese, a autenticación e as respostas pequenas teñen éxito, e despois unha transferencia atáscase indefinidamente en canto necesita un segmento de tamaño completo. As páxinas que cargan texto pero nunca rematan unha imaxe son o mesmo fallo a menor escala. Se non se conecta nada de nada, o problema está antes na ruta e o clamping non axudará. Un clamp non pode reparar un handshake que nunca chegou.
A sinatura existe porque o handshake é onde se acorda o tamaño do segmento. Cada lado anuncia un tamaño máximo de segmento como opción TCP, e os emisores respectan o anuncio do par. Se a ruta non pode transportar un segmento tan grande, o fallo aparece máis tarde, cando o emisor por fin o tenta.
Manteña o transporte á vista mentres le ese síntoma. O clamping é unha reescritura dunha opción TCP, así que unha chamada de voz ou vídeo que se atasca baixo o mesmo túnel non é un problema de MSS e non mellorará por iso. Anote o transporte antes de tocar unha opción TCP.
Ponlle prezo á ruta e compáraa co túnel
Dous números importan e a miúdo confúndense. A path-MTU é o paquete máis grande que a ruta transportará sen fragmentación, e o MSS anunciado para IPv4 é ese valor menos os 40 bytes de cabeceiras IP e TCP, ou menos 60 para IPv6. A encapsulación do túnel consome parte do orzamento antes de que o paquete interior sequera comece.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20O ping co bit do-not-fragment dille se sobrevive un paquete dese tamaño de carga útil; axuste o tamaño ata que falle e terá atopado o límite da ruta empiricamente. A saída de tracepath informa do MTU descuberto ao longo da ruta, que é máis rápido cando funciona e menos fiable cando un salto intermedio filtra as sondas.
Agora reste a sobrecarga do túnel. Unha cabeceira IP exterior, unha cabeceira UDP e unha cabeceira específica do túnel saen todas dos mesmos 1500 bytes, así que o MTU interior utilizable nunha base Ethernet típica é máis baixo do que suxire a ligazón física. Se o MTU interior calculado é inferior ao que anuncian os seus pares, atopou un candidato real a clamp e non unha conxectura. Se o valor calculado xa está por riba do que anuncian os pares, detéñase aquí e busque noutro sitio.
Coloque o clamp onde pasa o handshake
Un clamp funciona reescribindo a opción MSS nos paquetes SYN e SYN-ACK mentres cruzan a pasarela. Se a regra se asenta nunha interface que ningunha das dúas direccións atravesa nunca, a negociación complétase sen cambios e o síntoma persiste, por iso a colocación decide o resultado máis que o valor.
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
A dirección é a outra metade. Aplicar clamp nunha soa dirección arranxa a metade dos fluxos e deixa o resto fallando dunha forma que parece intermitente, así que aplíqueo ás dúas direccións do tráfico reenviado. A forma clásica en Linux para unha interface de túnel é unha regra mangle que coincide con paquetes SYN:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuFíxese no que --clamp-mss-to-pmtu fai en realidade: deriva o valor do MTU da ruta, que non sempre é o orzamento real de carga útil do túnel. Nun túnel baseado en ruta onde a ruta interior e a ruta exterior difiren, un valor explícito calculado na comprobación anterior é máis predicible ca un automático.
Verifique cunha conexión nova e manteña viva a retroalimentación
Unha conexión establecida conserva o MSS que negociou, así que probar na mesma sesión non demostra nada. Abra unha conexión nova tras o cambio e lea o valor negociado directamente en lugar de inferilo dunha transferencia que remata por casualidade.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSO primeiro comando informa do MSS do socket xunto co seu estado de conxestión, que é a confirmación máis rápida de que o clamp surtiu efecto. O segundo confirma que a regra que cre engadiu é a regra que existe, na táboa onde se colocou.
Despois protexa o mecanismo que non arranxou. O descubrimento path-MTU depende de que as mensaxes ICMP fragmentation-needed cheguen ao emisor, así que unha devasa que as descarte seguirá rompendo transferencias grandes mesmo cun clamp correcto. Permita esas mensaxes para a ruta do túnel, ou acepte que o clamping compensa unha política que vostede elixiu.
Por último, resista a tentación de tratar o clamp como un mando de axuste. Restrinxe o tamaño do segmento, o que custa rendemento en rutas que nunca o necesitaron. Aplicado tras as tres comprobacións é unha reparación dirixida; aplicado primeiro é un cambio que agocha o fallo orixinal e engade unha segunda variable a cada proba posterior. Ese intercambio merece facerse a propósito, non por defecto.
Anote a path-MTU que mediu, a sobrecarga do túnel que restou, a regra que engadiu e o MSS que viu despois. Catro números converten o seguinte incidente nunha consulta en lugar dunha investigación.