У меня есть клиент, подключающийся к серверу через VPN-туннель. Связь на месте, я могу пинговать сервер и запрашивать другие службы ( curl запрос к API, например) через этот туннель.
Одна служба на клиенте не может привязаться к соответствующей службе на сервере. При выполнении tcpdump, Я вижу, что сервер отвечает RST к начальному SYN клиента, подключающегося к порту службы.
Кто может выдать это RST? Это сетевой стек сервера (из-за брандмауэра, искаженного пакета, короче говоря, что-то, связанное с чистой сетью), или это также может быть сама служба (та, что на сервере, которая должна отвечать на запросы от клиент)?
Цель вопроса - попытаться различить неправильную конфигурацию устройств (ОС, брандмауэр, ...) и неправильную конфигурацию / несовместимость самих сервисов. В частности, я хотел бы понять, может ли служба высокого уровня (возможно, косвенно) закрыть соединение с запрашивающим клиентом таким образом, чтобы RST выдается обратно клиенту.
RST может быть выдан сервером или сетевым устройством, которое взаимодействует с трафиком (например, межсетевым экраном, концентратором VPN).
В зависимости от сетевого устройства и его конфигурации, оно могло ответить RST, или ICMP недоступен, или просто молча сбросить.
Изящное закрытие установленного соединения службой / приложением должно вызывать пакет FIN, а не RST; вы можете получить RST, если попытаетесь подключиться к порту, который не слушает.
Лучше всего выполнять анализ пакетов в разных точках сети; вы можете захватить трафик на сетевой карте сервера, чтобы увидеть, генерирует ли он RST, а затем переместить точку мониторинга в сторону клиента (VPN и брандмауэры обычно могут сбрасывать захваченные пакеты или журналы)
Флаги RST отправляются сетевым стеком сервера, межсетевые экраны обычно отбрасывают пакеты беззвучно, если порт фильтруется.
Вот хорошая статья, которая немного расширяет это: https://blogs.technet.microsoft.com/networking/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them/
Чтобы ответить на ваш конкретный вопрос, не исключено, что какой-то другой процесс может закрывать ваши TCP-соединения, хотя обычно это делается путем завершения процесса, который прослушивает этот порт. Если процесс прослушивания все еще открыт после RST, маловероятно, что другой процесс пытался закрыть соединение.