Почему не отправляется TCP/IP пакет с флагом RST?

Question

[Alex Efros]

Возможно я просто туплю, но мне всегда казалось, что если машина A посылает TCP-пакет машине B, который относится к (уже) не существующему TCP-соединению, то машина B должна ответить на него RST-пакетом (если, конечно, такие левые пакеты не DROP-аются файрволом, etc.). Но в данный момент я наблюдаю несколько иную картину, и не могу понять, то ли я что-то не знаю про TCP, то ли это какие-то баги в ядре линуха (честно говоря, традиционно грешил на conntrack, но отключение файрвола ничего не изменило).



Итак, есть два линух-сервера (назовём их A и B). Они подключены к одному (неуправляемому) свичу. Файрвол на обоих серверах изначально был включен (и использовался conntrack — "-m state --state NEW"), но потом я его сбросил (удалил все правила во всех таблицах и выставил ACCEPT по умолчанию во всех цепочках). Таким образом, ничего не должно блокировать/модифицировать пакеты между этими серверами.



Теперь, запускаем на сервере A TCP-сервис, который принимает входящие подключения и начинает непрерывно отправлять данные подключившимся клиентам. Он не пытается читать что-то от клиентов, и ожидает получить EPIPE при write() в клиента, который отвалился.



Далее, запускаем на сервере B TCP-клиент (обычный nc — netcat), он подключается к серверу A, начинает принимать от него данные, и тут мы отключаем nc (по Ctrl-C).



После этого TCP-сервис на сервере A блокируется при вызове write() в этого, уже отключившегося клиента, не получая (даже спустя пару минут) ни EPIPE ни другую ошибку.



Я погонял на обоих серверах tcpdump, и вот что он показывает:

1. после прерывается nc на сервере B, B посылает FIN на A, на который A корректно отвечает ACK-шкой — таким образом, на этом этапе мы получаем вполне корректное полу-открытое(одностороннее) TCP-соединение;
   
2. далее, A пытается продолжать отправлять данные B (обычными пакетами с флагами ACK и PSH,ACK) — что тоже ожидаемо и корректно;
   
3. НО, B никак на эти пакеты от A не отвечает (хотя B-то знает, что процесс nc уже вышел, так что это TCP-соединение уже закрыто/не существует, и, как я ожидаю, он должен ответить А RST-пакетом);
   
4. A, не получив никакого ответа, перестаёт принимать новые данные от TCP-сервиса (который в этот момент блокируется в вызове write()) и начинает перепосылать B пакеты с предыдущими данными (на которые тоже не получает никакого ответа от B).
   

Что интересно, если запустить и клиент и сервис на одном физическом сервере, то всё работает как я ожидаю — RST-пакет отправляется, сервис получает EPIPE при write() сразу после остановки nc по Ctrl-C.



Отсюда вопрос: из-за чего может не отправляться RST пакет когда клиент и сервис запущены на разных серверах (и правильно ли я понимаю, что он вообще обязан отправиться)?



На обоих серверах обновленный Hardened Gentoo Linux, ядро 2.6.39-hardened-r8, никаких специфичных сетевых настроек через sysctl нет.



Не знаю, важно ли это, но на обоих серверах достаточно большая сетевая активность — ` netstat -alnp` выдаёт порядка 5000 записей в любой момент, и, я думаю, порядка 1000 tcp-соединений устанавливается и разрывается каждую секунду. Эта активность не имеет отношения к описанному выше TCP-сервису — она относится к HTTP прокси (3proxy), причём в логах ядра на порт 3proxy постоянно выдаётся что-то в таком духе:




TCP: Possible SYN flooding on port XXXXX. Sending cookies.
net_ratelimit: 19 callbacks suppressed


Вот пример дампа описанной выше TCP-сессии: i54.tinypic.com/1zz10mx.jpg

Comments

[TheHorse]

> TCP/IP пакет
в заголвке, следует заменить на TCP. Сервер А — своя реализация? Может она recv==0 просто игнорит?

