Linux за българи: Форуми

Здравейте. Доста време търся ефективен начин за "убиване" на TCP връзки.
tcpkill по принцип ми върши не лоша работа, но е безполезен ако връзката е idle.

Ограничавам достъпа до 20 established паралелни връзки чрез iptables, но понякога се случва да увисне някоя връзка. Потребителя не може да я затвори, а аз също не мога да я дропя с tcpkill, защото не извършва никакъв трафик. При теста, който проведох, оставям отворено приложението (да вземем дори SSH за пример) без да извършвам някакво действие - tcpkill не работи. Напиша ли каквото и да е, в момента в който изпрати някаква информация и отчете трафик drop-ва връзката моментално. Въпросът е, как мога да отрежа и idle връзка?

Благодаря предварително на отзовалите се :)

Killcx : close a TCP connection (for Linux)

Killcx is a Perl script to close a TCP connection under Linux, whatever its state is (half-open, established, waiting or closing state).

This killcx tool is taking a different approach and tries to generate traffic on the wire to discover what the ACK and SEQ numbers are. Once it forces the peer to replay to its spoofed traffic it kills the TCP session immediately after.

http://killcx.sourceforge.net/

Вече го пробвах - не се случват нещата и при него..

killcx v1.0.3 - (c)2009-2011 Jerome Bruandet - http://killcx.sourceforge.net/

[PARENT] checking connection with [ClientIP:21881]
[PARENT] found connection with [ServerIP:9148] (ESTABLISHED)
[PARENT] forking child
[PARENT] sending spoofed SYN to [ServerIP:9148] with bogus SeqNum
[PARENT] no response from child, operation may have failed
[PARENT] => you may try using 'lo' as interface parameter
[PARENT] killing child [15730] and exiting program

А, d1saster ме преварил :) Тогава да кажа, че можеш да убиваш неактивните връзки и като убиваш родителския процес (неудобно, ако се очаква да има и активни връзки в този момент, които го ползват) или процеса на tty-а (не е задължително да има такъв).

Да спра процеса е най-лесно, но се получава, че заради 1 човек спирам достъпа на други 300 :) Не е практично.

Не виждам смисъла от заниманието, ама все пак таймаутите се контролират през procfs и има много вариации на темата според сценария. TCP стека е доста комплексно нещо. Понеже ме мързи да ровя документация, а и не мисля да се ровя вместо теб, ще направя нещо много по-полезно, мисля да ти обясня в общият случай как се случват нещата, за да няма разочарования.

Първо, има два варианта, при които една TCP връзка би "увиснала" в ESTABLISHED състояние - когато отсрещната страна се отсвири или когато отстрещната страна не се е отсвирила, но няма трафик, т.е връзката е установена, но е idle. Първият случай е много лесен за разрешаване - директно, има си procfs врътка, контролираща колко време трябва да мине преди връзката да се затвори ако няма никаква активност. Този таймаут по дефолт е доста висок, в рамките на няколко часа в честия случай, макар че това варира от дистрибуция до дистрибуция.

По-проблемен е случая обаче в който някой сокет е "маркиран" чрез setsockopt() да е keepalive сокет. В този случай, след изтичане на таймаута, връзката не се затваря, вместо това периодично се засилват празни TCP пакети и се чака ACK отсреща. Ако след няколко опита няма потвърждения, връзката се затваря. Колко да се чака и колко опита да се правят е също въпрос на procfs врътки, чиито имена не знам наизуст. При това положение, ако отсрещната страна се е отсвирила, връзката все пак ще се затвори. Обаче има и следващ вариант - отсрещната страна не се е отсвирила, но нарочно държи връзката idle, защото няма какво да прати или не иска да праща нищо, но въпреки това отговаря на keepalive пакетите (което може да е напълно вероятен евентуален DoS сценарий в някакъв специфичен случай). Което апропо обикновено също е и случая със ssh клиенти или сървъри с конфигурирани брутално високи таймаути. Е тогава нещата много загрубяват - в добрия случай софтуерът е така любезен да ти предостави възможност да конфигурираш таймаутите (sshd поне го прави). В случая в който не го прави, може би варианта остава ползването на някое шашаво iptables разширение, което може да match-ва трафик по timestamp-и в conntrack таблицата, не може да няма такова. Ако това ти се вижда странно, разбери че TCP стека в линукс ядрото не може да влиза в ролята на полицай, има си съвсем легитимни случаи където някоя TCP връзка да може да е idle с дни наред и щом като потребителския софтуер го е изискал, тогава да си чупи главата.

