Помогите, пожалуйста, разобраться в коротком tcpdump

для начала, работоспособность днс проверь в момент долгих подключений :)

Это не ДНС. Делается запрос по IP-адресу. Я сократил сообщение для краткости, по третьей ссылке там показал, чтобы портянку сюда не копировать. Видно так же, что ДНС-запросы, если уж о них - ходят совершенно нормально, к нескольким днс-серверам в интернете, которые проверял. Но в тесте и, соответственно, в дампе всё по IP адресу. В нормальных условиях весь вызов программы curl для HEAD запроса (у ответа на него нет тела) укладывается в 7 пакетов - там нет резолва.

в iptables что в этот момент?

в iptables что в этот момент?

В этот момент firewalld был остановлен, в lsmod не было iptables.

Я всё перепробовал, т.к. проблема почти каждый день, плюс выгружал всё, что теоретически могло бы влиять: модули от vmware player, virtualbox, kvm.

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_timestamps = 0

Я так понял, имеется в виду выполнить «sysctl -w net.ipv4.tcp_timestamps=0» Записал, попробую.

Да.

Может кто-то подскажет, каков смысл пакетов, помеченных «R» и «S»? Что может приводить к их появлению в моем случае?

S (SYN) R (RST)

проблема на железе или на виртуалке?

Хм .Т.е. на человеческом языке вопрос будет звучать примерно так: «по прошествии какого-то времени у меня перестает осуществляться TCP handshake - моя система сама сбрасывает частично установленное соединение».
Похоже на исчерпание какого-то ресурса, вот только понять бы, какого.
В системных логах какие-нибудь вопли есть? На момент начала глюков какое число активных/закрывающихся соединений?

проблема на железе или на виртуалке?

На хосте.

S (SYN) R (RST)

Я нагуглил это, да, но я про сети последний раз что-то слышал лет 10 назад, когда прогуливал институт. С чего бы вдруг этим ресетам идти.

«по прошествии какого-то времени у меня перестает
осуществляться TCP handshake - моя система сама сбрасывает
частично установленное соединение».

Спасибо вам что распознали и сформулировали проблему.

Похоже на исчерпание какого-то ресурса, вот только понять бы, какого.

Может ли быть такое, что некий модуль, приводит ядро в такое состояние? Причем rmmod модуля не исправляет ситуацию? Устройство ядра/сетевого стека допускает такую деградацию? Или это невозможно?

В системных логах какие-нибудь вопли есть?

Извините за глупый вопрос, но что есть системные логи? В /var/log/ множество файлов.

На момент начала глюков какое число активных/закрывающихся соединений?

Я посмотрю в следующий раз, какой командой? Не думаю, что большое. Торренты не были запущены. Но в фоне играет радио по http. Внутри виртуалок только nginx и php, но они смотрят только внутрь да и нагрузки нет фактически.

Может ли быть такое

Да все может быть, наверное. Может, это драйвер глючит.

что есть системные логи? В /var/log/ множество файлов.

/var/log/messages, на седьмом центосе - journalctl --system

какой командой?

netstat -nt | wc -l

Но вообще хрен его знает, что там происходит.

Спасибо вам!

Видимо, полезно будет еще по очереди полностью исключать: vbox, vmware, sshfs и nfs до виртуалок. Просто работать еще надо же как-то.

возможно следующие параметры sysctl

«по прошествии какого-то времени у меня перестает осуществляться TCP handshake - моя система сама сбрасывает частично установленное соединение».

net.ipv4.tcp_keepalive_time = 7200 (2 часа)

начинают устанавливаются невероятно долго (до 100 секунд), в локалке всё нормально.

net.ipv4.tcp_keepalive_intvl = 75 (секунд)
net.ipv4.tcp_keepalive_probes = 9 (попыток)

попробуй уменьшить эти параметы до считанных минут-секунд

Спасибо всем участвовавшим за советы!

