nf_conntrack in TIME_WAIT @ Slo-Tech

Forum » Pomoč in nasveti »
nf_conntrack in TIME_WAIT

nf_conntrack in TIME_WAIT

čuhalev :: 8. sep 2015, 12:42

Imam Linux sistem, na katerem teče enostaven program, ki komunicira: dobi zahtevo in se odziva, ampak čez nekaj časa se mi nf_conntrack tabela zapolni in 99 % od tega je od tega programa v statusu TIME_WAIT [ASSURED].

nf_conntrack tabela mora, kot sem prebral, ostati, saj sistem vrši NAT, vendar komunikacija na ta program je direktna, torej na INPUT.

Ali obstaja še kakšna boljša rešitev kot nastaviti

nf_conntrack_tcp_timeout_time_wait=1

Ribič :: 8. sep 2015, 12:59

Lahko malo bolj podrobno opišeš zadevo? Od daleč težko rečem kaj bi bilo narobe. Predpostavljam, da ti tale program posluša na TCP potru. Ena možnost je, da imaš kaj narobe s NAT tabelami - ali je možno, da program stestiraš še na kakšni drugi linux distribuciji? Druga možnost pa je, da program ne zapira povezav. Za kateri program gre, če nam lahko zaupaš?

čuhalev :: 8. sep 2015, 18:24

Da, na TCP imam HTTP strežnik napisan v C: accept, recv, send, shutdown, recv, shutdown, close.

Paketki z tcpdump:

 S >, S. <, . >, P. >, . <, P. <, . >, F. >, F. <, . >, . <

Ampak včasih zadnji . > ali . < zmanjka.

Ribič :: 8. sep 2015, 21:18

Kaj se zgodi, če program prekineš oz. ga izklopiš, ko so conntrack tabele polne? Mar se spraznijo (čez koliko časa?) ali ostanejo polne?
In kakšno imaš konfiguracijo požarnega zidu na mreži oz. strežniku? Je to strežnik, ki posluša samo na interni mreži LAN (192.168.0.0/24) oz. ali posluša na javno dostopnem IP-ju?
Pa daj prosim gor kak soliden wireshark pcap oz. tcpdump datoteko gor, ker teh tvojih heroglifov ne razumem ravno najbolje.

lp

čuhalev :: 9. sep 2015, 02:16

Tole je en zahtevek preko

echo -e "GET / HTTP/1.0\r\n" | nc REMOTE 80

tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
02:10:22.284772 IP (tos 0x0, ttl 64, id 9805, offset 0, flags [DF], proto TCP (6), length 60)
    LOCAL.54256 > REMOTE.80: Flags [S], cksum 0x2397 (correct), seq 1495938740, win 29200, options [mss 1460,sackOK,TS val 66982137 ecr 0,nop,wscale 7], length 0
02:10:22.285822 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    REMOTE.80 > LOCAL.54256: Flags [S.], cksum 0x4daf (correct), seq 3694827487, ack 1495938741, win 14480, options [mss 1460,sackOK,TS val 2005795 ecr 66982137,nop,wscale 2], length 0
02:10:22.285884 IP (tos 0x0, ttl 64, id 9806, offset 0, flags [DF], proto TCP (6), length 52)
    LOCAL.54256 > REMOTE.80: Flags [.], cksum 0xb421 (correct), ack 1, win 229, options [nop,nop,TS val 66982137 ecr 2005795], length 0
02:10:22.286030 IP (tos 0x0, ttl 64, id 9807, offset 0, flags [DF], proto TCP (6), length 68)
    LOCAL.54256 > REMOTE.80: Flags [P.], cksum 0xe596 (correct), seq 1:17, ack 1, win 229, options [nop,nop,TS val 66982137 ecr 2005795], length 16
02:10:22.286064 IP (tos 0x0, ttl 64, id 9808, offset 0, flags [DF], proto TCP (6), length 52)
    LOCAL.54256 > REMOTE.80: Flags [F.], cksum 0xb410 (correct), seq 17, ack 1, win 229, options [nop,nop,TS val 66982137 ecr 2005795], length 0
02:10:22.290268 IP (tos 0x0, ttl 64, id 3267, offset 0, flags [DF], proto TCP (6), length 52)
    REMOTE.80 > LOCAL.54256: Flags [.], cksum 0xa6d2 (correct), ack 17, win 3620, options [nop,nop,TS val 2005795 ecr 66982137], length 0