[Alex Efros]

Реализация сервера своя. Более того, она написана на Inferno/Limbo. Но это вроде бы не должно влиять на отправку или не отправку RST-пакета совершенно другим сервером. И локально-то RST отправляется. Что касается recv, то, как я уже написал в тексте вопроса, этот сервис вообще не делает read() из клиента, только write(). Так что да, сервис не считывает EOF когда отключается клиент, но вопрос-то не в том, как сервису определить что клиент отключился (тут для надёжности одного считывания EOF маловато будет, нужно таймаут на write() вешать), а почему нет EPIPE?

[TheHorse]

Я сейчас могу немножко запутаться в том что вы говорите (аббревиатуры позабывал), но надеюсь что следующая инфа будет в тему (если нет — утром попробую нормально разобраться):
В tcp для того, чтобы закрыть сессию передачи данных/сокет, нужно на любой стороне отправить запрос на закрытие и дождаться подтверждения закрытия (чуть более сложно все, но приблизительно так). Чтобы сервер понял, что клиент закрыл соеденение (сама ОС сделает если приложение kill -9), сервер должен иметь мультиплексор входных сокетов, и как только сокет готов к чтению и чтения инфы из него пустое (recv == 0) он должен послать сигнал подтверждения (closesocket), иначе, вроде, нарушение tcp протокола.

Answer 1

[bear11]

2.6.39-hardened-r8
Попробуйте последнее vanilla ядро с kernel.org
Возможно, с hardened они что-то накрутили.

Comments

[Alex Efros]

Я сейчас погонял под VMware Gentoo с парой старых ядер: 2.6.28-hardened-r9 работает стабильно и правильно (т.е. при прерывании nc по Ctrl-C отправляет FIN, и переводит соединение в состояние FIN_WAIT_2, а когда сервер присылает новые данные отправляет в ответ RST и переводит соединение в CLOSED); 2.6.32-hardnened-r22 работает по-разному — иногда при прерывании nc сразу вместо FIN отправляет RST (как сделала винда), а иногда отправляет FIN и игнорирует дальнейшие пакеты как описано в вопросе.

[Alex Efros]

Таки да, это hardened. Причём это не баг, а фича, включенная у меня в ядре:

Security options  --->
    Grsecurity  --->
        Network Protections  --->
        [*] TCP/UDP blackhole and LAST_ACK DoS prevention

CONFIG_GRKERNSEC_BLACKHOLE:
If you say Y here, neither TCP resets nor ICMP destination-unreachable packets will be sent in response to packets sent to ports for which no associated listening process exists. This feature supports both IPV4 and IPV6 and exempts the loopback interface from blackholing. Enabling this feature makes a host more resilient to DoS attacks and reduces network visibility against scanners. The blackhole feature as-implemented is equivalent to the FreeBSD blackhole feature, as it prevents RST responses to all packets, not just SYNs.
…

[bear11]

Тогда вам прямая дорога в багзиллу от gentoo.

[Alex Efros]

Зачем в багзиллу, если это фича? :)

Answer 2

[square]

А помоему B и не должен ругаться, он находится в состоянии FIN_WAIT_2 и ожидает только FIN от A

Comments

[Alex Efros]

Когда nc прерывается по Ctrl-C на сервере B netstat вообще не показывает это соединение, так что оно, надо полагать, закрыто, а не находится в FIN_WAIT_2. А на сервере A это соединение находится в CLOSE_WAIT.

[square]

А что возвращает write на сервере? По идее одна запись может отработать без EPIPE, но вторая попытка всё равно должна увидеть FIN. Не приходит ли сигнал SIGPIPE?

[Alex Efros]

В том-то и дело. После прерывания netcat сервис успешно выполняет несколько write-ов, после следующий write блокируется. EPIPE не приходит как минимум минут 15, дольше не проверял.

[square]