Та не знам точно какъв е твоя случай и кое точно виждаш като проблем. За мен лично това ограничение от 20 установени TCP връзки ми се вижда малко странно.

Софтуера има възможност за закриване на "увисналите" връзки. Именно keepalive проверките ги затварят след 2 минути неактивност, което ме устройва до известна степен. Проблемът е, че в клиентския софтуер, който прави комуникацията със сървъра има бъг, при който на моменти, при определен сценарий запазва background връзки активни, които отговарят на keepalive запитванията. Потребителите ми са с ниска (при някои от тях дори клоняща към нула) култура в тези среди и не могат да ги затворят сами от машините си, което ме принуждава да търся начин да ги прекратя от страна на сървъра.

Добре де, на клиентите не може ли да им се конфигурира също таймаут за неактивност? Keepalive нещата така да го кажем не се "броят" като активност по мрежата, payload-а им е с нулева големина. С други думи ако те получат keepalive пакет от сървъра, това не би трябвало да го отчитат като "активност" върху сокета. Макар че знам ли и аз - операционни системи много, имплементации на TCP стека много.

Не виждам как бих могъл да го направя таймаута в клиентското приложение - не е open source, а разработчика е спрял поддръжката му преди години.
Дори и с нулев обем, явно отговора е достатъчен, за сървъра, за да запази връзката отворена. tcpkill не върши работа, когато сървър-клиент е само с keepalive заявки. Докато клиента е на idle не го закача. В момента, в който изпратя каквато и да е информация, дори нещо просто като това да си проверя пинга, tcpkill го засича и drop-ва връзката моментално. При клиента обаче когато остане като background не изпраща дори това, така че на теория може да стои и с часове отворена - в момента решаваме проблема, като крайния потребител рестартира мрежовата си свързаност (или компютъра директно, че му е по-лесно :)). Без да го направи обаче, връзката остава отворена и запълва лимита от 20 връзки, който споменах в предните си публикации. Връзката пък е established, така че не виждам как бих могъл да променя и правилото в iptables, за да не засяга idle връзките.. Задънена улица ми се вижда на мен, за това и ми се наложи да потърся помощ тук, от по-компетентни лица.

Защо не пробваш с CUTTER ? Обикновено работи по следния начин като изпраща FIN -> ACK -> RST , за да прекъсне връзката. Виж официалния сайт на линка долу :

http://www.digitage.co.uk/digitage/software/linux-security/cutter ($2)

Да спра процеса е най-лесно, но се получава, че заради 1 човек спирам достъпа на други 300 :) Не е практично.

И на всичките тези 300 ли го има този проблем???
Брой им връзките и като станат повече от х за даден клиент му пращай едно съобщение да си рестартира клиента :)

Добре де, conntrack -D (след инсталация на conntrack-tools) не върши ли работа?

Не виждам как бих могъл да го направя таймаута в клиентското приложение - не е open source, а разработчика е спрял поддръжката му преди години.
Дори и с нулев обем, явно отговора е достатъчен, за сървъра, за да запази връзката отворена. tcpkill не върши работа, когато сървър-клиент е само с keepalive заявки. Докато клиента е на idle не го закача. В момента, в който изпратя каквато и да е информация, дори нещо просто като това да си проверя пинга, tcpkill го засича и drop-ва връзката моментално. При клиента обаче когато остане като background не изпраща дори това, така че на теория може да стои и с часове отворена - в момента решаваме проблема, като крайния потребител рестартира мрежовата си свързаност (или компютъра директно, че му е по-лесно :)). Без да го направи обаче, връзката остава отворена и запълва лимита от 20 връзки, който споменах в предните си публикации. Връзката пък е established, така че не виждам как бих могъл да променя и правилото в iptables, за да не засяга idle връзките.. Задънена улица ми се вижда на мен, за това и ми се наложи да потърся помощ тук, от по-компетентни лица.

Лошо. Добре де, а защо все пак е лимита от 20 връзки? В смисъл от сървърна страна при това положение освен ако няма някаква много специална причина, не виждам проблем и 2000 idle връзки да държа отворени. Иначе доста глупавото решение е да рестартирам сървърното приложение през някакъв период от време, но е простотия това, защото ще го отнесат легитимни клиенти

Защо не пробваш с CUTTER ? Обикновено работи по следния начин като изпраща FIN -> ACK -> RST , за да прекъсне връзката. Виж официалния сайт на линка долу :

http://www.digitage.co.uk/digitage/software/linux-security/cutter ($2)

Ще го тествам и него да видим ще свърши ли работа :)

Цитат на: Breakfist в Mar 25, 2015, 00:53

