Я запускаю несколько виртуальных машин в Azure. Виртуальные машины работают в подсети с NSG. Сетевые карты не используют NSG, мы не используем ускоренную сеть.
Я заметил, что когда виртуальная машина взаимодействует с другой виртуальной машиной в той же подсети, используя TCP, значение MSS в пакетах SYN уменьшается на 42. Это означает, что если я отправлю TCP SYN с MSS=876 на другую виртуальную машину в той же сети, другая виртуальная машина захватит TCP SYN с MSS=834:
Клиент:
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: флаги [S], seq 3092614737, win 17520, параметры [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], длина 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: флаги [S.], seq 1710658781, ack 3092614738, win 28960, параметры [mss 1418, sackOK, TS val 3901957431, wopscale, 3901957431 ecr ], длина 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], длина 0
Сервер:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: флаги [S], seq 3092614737, win 17520, параметры [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], длина 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Флаги [S.], seq 1710658781, ack 3092614738, win 28960, параметры [mss 1460, sackOK, TS val 3901957431, val 3901957431 ecr ], длина 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], длина 0
Мы используем несколько NVA, и наши SYN-пакеты проходят через несколько переходов, и мы фактически видим, что MSS уменьшается несколько раз, мы первоначально измеряли сокращение на 84, в некоторых случаях мы также измеряли снижение на 138 (действительно, не кратное 42), то есть мы снижаем эффективность нашей сети более чем на 10%.
Я провел некоторое время, наблюдая, как различные сетевые устройства взаимодействуют с MSS. В большинстве случаев для MSS устанавливается фиксированная величина либо путем фиксирования статического значения, либо до MTU пути. PaloAlto будет использовать «корректировку» относительно MTU сетевого интерфейса, который является фиксированным значением. Arista позволит вам установить максимальное значение для входящего или исходящего трафика, опять же абсолютные значения. Некоторые поставщики брандмауэров, такие как PaloAlto, будут уменьшать MSS в случае DoS-атаки и активации файлов cookie SYN, но в этом случае MSS будет одним из 8 возможных значений.
Я считаю, что этот механизм MSS = 42 ломает TCP: если клиент поддерживает большие кадры и отправляет MSS 8860, сервер в Azure получает 8876, сам отвечает 1330, но клиент получает 1246, клиент согласится, что пакеты должны иметь 1246 байт. полезной нагрузки, в то время как сервер отправит 1330 байт полезной нагрузки.
Самая большая проблема в том, что у нас есть случаи, когда трафик работает «случайно».Зажим не выполняется должным образом на стороне экспресс-маршрута, но из-за этого -42 здесь и там MSS фактически уменьшается до значения, которое «подходит», до тех пор, пока не произойдет небольшое изменение в способе маршрутизации пакетов, и вы обнаружите вдруг где-то была неправильная конфигурация.
Есть идеи, как объяснить это сокращение? Я считаю, что это поведение нигде не задокументировано.
РЕДАКТИРОВАТЬ
Просто читаю RFC879
MSS может использоваться совершенно независимо в каждом направлении потока данных. В результате могут быть совершенно разные максимальные размеры в двух направлениях.
Так что это выглядит законно в соответствии с RFC. Все-таки странное поведение.
