How to manage other people's TCP connections on Windows?

Question

Computer networks

Ultimate goal: be able to gracefully selectively kill other people's TCP connections. It is highly desirable without the need to develop your own LSP (layered service provider), without "hacking" other people's processes, without injecting DLLs into them, without writing drivers, and without other black magic tricks.

There are a number of programs that have a problem - many TCP connections accumulate in the state, mainly FIN_WAIT_1. Sometimes there are also CLOSE_WAIT (rarely). Sooner or later it breaks the network and nothing works.

How is it possible to:
1. (at least) forcibly release resources occupied by foreign connections with the state FIN_WAIT_1 and CLOSE_WAIT.
2. (preferably) somehow forcibly destroy other people's TCP connections without disturbing the work of programs (that is, so that programs think that the cable has flown out, or host unreachable, or timeout for a response from a remote host).

OS Windows 8, Windows 10, Server 2012.

A little about the situation

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

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

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

Answer 1

This:

be able to gracefully selectively destroy other people's TCP connections.

Impossible under the window

without the need to develop your own LSP (layered service provider), without "hacking" other people's processes, without injecting DLLs into them, without writing drivers, and without other black magic tricks.

These are the states in TCP

FIN_WAIT_1. Sometimes there are also CLOSE_WAIT (rarely).

the really smart people at Berkeley came up with this to guard against some mistakes that could lead to very, very, very stupid consequences.
You can try to put the program along with wine in docker and run it on Linux. Then, to repair this collective farm, it will be enough to pull the container back and forth.