Слабое знание сетей не позволяет понять, из-за провайдера это или из-за домашней «точки доступа», но проблема действительно решается указанием net.ipv4.tcp_timestamps=0 (на постоянной основе можно занести в файл /etc/sysctl.conf) Проблема встречается часто, но плохо гуглится.

Пользователь post-factum либо вгляделся в дамп, либо догадался по увязке возникновения глюков с аптаймом системы. За что ему отдельная благодарность.

Пользователь post-factum сталкивался с похожим на предыдущей работе, и в результате усиленного гугления за пару часов нашёл подходящее решение. С тех пор и запомнил.

P.S. Это из-за провайдера.

Почему из-за провайдера, если соединение сбрасывает машина ТС

Причины, к сожалению, мне не совсем понятны. У меня было так, что смена провайдера как раз убирала проблему. Видимо, особенности работы промежуточных маршрутизаторов.

А ведь действительно, по дампу видно (теперь, когда я знаю, куда смотреть) что дело в timestamp'ах.

Наверное, провайдерское оборудование работает не как маршрутизатор, а как tcp-прокси, причем кривой.

По идее, netstat -s показал бы причину дропов, да как-то я не подумал об этом вчера.

Насколько я понял в результате гугления, одна из версий такова: что-то за пределами моего компьютера изменяет метки времени в приходящих пакетах, операционке эта разница не нравится, пакеты признаются плохими и подтверждение установки соединения не признается. Эти промежуточные манипуляции становятся проблемой только по мере нарастания значений самих меток, которые напрямую зависят от аптайма машины которая пытается установить соединение, т.к. значения инкрементируются каждые 0,1-1 секунду (у разных ОС/оборудования по разному, по ним можно даже определить тип ОС наблюдая за проходящими пакетами). На винде этой проблемы нет, т.к. винда изначально не встраивает эти метки и, соответственно, не контролирует в дальнейшем их значения во входящих пакетах. Либо встраивает, но имеет другую политику реинициализации счетчика.

Возможно роутер, возможно где-то у провайдера (шейпинг, сорм, и т.д.), возможно где-то дальше - за пределами сети провайдера. Можно проверить исключив роутер, но лень проверять.

Вообще я тут подумал, что грамотные сетевики могли бы проверить это так: поднять любой сервер, сходить туда и сделать там tcpdump и убедиться, что кто-то портит метки.

Это мое приблизительное понимание.

Обычно маршрутизаторы не лезут внутрь пакетов, резве что nat сделать. Сделай до проблемного хоста traceroute по icmp и по tcp используя 80 порт. Может на пути стоит прозрачный прокси.

root@swelf-work:~# traceroute -n 184.168.27.118
traceroute to 184.168.27.118 (184.168.27.118), 30 hops max, 60 byte packets
 1  192.168.4.1  0.899 ms  0.869 ms  0.846 ms
 2  195.239.*.*  2.576 ms  2.590 ms  2.568 ms
 3  79.104.226.43  20.575 ms  20.539 ms 79.104.227.43  20.469 ms
 4  62.141.106.228  38.395 ms  38.774 ms  38.369 ms
 5  10.2.2.2  37.380 ms  37.353 ms  37.268 ms
 6  * * *
 7  * * *
 8  * * *
 9  4.34.191.254  223.160 ms  222.833 ms  222.799 ms
10  184.168.0.69  213.758 ms  214.821 ms  213.767 ms
11  184.168.0.73  217.461 ms  216.999 ms  214.923 ms
12  * * *
13  * * *
14  *^C
root@swelf-work:~# traceroute -n -T -p80 184.168.27.118
traceroute to 184.168.27.118 (184.168.27.118), 30 hops max, 60 byte packets
 1  184.168.27.118  1.197 ms  1.066 ms  1.045 ms

Как пример мой вывод, у меня стоит прозрасный прокси, и как видишь вывод отличается.