Случайная метка времени при первой синхронизации при обратной петле

Предисловие

Мы тестируем IPS на базе хоста. В этом тестовом примере наше приложение прослушивает обратную петлю, и приложение получает трафик в виде открытого текста. Мы используем либо nginx, либо haproxy для завершения TLS в общедоступном интерфейсе. Наш IDP будет отслеживать петлю, чтобы видеть незашифрованный трафик.

Наш IDP видел искаженные / неправильные даты, поэтому мы начали копать глубже.

[Обновление 2] Как упоминал @kasperd, tcpdump получает временные метки из ОС. Тем не менее, оказывается, эта ошибка фактически вызывает отключение IDP в дополнение к tcpdump. Он видит connection_established, но не может увидеть действительный сеанс http, так как syn-ack недействителен.

Ошибка была зарегистрирована на redhat.com и centos.org.

Наблюдение

Первая синхронизация по шлейфу всегда имеет дату, близкую к началу эпохи, или в пределах 2 лет от нее на виртуальных машинах. Это сильно отличается от Декабрь 1970 г. к Февраль 1973 г. на виртуальных машинах и далеко в будущем на голых железных серверах Xeon. NTP правильный на всех наших виртуальных машинах и серверах без операционной системы дрейф менее 50 мс.

Это происходит только на кольцевой проверке. Мы никогда не видим этого на bond0 на серверах или eth0 на виртуальных машинах.

Тестовые серверы и ноутбуки

ОПЕРАЦИОННЫЕ СИСТЕМЫ: CentOS 7

Платформы:

Серверы Dell 20 Core Xeon (ОС без операционной системы)

Серверы HP 20 Core Xeon (ОС без операционной системы)

VirtualBox в MacOS

Hyper-V в Windows 10 Enterprise на Lenovo P50 с 6 виртуальными ядрами.

Один роутер на базе Celeron 4 Core 1,6 ГГц (не воспроизводится на Celeron)

Действия по воспроизведению

На каждой платформе мы запускаем веб-прослушиватель на 80-м порту петли.

./simple_python 127.0.0.1 &

Код выше Вот

Затем запускаем tcpdump

tcpdump -p -NNnn -XXxx -tttt -vv -s0 -c2 -i lo &

Затем скручиваем на localhost

curl -s -o /dev/null http://127.0.0.1/

Вывод

2018-04-10 21:05:30.087769 IP (tos 0x0, ttl 127, id 49233, offset 0, flags [DF], proto TCP (6), length 60)
    127.0.0.1.25134 > 127.0.0.1.80: Flags [S], cksum 0xfe30 (incorrect -> 0xce27), seq 4053136920, win 65495, options [mss 65495,sackOK,TS val 22951497 ecr 0,nop,wscale 13], length 0
    0x0000:  0000 0000 0000 0000 0000 0000 0800 4500  ..............E.
    0x0010:  003c c051 4000 7f06 3d68 7f00 0001 7f00  .<.Q@...=h......
    0x0020:  0001 622e 0050 f195 f618 0000 0000 a002  ..b..P..........
    0x0030:  ffd7 fe30 0000 0204 ffd7 0402 080a 015e  ...0...........^
    0x0040:  3649 0000 0000 0103 030d                 6I........
1973-02-14 22:12:10.785902 IP (tos 0x0, ttl 127, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    127.0.0.1.80 > 127.0.0.1.25134: Flags [S.], cksum 0xfe30 (incorrect -> 0x2f28), seq 3928063281, ack 4053136921, win 65483, options [mss 65495,sackOK,TS val 22951497 ecr 22951497,nop,wscale 13], length 0
    0x0000:  0000 0000 0000 0000 0000 0000 0800 4500  ..............E.
    0x0010:  003c 0000 4000 7f06 fdb9 7f00 0001 7f00  .<..@...........
    0x0020:  0001 0050 622e ea21 7d31 f195 f619 a012  ...Pb..!}1......
    0x0030:  ffcb fe30 0000 0204 ffd7 0402 080a 015e  ...0...........^
    0x0040:  3649 015e 3649 0103 030d                 6I.^6I....

В любом случае синхронизация всегда происходит между 1970 и 1973 годами на виртуальных машинах и в будущем на Xeon.

• Я могу воспроизвести это 100% времени на каждой из платформ, кроме Celeron. Мы не используем Celeron в дата-центре. Я просто пытался найти что-то не затронутое.

Что еще я пытался избавить от этого?

• Я пробовал прикреплять приложения к ядру, используя taskset.
• Я пробовал устанавливать различные переменные, влияющие на libc, такие как TZ, LANG, LC_ALL и т. Д.
• Я попытался отключить все возможности разгрузки интерфейса, несмотря на то, что это обратная петля, и на самом деле они ничего не должны делать.
• Я пробовал несколько разных настроек sysctl.
• Я пробовал использовать другой снаплен в tcpdump. (Мне известны некоторые исторические проблемы, связанные с длиной snaplength)
• Я проверил, что аппаратные часы правильные.

Что я не пробовал

• Я не пробовал настраивать управление потоком приема, так как мы бы не стали делать это в наших дата-центрах без уважительной причины.
• Вероятно, есть множество других вещей, которые я мог бы попробовать, но это действительно похоже на какую-то ошибку libc / buffer / race condition.

Есть мысли о том, где в коде Linux это может происходить? Я не решаюсь копаться в glibc, поскольку я не разработчик C.

[Обновить] Кажется @jackthecoiner нашел где-то еще тоже сталкивается с этой проблемой и пока не получал никаких отзывов на сайте Redhat.