Рабочий метод разрыва конкретного активного соединения из командной строки linux (drop/kill/cut/close ESTABLISHED connection)

[@meteozond]

E: Couldn't find package libnetpacket-perl

[@meteozond]

Приведите пример использования — добавлю в топик.

[@meteozond]

Еще раз повторюсь у меня tcpkill не заработала ни на одном из серверов.
Почему-то не находит соединения соответствующего запросу — поэтому весь сыр бор.
Насколько я видел в сети — я такой не один. Баг в трекере висит еще с 2008-го года.

[@meteozond]

Наврал, это cutter говорит что нечего не найдено.
tcpkill: write: Operation not permitted

[@meteozond]

ничего

[@mikevmk]

Никакого holywar (еще раз: никакого holywar), просто упомяну, что очень жаль, что в linux нет аналога tcpdrop(8) из FreeeBSD

[@torero]

Да было бы желание — уже запилили бы такое же.
Просто все силы уходят на создание новых дистров и попытки их индивидуализировать :) Это же круче, чем tcpdrop ваять.

[@meteozond]

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

[@gnomeby]

tcpdrop делает соединениям REJECT, а не DROP. Пока самый простой метод для себя нашёл — виртуалка в VirtualBox, где можно временно вырубать сетевую карту.

[@ghisguth]

Тоже когда-то сталкивался с подобной проблемой — не мог разорвать соеденение на порту, который мне нужен был для других целей. Не работала ни одна утилита для разрыва соеденения. Насколько помню — помогло поставить в начало iptables отклонение пакетов, после этого соеденение само отвалилось и я занял этот порт.

[@iManiacDev]

Эмн, а мне одному хочется разделить блог Линукс для всех на два? Линукс для всех и Линукс для гиков, ибо в этом блоге уже очень много разной информации для профессионалов и они ни очем порой не говорят новичкам, или людям которые только приглядываются к Линуксу.

[@meteozond]

я бы сказал, это на грани гиковства :) Задача вполне тривиальная.

[@bondbig]

Всё уже сделано за нас.

[@CentALT]

Вас штатный conntrack-tools чем не устраивает?

Может делать с Вашей conntrack таблицей такое, о чем Вы и помыслить не могли :)

[@meteozond]

Рабочий пример использования приведите, пожалуйста, добавлю в статью.

[@CentALT]

Например так
conntrack -D conntrack --orig-src 127.0.0.1


на выходе получаем
tcp 6 40 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=55307 dport=9000 packets=18 bytes=1864 src=127.0.0.1 dst=127.0.0.1 sport=9000 dport=55307 packets=18 bytes=136736 [ASSURED] mark=0 use=1

tcp 6 5 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=55306 dport=9000 packets=7 bytes=1372 src=127.0.0.1 dst=127.0.0.1 sport=9000 dport=55306 packets=7 bytes=13372 [ASSURED] mark=0 use=1

tcp 6 46 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=55308 dport=9000 packets=6 bytes=1560 src=127.0.0.1 dst=127.0.0.1 sport=9000 dport=55308 packets=6 bytes=400 [ASSURED] mark=0 use=1


conntrack v0.9.15 (conntrack-tools): 3 flow entries have been deleted.

Вообще советую набрать команду conntrack без параметров.

[@meteozond]

тот же эффект:

tcp 6 431999 ESTABLISHED src=178.66.18.146 dst=83.222.95.94 sport=3642 dport=80 packets=159 bytes=7324 src=83.222.95.94 dst=178.66.18.146 sport=80 dport=3642 packets=151 bytes=371944 [ASSURED] mark=0 secmark=0 use=1
conntrack v0.9.14 (conntrack-tools): 1 flow entries have been deleted.

а соединение висит

[@bondbig]

Вас штатный conntrack-tools чем не устраивает?

Хотя бы тем, что conntrack может и не использоваться на конкретной системе, как и iptables в целом.

[@CentALT]

Кстати tcpkill у меня заработал без танцев с бубном
tcpkill -i eth0 host 10.0.0.1

tcpkill: listening on eth0 [host 10.0.0.1]



и соединение отвалилось.

[@meteozond]

Чудеса и centos и debian с последними обновками выдают бесконечную простыню из:

78.132.197.207:1234 > 83.222.96.98:80: R 4125933406:4125933406(0) win 0

А соединение висит как ни в чем не бывало.