Да спра процеса е най-лесно, но се получава, че заради 1 човек спирам достъпа на други 300 :) Не е практично.

И на всичките тези 300 ли го има този проблем???
Брой им връзките и като станат повече от х за даден клиент му пращай едно съобщение да си рестартира клиента :)

То няма да има голяма разлика със сегашното положение сякаш. Не е при всички потребители, може да го има при 2 или 3 от тях в даден момент, може да е при 50 или при нито един, зависи кога увисне клиента. Примерно лагва му нета, изхвърля го от клиента, но софтуера продължава да работи background и запълва ограничението. На практика може да има и 15 увиснали връзки, като потребителя влезе ли с 5 - до там е. Предупредително съобщение би имало ефект ако знаят как да решат проблема крайните потребители, но в моя случай е безпредметно сякаш.

Цитат на: Breakfist в Mar 25, 2015, 01:37

Не виждам как бих могъл да го направя таймаута в клиентското приложение - не е open source, а разработчика е спрял поддръжката му преди години.
Дори и с нулев обем, явно отговора е достатъчен, за сървъра, за да запази връзката отворена. tcpkill не върши работа, когато сървър-клиент е само с keepalive заявки. Докато клиента е на idle не го закача. В момента, в който изпратя каквато и да е информация, дори нещо просто като това да си проверя пинга, tcpkill го засича и drop-ва връзката моментално. При клиента обаче когато остане като background не изпраща дори това, така че на теория може да стои и с часове отворена - в момента решаваме проблема, като крайния потребител рестартира мрежовата си свързаност (или компютъра директно, че му е по-лесно :)). Без да го направи обаче, връзката остава отворена и запълва лимита от 20 връзки, който споменах в предните си публикации. Връзката пък е established, така че не виждам как бих могъл да променя и правилото в iptables, за да не засяга idle връзките.. Задънена улица ми се вижда на мен, за това и ми се наложи да потърся помощ тук, от по-компетентни лица.

Лошо. Добре де, а защо все пак е лимита от 20 връзки? В смисъл от сървърна страна при това положение освен ако няма някаква много специална причина, не виждам проблем и 2000 idle връзки да държа отворени. Иначе доста глупавото решение е да рестартирам сървърното приложение през някакъв период от време, но е простотия това, защото ще го отнесат легитимни клиенти

Всичко над 20 е premium опция :) Това е платен абонамент, чрез който се самоиздържа иначе безплатната услуга, която предлагам.

Защо не пробваш с CUTTER ? Обикновено работи по следния начин като изпраща FIN -> ACK -> RST , за да прекъсне връзката. Виж официалния сайт на линка долу :

http://www.digitage.co.uk/digitage/software/linux-security/cutter ($2)

Не ми върши работа..

(http://store.picbg.net/pubpic/F2/C3/b12b288aaf4cf2c3.png)

Що да не ти върши работа? Качваш сървъра на виртуална машина (или правиш една и качваш един линукс да играе рутер), прекарваш нетя през линукския рутер и си готов :)

Всичко над 20 е premium опция :) Това е платен абонамент, чрез който се самоиздържа иначе безплатната услуга, която предлагам.

Ами в такъв случай защо трябва да решаваш този проблем? На практика имаш неочакван помощник, стимулиращ клиентите да минат на платена услуга :)

Що да не ти върши работа? Качваш сървъра на виртуална машина (или правиш една и качваш един линукс да играе рутер), прекарваш нетя през линукския рутер и си готов :)

Самия сървър е виртуална машина, намираща се на хипервайзора на хостинг провайдъра.

Цитат на: Breakfist в Mar 26, 2015, 00:16

Всичко над 20 е premium опция :) Това е платен абонамент, чрез който се самоиздържа иначе безплатната услуга, която предлагам.

Ами в такъв случай защо трябва да решаваш този проблем? На практика имаш неочакван помощник, стимулиращ клиентите да минат на платена услуга :)

Аз мога и да ги отрежа тотално и да го направя с платен достъп, но не това ми е целта :)
Предлагам 20 безплатни свързвания, и търся начин да мога да ги осигуря на потребителите си. Пък който иска да вземе premium - да заповяда, но държа това да бъде въпрос на избор, не да ги задължавам един вид :)

Още по-добре - взимаш си още един ВПС и си правиш рутера там :) Хостинг провайдера ти има начин да ти направи вътрешна мрежа между машините...

Още по-добре - взимаш си още един ВПС и си правиш рутера там :) Хостинг провайдера ти има начин да ти направи вътрешна мрежа между машините...