Есть вероятность, что я немного не понимаю чего-то, не злитесь если что, просто мне сейчас эта тема близка, поэтому я хочу разобраться, может и вам помогу. Насколько я понимаю EPIPE, это значение errorn которое вы можете увидеть только после разблокировки write'а, а есть ещё сигнал SIGPIPE, вы как-то его обрабатываете?

[Alex Efros]

SIGPIPE традиционно заблокирован (игнорируется), ибо его можно схлопотать при некоторых абсолютно обычных сценариях I/O. Но суть у SIGPIPE и EPIPE одна и та же, и возникают они по одной и той же причине — попытке записи в разорванное соединение. И, насколько я понимаю, определяется этот факт именно по RST-пакету. Нет RST — и SIGPIPE/EPIPE взяться неоткуда.

Answer 3

[bear11]

Можете ли выложить запись сессии в wireshark-формате?

Comments

[Alex Efros]

Наверное могу, но… а что Вы там хотите увидеть такого, чего нет на моём скриншоте (ссылка в конце вопроса)? Там как раз видны все пакеты одной полной сессии.

Answer 4

[Владимир Дубровин]

Поведение зависит от того, установлена ли на сокет опция SO_LINGER. Если клиент устанавливает SO_LINGER — то ресетов не будет, пока пакеты идут в рамках TCP-соединения.

Comments

[square]

У Netcat l_onoff = 1 и l_linger = 0 — значит должны быть RST

[Владимир Дубровин]

When enabled, a close(2) or shutdown(2) will not return until all queued messages for the socket have been successfully sent or the linger timeout has been reached. Otherwise, the call returns immediately and the closing is done in the background. When the socket is closed as part of exit(2), it always lingers in the background.

[Alex Efros]

SO_LINGER управляет тем, что произойдёт с ещё не отправленными данными, когда сокет закрывает сторона отправившая эти данные. В моём сценарии сокет закрывает nc, который ничего не отправлял. Так что SO_LINGER здесь вроде вообще не при делах.

[Владимир Дубровин]

Я ж процитировал, что в этих ваших линухах, если сокет закрывается exit'ом, то лингер есть всегда.

> и тут мы отключаем nc (по Ctrl-C)

[Владимир Дубровин]

А если есть лингер, то RST взяться неоткуда. Про FIN_WAIT2 уже сказали. Соединение остается и после завершения приложения.

[Alex Efros]

Во-первых по Ctrl-C nc выполняет close() сокета перед выходом. Что наглядно показывает strace:

