Много разных временных меток TCP через устройство NAT заставляют сервер отбрасывать пакеты (PAWS)

Question

Много разных временных меток TCP через устройство NAT заставляют сервер отбрасывать пакеты (PAWS)

Различные рабочие станции за брандмауэром трансляции сетевых адресов (NAT) на стороне клиента отправляют информацию о временной метке пакета TCP на наш сервер. Пакеты от многих рабочих станций приходят с несоответствующими временными метками из-за устройства NAT. Когда они поступают на наш сервер - в некоторых случаях на один и тот же порт - сервер не может отличить эти пакеты от других, поступающих на тот же порт и от того же IP-адреса клиента (устройства NAT).

Сервер интерпретирует пакеты с метками времени непоследовательности как принадлежащие соединению, которое уже было завершено, и пакет затем игнорируется - но в этом случае это не должно быть. Тезисы являются законными пакетами от рабочих станций за устройством NAT. Удаление пакетов со старыми значениями меток времени - это особая функция TCP, называемая PAWS ( http://www.ietf.org/rfc/rfc1323.txt, Защита от упакованных последовательностей) - сервер просто предполагает, что пакет старый, и он уже разобрался со связью.

Чтобы обойти это, мы отключили настройки меток времени на наших серверах. НО - что является лучшей практикой для этой ситуации? Следует ли отключить поддержку меток времени на всех серверах? Или все устройства NAT должны удалять или перезаписывать значения меток времени? Или же?

2

nat tcp timestamp

Источник

user93453 01 сен '11 в 20:22

2 ответа

Другие вопросы по тегам nat tcp timestamp

Shane Madden 01 сен '11 в 21:21 2011-09-01 21:21 · Answer 1 · 2011-09-01 21:21

Порт источника является дополнительной функцией идентификации для соединения TCP, и никаким двум соединениям за устройством NAT не должен назначаться один и тот же порт источника - клиенты никогда не будут мешать соединениям друг друга, если им не предоставлен один и тот же порт источника плохим устройством NAT,

PAWS не должен отбрасывать нужные пакеты, он просто дублирует повторную отправку - доставка по порядку не обновляет минимальное время. Значение времени копируется из последнего последовательного сегмента; Пакет с более высоким порядковым номером (т. е. тот, который необходим) должен всегда иметь более высокую временную метку, чем пакет с более низким порядковым номером.

Если он находится в правильной последовательности, но имеет более низкую временную метку, то это неверно ведет себя клиент TCP - и если по какой-то странности PAWS выбрасывает хорошие последовательные пакеты, то клиент должен повторно отправлять новую метку времени, восстанавливаясь после любого проблемы, которые были вызваны сбросом.

Какое поведение вы видите, что привело вас к этой проблеме?

lav 27 июн '16 в 13:45 2016-06-27 13:45 · Answer 2 · 2016-06-27 13:45

В моем случае следующая команда устранила проблему с отсутствующими ответами SYN/ACK с сервера Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Я думаю, что это более правильно, чем отключение меток времени TCP, так как метки времени TCP полезны (PAWS, масштабирование окна и т. Д.).

Документация на tcp_tw_recycle в явном виде заявляет, что не рекомендуется его включать, так как многие маршрутизаторы NAT сохраняют временные метки и, следовательно, запускается PAWS, поскольку временные метки с одного и того же IP не согласованы.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.