Ехеее чак от такива изпълнения няма нужда :)
Аз бих развил идеята доста по-просто:
1. Казваш на приложението си да слуша на lo0
2. Правиш си Policy routing - ето  линк http://en.wikipedia.org/wiki/Policy-based_routing ($2)
с две думи: дефинираш кои входящи пакети са за твоята програма и ги рутираш към lo0 - тук малко NAT трябва да направиш, което ме навежда на мисълта, че може и само с DNAT да стане, но така или иначе идеята е че вече имаш рутер който хвърля пакетите м/у eth0 и lo0 и се надяваш тази програма cutter да ти свърши работа :)

Успех.

Ето за това са форумите :) Понякога човек се задълбава без да се огледа за по-простото решение :)

За да опростим още повече нещата, може би е достатъчно просто да се пусне едно haproxy пред сървъра и да му се настроят въпросните таймаути и ограничения.

Може би по-скоро ще търся в такъв случай вариант да "убивам" връзките от страна на потребителя.
Лошото е, че зависват като "TIME_WAIT" и PID 0, дефакто не виждам кой процес трябва да прекратя, за да ги освободя.. Кофти работа.

Ама то TIME_WAIT означава че сокета е затворен от твоята страна, демек предполагам сървъра. Ако връзката се е обслужвала от child процес, който е терминиран след затварянето на сокета, PID 0 е нещо нормално. Много странното обаче е ако тези връзки висят прекалено дълго в това състояние, би трябвало относително скоро да си заминат. При първия пакет изпратен отсреща или след някакъв относително кратък таймаут. Ако не се лъжа, включително и за този таймаут си има procfs врътка.

TIME_WAIT го показва при потребителя (В момента комуникирам с човек, който има такъв проблем и чрез TeamViewer гледам при него какво е положението). На сървъра обаче същите връзка са ESTABLISHED. И просто ме удря в земята, нямам представа какво да направя повече.. А не откривам начин и да ги прекратя принудително. До колкото четох в Google, TIME_WAIT е вече затворена връзка (което каза и ти всъщност), която продължава да стои активна още Х време, от гледна точка на сигурността, за да не се дублират пакети на един порт. Не разбирам обаче как затворена връзка ми я показва established от сървърната страна..

Ми според мен клиентския софтуер е написан нагло и не затваря сокетите си културно. Може би е добре да свалиш TCP keepalive таймаута на сървъра да не е няколко часа? Би трябвало като изтече отреденото му време, сървъра да прати keepalive пакет, клиента да му върне RST и нещата да се приключат. Ще си докараш повече трафик на сървъра, но това не мисля че ще е особено голяма болка.

lsof -n -i@127.0.0.1
при bsd може tcpdrop но при линукса май не поддържаше TCPCTL_DROP
може да пробваш
netstat --program --numeric-hosts --numeric-ports --extend и после
 find -inum inode number 
и после
find . -inum inode number  -exec rm -i {} \;

ако това ти върши работа  [_]3 тая бира свършване няма  ;)

Според мен това трябва да се реши от клиентската страна. След като проблема е там.

Аз имам подобен проблем сега http://prntscr.com/6o2rjd ($2) отварям си пощата от майлбг после излизам и искам да влезна с друга поща но рутера не е прекъснал връзката и на другата поща получавам отговор , че в момента сървъра не работи опитайте след 15 мин

Аз имам подобен проблем сега http://prntscr.com/6o2rjd ($2) отварям си пощата от майлбг после излизам и искам да влезна с друга поща но рутера не е прекъснал връзката и на другата поща получавам отговор , че в момента сървъра не работи опитайте след 15 мин

Това дето си го шернал не ми се отваря, ама ще се опитам да предположа.... Искаш да влезеш с друго име и парола или искаш да отвориш друг уеб интерфейс на друг пощенски сървър? БТВ по отношение на уеб интерфейсите рутера ти няма мешавина. Ако отвориш два браузъра (различни) ще можеш едновременно да ползваш мейлбг. С различни юзъри разбира се.

Пробвам от различни компютри с различни браузъри излизам от единия акаунт и искам да влезна в другия и дотам дава , че сървъра е изключен пробвайте след 15 мин  и като поглиднах на рутера ми дава към майл бг естаблиш от иптата от които съм отварял . Излизам с логофф но утре ще си го ровя проблема смених на
 set optimization aggressive и
tcp.first                   120s
tcp.opening                  30s
tcp.established          900s
tcp.closing                 120s
tcp.finwait                  45s
tcp.closed                   90s ще го видя утре но досега не съм имал такъв проблем  по същата логика трябва и с други сайтове да се случва