02:10:22.290514 IP (tos 0x0, ttl 64, id 3268, offset 0, flags [DF], proto TCP (6), length 134)
    REMOTE.80 > LOCAL.54256: Flags [P.], cksum 0x289d (correct), seq 1:83, ack 18, win 3620, options [nop,nop,TS val 2005795 ecr 66982137], length 82
02:10:22.290546 IP (tos 0x0, ttl 64, id 9809, offset 0, flags [DF], proto TCP (6), length 52)
    LOCAL.54256 > REMOTE.80: Flags [.], cksum 0xb3bc (correct), ack 83, win 229, options [nop,nop,TS val 66982139 ecr 2005795], length 0
02:10:22.290655 IP (tos 0x0, ttl 64, id 3269, offset 0, flags [DF], proto TCP (6), length 52)
    REMOTE.80 > LOCAL.54256: Flags [F.], cksum 0xa67e (correct), seq 83, ack 18, win 3620, options [nop,nop,TS val 2005795 ecr 66982137], length 0
02:10:22.290671 IP (tos 0x0, ttl 64, id 9810, offset 0, flags [DF], proto TCP (6), length 52)
    LOCAL.54256 > REMOTE.80: Flags [.], cksum 0xb3bb (correct), ack 84, win 229, options [nop,nop,TS val 66982139 ecr 2005795], length 0

Ko stežnik ubijem, povezave umirajo skladno s svojim timeoutom. Interni naslovi so. Bom jutri naložil datoteko.

Ribič :: 9. sep 2015, 21:25

Tale TCP stream zgleda sicer vredu glede flagov, čeprav sem želel videti tudi kakšen wireshark capture. Sem malo prebral po spletu zadeve in mi je pod določenimi pogoji stvar uspelo reproducirati na svojem računalniku. Očitno so te TIME_WAIT stopnje kar normalna zadeva za TCP povezave, saj preprečujejo, da bi stari paketi prispeli na novo povezavo. Meni je sider uspelo napraviti par TIME_WAIT TCP povezav v netstat-u, ki so s časoma izginile. Tako, da če se ti zadeva res tako hitro zapolni pod privzetimi vrednostmi, potem moraš imeti res veliko prometa na tem strežniku. Druge ideje nimam.

Če je temu tako, bi ti pa nekaj predlagal: Razmisli, če bi namesto neprestanega povezovanja na strežnik (ugibam, da imaš ukaz "nc" v neki zanki v bash skripti ali kaj podobnega) bilo pametneje uporabiti nekaj, kar se poveže enkrat in ima potem TCP povezavo odprto ter sproti prejema podatke s strežnika. Tole pride v poštev, če imaš malo število klientov, ki se zelo hitro povezujejo. V nasprotnem primeru pa bo verjetno potrebno prilagoditi kakšne sistemske nastavitve. Glej npr: http://vincent.bernat.im/en/blog/2014-t...

lp

jedateruk :: 18. okt 2015, 09:57

Upam, da ne boste jezni, da tu vprašam nekaj o time_wait povezavah, ki jih vidim, ko vnesem komando netstat -ano.
Teh time_wait connections imam kar nekaj, sem našel neko možno rešitev, tukaj piše o tem. Me zanima, če je dobro za windows 8.1, če grem prek registra zmanjšati čakalno dobo, da se povezava prej prekine.

Zgodovina sprememb…

spremenil: jedateruk (18. okt 2015 ob 09:58)

Vredno ogleda ...

	Tema	Sporočila	Ogledi	Zadnje sporočilo
	Tema	Sporočila	Ogledi	Zadnje sporočilo
»	"Port scan" stanje na IPv4 omrežju (strani: 1 2 ) HotBurek Oddelek: Omrežja in internet	55	9531 (8451)	AštiriL 7. okt 2019 20:10:19
»	asus router p/p ? All Oddelek: Omrežja in internet	8	1237 (1061)	T743 8. mar 2019 09:20:07
»	dolžina ethernet paketa slovencl Oddelek: Omrežja in internet	16	5000 (4531)	AndrejO 9. jun 2013 18:32:11
»	SIOL TV dela samo 5 minut (IGMP snooping) bulekk Oddelek: Omrežja in internet	11	2688 (2424)	bulekk 24. dec 2008 12:27:53
»	IPTABLES in TCP flags problem Bojan xxxx Oddelek: Operacijski sistemi	17	1465 (1294)	Bojan xxxx 17. dec 2004 21:24:02

Več podobnih tem

Zadnje novice

Zadnji članki

Išči:

Forum » Pomoč in nasveti »
nf_conntrack in TIME_WAIT

nf_conntrack in TIME_WAIT