Как управлять чужими TCP соединениями на Windows?

Question

[KotomeNami]

Конечная цель: уметь graceful выборочно уничтожать чужие TCP соединения. Очень желательно без необходимости разработки собственного LSP (layered service provider), без "взлома" чужих процессов, без инжекта в них DLL, без написания драйверов, и без прочих приёмов чёрной магии.

Есть ряд программ, у которых наблюдается проблема - скапливается множество TCP соединений в состоянии, главным образом, FIN_WAIT_1. Иногда ещё бывают CLOSE_WAIT (редко). Рано или поздно это нарушает работу сети, и ничего не работает.

Каким образом возможно:
1. (хотя бы) принудительно освобождать ресурсы, занятые чужими соединениями с состоянием FIN_WAIT_1 и CLOSE_WAIT.
2. (желательно) как-нибудь принудительно уничтожать чужие TCP соединения без нарушения работы программ (то есть чтобы программы думали, будто бы кабель вылетел, или host unreachable, или timeout на ответ от удалённого хоста).

ОС Windows 8, Windows 10, Server 2012.

Немного о ситуации

Программа 32-bit, от промышленного оборудования. Документации на программу нет, исходников тем более, техподдержка закрылась ещё в 2008-ом, программисты уволились ещё раньше. (Хотя имеющаяся версия программы датирована 2013-м годом - говорят, это было последнее обновление, кто его делал - никто не объяснил). (Писать про ПО и оборудование я не могу).

На программе стоит какая-то защита, которая, с одной стороны, позволяет ей работать на Windows от 2000 до 10 (хотя используется Windows 8), с другой стороны - не позволяет инжектировать в неё DLL и перехватывать обращения к winsock. Всё даже хуже - VirtualAllocEx, CreateRemoteThread, WriteProcessMemory практически гарантированно приводят к срабатыванию защиты. Программа состоит из ПЯТИ РАЗНЫХ (!!!) экзешников, которые как-то мониторят друг друга, один всегда под отладкой, ещё два загружены как системные службы. А ещё у них там похоже собственный загрузчик DLL есть, который сам грузит системные библиотеки, и, похоже, что-то с ними ещё и делает. Под OllyDbg всю эту радость так ни разу запустить и не получилось. (До прошлого месяца я вообще не знал о существовании InternalGetTcpTableWithOwnerModule в iphlpapi.dll) И хоть загрузить свою DLL в процесс, работающий с сетью в принципе реально - делать это минимум страшно - при попытках модификации кода срабатывает защита. В общем модифицировать/отлаживать уже пытались - и там всё плохо, так как если даже что нибудь будет придумано - нет никакой гарантии, что их защита не скажет через месяц, что что-то пошло не так, вы программу не купили а взломали, всё остановлено.

Интересует не решение конкретной проблемы, а именно вопрос управления чужими TCP соединениями.

Answer 1

[Армянское Радио]

Вот это:

уметь graceful выборочно уничтожать чужие TCP соединения.

Под форточкой невозможно

без необходимости разработки собственного LSP (layered service provider), без "взлома" чужих процессов, без инжекта в них DLL, без написания драйверов, и без прочих приёмов чёрной магии.

Вот эти состояния в TCP

FIN_WAIT_1. Иногда ещё бывают CLOSE_WAIT (редко).

реально умные люди в Беркли придумали для того, чтобы защититься от некоторых ошибок, которые могут привести к очень-очень-очень дурацким последствиям.

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

Answer 2

[rPman]

Поставить утилитку (не обязательно ее) и с ее помощью брякать подключения? Или подвисшие соединения никак не сбрасываются штатно?

Точно помню, что различные манипуляции с настройками сетевого адаптера, даже банальный выключить включить, полностью игнорирует что кто то пользуется интернетом, приложения принудительно закрывают подключения и падают с ошибками (если слушатель порта не умеет отрабатывать такие случаи) что у вас происходит? По уму должны все открытые подключения закрыться принудительно.

p.s. Странно что в вопросе показан очень высокий уровень понимания и при этом не готовы написать свое приложение, использующее lsp для контроля?