.png)
Estoy ejecutando varias máquinas virtuales en Azure. Las máquinas virtuales se ejecutan en una subred con NSG. Las NIC no utilizan NSG, no utilizamos redes aceleradas.
Noto que cuando una VM habla con otra VM de la misma subred usando TCP, el valor MSS en los paquetes SYN se reduce en 42. Eso significa que si envío un TCP SYN con MSS=876 a otra VM de la misma red, el otra VM capturará un TCP SYN con MSS=834:
Cliente:
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
Servidor:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
Estamos usando múltiples NVA, y nuestros paquetes SYN viajan a través de múltiples saltos, y de hecho vemos que el MSS se reduce varias veces, originalmente medimos una reducción de 84, también medimos una reducción de 138 en algunos casos (de hecho, no es un múltiplo de 42), eso significa que reducimos en más de un 10% la eficiencia de nuestra red.
He pasado algún tiempo observando cómo funcionan varios dispositivos de red con el MSS. En la mayoría de los casos, el MSS se establece en una cantidad fija, ya sea fijándolo a un valor estático o a la ruta MTU. PaloAlto utilizará un "ajuste" relativo a la MTU de una interfaz de red, que es un valor fijo. Arista le permitirá poner un valor máximo al tráfico de entrada o salida, nuevamente valores absolutos. Algunos proveedores de firewall como PaloAlto reducirán el MSS en caso de un ataque DoS y se activan las cookies SYN, pero el MSS será uno de los 8 valores posibles en ese caso.
Creo que este mecanismo MSS -= 42 rompe TCP: si el cliente admite tramas gigantes y envía un MSS de 8860, el servidor en Azure recibe 8876, él mismo responde 1330, pero el cliente recibe 1246, el cliente aceptará que los paquetes deben tener 1246 bytes. carga útil, mientras que el servidor enviará una carga útil de 1330 bytes.
El mayor problema es que tenemos casos en los que el tráfico funciona "por casualidad". La sujeción no se realiza correctamente en el lado de la ruta rápida, sin embargo, debido a esto -42 aquí y allá, el MSS en realidad se reduce a un valor que "se ajusta", hasta que hay un ligero cambio en la forma en que se enrutan los paquetes y usted descubre De repente, hubo una mala configuración en alguna parte.
¿Alguna idea de cómo explicar esta reducción? Creo que este comportamiento no está documentado en ninguna parte.
EDITAR
Solo leyendoRFC879
El MSS se puede utilizar de forma totalmente independiente en cada dirección del flujo de datos. El resultado pueden ser tamaños máximos bastante diferentes en las dos direcciones.
Entonces parece legítimo según RFC. Aún así, un comportamiento extraño.
Respuesta1
A diferencia de las redes físicas, las redes SDN consumen "bytes" adicionales para los encabezados de encapsulación (GRE). Las IP visibles son CA (dirección del cliente), pero también hay PA (dirección del proveedor) que requiere enrutamiento en el proveedor de la nube. Por lo tanto, verá menos MSS disponibles, ya que el proveedor de la nube aplica una sujeción TCP adicional en la infraestructura para que se realice el enrutamiento backend.