...
select(16, [0 3], NULL, NULL, NULL)     = ? ERESTARTNOHAND (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
write(2, "\n", 1)                       = 1
close(3)                                = 0
exit_group(1)                           = ?
Process 15291 detached

Во-вторых я сегодня внимательно перечитал Стивенса (Unix network programming, глава 7.5 описывающая SO_LINGER), и снова хочу обратить Ваше внимание, что SO_LINGER контролирует то, как будут обрабатываться данные находящиеся в исходящем буфере ядра при выполнении close() — данные, которые ещё не были отправлены и/или подтверждены. RST, отправляемый в определённом случае SO_LINGER-ом, сообщает удалённой стороне о том, что отправка данных была прервана (причём отправляется этот RST вместо FIN, а у меня как раз этот FIN — от клиента к сервису — отправляется и подтверждается нормально). Я нигде не вижу упоминания о том, что SO_LINGER может как-то влиять на отправку или не отправку RST в ответ на принимаемые после close() пакеты.

[Alex Efros]

Что касается вышеупомянутого FIN_WAIT_2, то здесь тоже не всё понятно. Теоретически, после выхода nc соединение действительно должно остаться в FIN_WAIT_2, но практически netstat его не показывает вообще (хотя другие соединения в FIN_WAIT_2 в выводе netstat присутствуют), так что похоже что оно как-то уж совсем моментально закрывается. Но даже если бы оно осталось в FIN_WAIT_2, на мой взгляд ядро на клиенте всё-равно должно как-то реагировать на пакеты с данными, которые продолжает отправлять сервис — или ACK или RST, но хоть как-то реагировать. Хоть для соединений в FIN_WAIT_2 хоть для CLOSED. А оно не реагирует на эти пакеты вообще никак, как будто (отключенный) файрвол их DROP-ает.

[square]

Интересно, что в выводе strace нету вызова shutdown

[square]

Т.е. может быть сокет не умирает на сервере потому, что у нем висит не обработанный \n

[Alex Efros]

shutdown нет потому, что там close. \n выводился в stderr.

[square]

Соответственно и RST не отправляется, т.к. тогда, по-протоколу, сервер должен будет воспринять это как ошибку.

[Владимир Дубровин]

При нулевом лингере удаленному концу принудительно шлется RST и соединение закрывается, на все последующие пакеты приходят RST. При ненулевом лингере на пакеты, которые пришли в рамках соединения, даже если это ретрансмиты после FIN, RST не шлется.

по strace'у что-то немного странное. Обычно в nfds пишется sock+1, если sock — максимальный сокет в FD_SET, почему там 16, если 15й сокет не в списке — какой-то подвох. Если б меня сильно интересовал вопрос — таки я бы заглянул в сорсы и посмотрел что там за select и что происходит по Ctrl+C.

Еще можно проверить nmap'ом — если на попытку ACK-скана на недавно закрытый порт RST возвращается, значит причину точно следует искать в лингерах.

[bear11]

а запустить не дающую RST софтину под Windows или FreeBSD возможно? Может стоит попробовать? Это вроде как просто nc?

[Alex Efros]

При ненулевом лингере на пакеты, которые пришли в рамках соединения, даже если это ретрансмиты после FIN, RST не шлется.

Откуда такая информация? В известных мне описаниях лингера ничего про ответы на входящие пакеты нет. В общем, если не сложно, хотелось бы увидеть пруфлинки на доку/rfc/etc.

[Владимир Дубровин]

Линк был в самом первом посте. RFC тут никаким боком, это системный API. К сожалению, какой-либо более «официальной» документации по Linux для случая l_linger=0 я не знаю, но в микрософтовской документации четко сказано, что удаленный конец при таком закрытии (abortive close) получает именно reset.

[Владимир Дубровин]

причем даже при попытке чтения.

[Владимир Дубровин]

А, ну кстати, вот вам:

www.faqs.org/faqs/unix-faq/socket/

If the peer calls close() or exits, without having messed with
SO_LINGER, then our calls to read() should return 0. It is less clear
what happens to write() calls in this case; I would expect EPIPE, not
on the next call, but the one after.

If the peer reboots, or sets l_onoff = 1, l_linger = 0 and then
closes, then we should get ECONNRESET (eventually) from read(), or
EPIPE from write().

[Alex Efros]

Там цитаты из того же Стивенса. И нигде не пишут, что лингер блокирует отправку ACK или RST в ответ на входящие пакеты по закрытому/закрываемому соединению. Наоборот, пишут что другая сторона должна таки получить EPIPE на очередном write() — т.е. должна получить RST-пакет либо должен сработать таймаут на перепосылку пакетов (вроде никаких других способов определить разорванное соединение для возврата EPIPE не существует).

[Владимир Дубровин]

Так а причем тут блокирование ACK или RST? Нет там никакого блокирования, просто никто их не отправляет. ACK со стороны сервера не отправляется, т.к. данные из буффера не считываются, принимающая сторона не хочет получать новых данных. RST тоже никто не отправляет, для этого нет никаких причин — все идет строго по протоколу, ретрансмиты полученных ранее пакетов молча отбрасывается.

[Alex Efros]

Сервер A отправляет данные серверу B. Сервер B не подтверждает эти данные ни ACK ни RST, вообще никак. Сервер A, не получив никакого ответа, отправляет эти данные повторно. Сервер B снова никак на них не отвечает. Даже если допустить, что сервер B не отвечает на ретрансмиты потому, что уже видел эти данные, то он ведь и на первую порцию этих данных никак не ответил. Кроме того, насколько я знаю, на ретрансмиты всё-таки отвечают, т.к. сам факт ретрансмита говорит о том, что ответ потерялся, и его, следовательно, таки надо отправить повторно.

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

Моя точка зрения заключается в том, что SO_LINGER здесь абсолютно не при чём:

1. он никак не влияет на то, как отправляются или не отправляются ACK/RST в ответ на полученные пакеты, а проблема именно в этом
2. при локальном запуске nc всё работает как ожидается (RST отправляется, сервис получает EPIPE), хотя для SO_LINGER не должно быть разницы клиент и сервис на одном сервере или на разных
3. в Вашей цитате описания SO_LINGER явно написано, что сервис на второй стороне таки должен в любом случае получить EPIPE при очередном write()
4. netcat во-первых не устанавливает SO_LINGER сам, и во-вторых делает явный close() перед exit() — я только что проверил по сорцам, раз Вам вывода strace не хватило — таким образом ни вручную ни автоматически при exit() SO_LINGER активироваться в моем сценарии не должен вообще

[Владимир Дубровин]

securityvulns.ru/files/testconn.c — возьмите да проверьте с разными лингерами, делов то.

Answer 5

[square]

А код сервера очень секретный? Может опубликуете? Очень интересная задачка, хочу докопаться до сути

Comments

[Alex Efros]

Код не в паблике, но во-первых ничего интересного там нет, и во-вторых я не думаю, что код сервиса вообще как-то причастен к этой мистике с RST. Если до понедельника теоретически в вопросе разобраться не получится, то я попробую заменить клиент-nc и сервис на Limbo на тупые линейные блокирующие клиент и сервер на перле. Убежусь, что с ними наблюдается тот же эффект, и дальше буду искать проблему в районе ядра линуха. :(

[Владимир Дубровин]

Насколько я понимаю, можно запустить chargen с равным успехом.

Answer 6

[square]

Вспомнилась ещё вот что ru.wikipedia.org/wiki/TCP_hijacking
может быть как-то связано

Comments

[Alex Efros]

Я уже писал, что у нас локалка — оба сервера подключены к одному неуправляемому свичу, пакеты подменять некому. Кроме того, я запускал tcpdump на обоих серверах, чтобы быть уверенным в том, что RST пакет не только не приходит, но и не отправляется. Ну и напоследок я на всякий случай проверил таблицу ARP и сравнил MAC-адреса, но это уже чистая паранойя была. :)

Answer 7

[bear11]

Посмотрите книгу «Ричард Стивенс. Протоколы TCP IP».
Ее можно найти или купить в интернете. Там этот вопрос обстоятельно разобран.
В главе «Обнаружение полуоткрытых соединений» четко сказано, что на такое действие (write в полузакрытый сокет) действительно должен приезжать RST.
Посмотрите также поведение ARP в этот момент — не теряет ли сервер, который должен отправлять RST информацию о том, куда ее отправлять?

Comments

[Alex Efros]

Стивенс у меня есть, и не только эта книга, и я его выше уже упоминал. И да, согласно Стивенсу RST должен отправляться, но на практике он не отправляется, в этом-то и суть вопроса — почему он не отправляется.
Насчёт ARP мысль любопытная (хотя возможная причина потери ARP-записи именно в этот момент мне не ясна), я проверил — никаких ARP или других не-TCP-шных пакетов во время описанного в вопросе сценария не бегает.

[bear11]

Хм. А у Стивенса в примере — бегает. Может оно и плохо, что не бегает-то? И еще повторюсь — не можете ли проверить то же, но с другим стеком TCP на сервере (другой ОС)?

[Kindman]

Попробуйте, вместо сервера повесить приложение, которое способно работать с «сырыми сокетами» и заготовьте RAW-IP пакеты с установленными нужными флагами, и посмотрите, как на них отреагирует клиент

[Alex Efros]

Запустил nc на винде. При остановке nc по Ctrl-C на сервер уходит не FIN, а RST. И на сервере write() сразу получает EPIPE.