Нет ответа на некоторые пакеты SYN, когда включены временные метки

У меня есть TCP-сервер, прослушивающий машину («сервер») под управлением Ubuntu 12.04.3 (ядро 3.8.0-31-generic). Он получает соединения от 2 разных клиентских машин. На машине A работает Ubuntu 12.04.4 (3.11.0-17-generic), а на машине B работает Ubuntu 11.10 (3.0.0-32-сервер).

Если на сервере включены временные метки TCP (sysctl net.ipv4.tcp_timestamps = 1), то иногда пакеты SYN с компьютера A «игнорируются». Используя tcpdump на сервере (в не смешанном режиме), я вижу, что SYN приходят нормально и с правильными контрольными суммами - просто нет ответа - нет SYN / ACK и нет RST. Машина A повторно передает SYN несколько раз, прежде чем сдаться. Клиентское программное обеспечение, работающее на компьютере A (в данном случае, wget), немедленно повторяет попытку с новым подключением и успешно, получая мгновенный SYN / ACK.

У компьютера B нет проблем с тем же сервером, и его трафик выглядит нормально - он использует те же параметры TCP, что и компьютер A (из того, что я вижу из файлов захвата). Отключение меток времени TCP на сервере заставляет все работать как надо.

Тем не менее, временные метки в игнорируемых пакетах SYN кажутся мне действительными, поэтому я не уверен, почему они вызывают проблемы или вообще являются их основной причиной.

Я поместил здесь анонимный pcap https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . Он был сделан на сервере (10.76.0.74), показывая, что машина A (10.4.0.76) успешно выполняет HTTP GET (пакеты с 1 по 10), а затем через 1 секунду пытается снова получить тот же URL-адрес (пакеты с 11 по 17), но вместо этого его SYNs игнорируются. Пакеты с 18 по 27 - это еще один успех.

Я подозреваю, что это проблема, аналогичная той, которая описана в разделе « Почему сервер не отправляет пакет SYN / ACK в ответ на пакет SYN », и, хотя отключение меток времени - это обходной путь, я хотел бы понять, что происходит. Это просто ошибка?

Не работает локальный брандмауэр. Сервер обрабатывает довольно много TCP-соединений (около 32 Кбайт одновременно), но имеет много свободной памяти / ЦП. Во время теста, показанного в pcap, не было никаких других соединений TCP между машиной A и сервером. Нет никаких признаков того, что очередь приема серверного приложения внезапно заполняется (кроме того, это должно повлиять на обоих клиентов, я бы предположил). Когда пакеты выглядят нормально в pcap, взятом на сервере, не похоже, что вмешивающееся сетевое устройство ломает вещи.

Первоначально я разместил это на форумах Ubuntu, но в ретроспективе это может быть более подходящим местом. Надеясь на заем ключа.

tcp timestamp syn

— user133831
источник

В моем случае следующая команда устранила проблему с отсутствующими ответами 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.

— LAV
источник

Все рассматриваемые машины были модернизированы, и я считаю, что проблема больше не возникает, поэтому я не могу попробовать это сейчас. Однако в этом случае между клиентом и сервером не было задействовано NAT. Это по-прежнему кажется мне подозрительной ошибкой.

— user133831