mennyi az alapertelmezett conntrack timeout?

Hálózatok általános

neha kiesnek csomagok a conntrackbol, SRC=53-al naplozok hibakat. (ez a valasz csomag, a ct state established,related)

beallitanek neki uj timeoutot, csak nem tudom mennyi az alapertelmezett ertek.

ha valaki tudja mirol van szo, legyszi irja meg!

https://wiki.nftables.org/wiki-nftables/index.php/Ct_timeout

koszi!

update:

a teljes kephez hozzatartozik, hogy 20 evig a hoston volt csak tuzfal, regebben iptables, majd iptables-nft, ott nem logolt ilyen problemat.

nemreg megcsinaltam minden vm-ben a tuzfalat nftables-el, majd leegyszerusitettem a hoston a vm-ek fele meno forgalomra a tuzfalat.

ez csak a vm-ekben jelentkezik, es csak azota, hogy ott is van tuzfal.

  • 812 megtekintés

( _ventura_ v | 2023. 08. 20., v – 20:13 )

Esetleg egy:

sysctl -a |grep -i timeout

Lesz pár timeout ...

Fedora 42, Thinkpad x280

Hát, az tippre akár egy olyan DNS kérés is lehet, amire a dns nem válaszol, mert olyanja van, vagy épp nem működik, aztán a conntrack egy idő után dobja, hogy ebből már nem lesz semmi. Az UDP tud vicces dolgokat csinálni, mert app szinten nem szokott nyafi lenni egy-egy elveszett csomagból, meg abból se, ha van, amire nincs válasz, és a conntracknak is tulajdonképp csak meg kell sejteni, hogy mi egy connection, nem teljesen egyértelmű.

én őszintén szólva csodálkoznék, a contracket / socket timeoutokat elég nehéz lenyírbálni, inkább az szokott lenni a gond, hogy gyűlnek, nem az, hogy túl gyorsan elmúlnak. (A tcp time-wait lenyírására meg src port reusera pl ha jól emlékszem az alinak még valami kernel patche is van)

Én erősen kábelcápáznék, meg nézném a conntrack táblát, hogy mi a picsa van.

A "neha kiesnek csomagok a conntrackbol, SRC=53-al naplozok hibakat. (ez a valasz csomag, a ct state established,related)" nem vagyok benne biztos, hogy az tényleg egy válasz csomag, feltéve, hogy udp, a state established,related-et benézheti a conntrack, sokkal könnyebben mint a tcpnél, ahol ugye az established egy jól definiált dolog, ellenben az udpvel, ahol ez nincs. De akár valami dup is lehet, akár valami elkeffentett nat, vagy docker proxy, vagy vmi hw offload (bár ez a konkrét infóból lejjebb van a listán) miatt. 

( andras0602 | 2023. 08. 24., cs – 23:22 )

Biztosan timeout és nem conntrack_max méret a gond?
 

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

eddig nem, most elolvastam.

nekem nem ir ilyet, remeltem ha betelik errol tajekoztat, de nincs ilyen.

megprobaltam az okat megkeresni, de mivel nem sikerult, az rsyslog-ban filterezem ezeket, igy a dmesg-ben latszik, de a syslogban nem, es igy a logcheck sem kuld orankent emailt ezekrol.

neked aztan fura humorod van...

( blackluck v | 2023. 08. 26., szo – 21:16 )

Nezd meg ha nem conntrack-re bizod a dns valasz engedest, hanem siman tuzfallal engeded src 53-as forgalmat is akkor is jelentkezik-e.

Avagy probald tcpdump-al vagy tuzfal logolassal lementeni ezeket a forgalmakat, hogy amelyik valasz elveszik arra a kliens src portra nem-e volt mar korabban masik valasz es amiatt conntrack lezarta a kapcsolatot.
Pl.: kliens A-rol hivas (A query kutya.hu) kimegy tuzfalrol src port 23456 -> dns server port 53,  kozben kliens B-rol hivas (A query macska.hu) tuzfalrol szinten src port 23456 -> dns server port 53 mielott kliens A hivasra jott volna valasz, kesobb megjon kliens A-nak a valaszt conntrack meg lezartnak tekinti ezert kliens B keresere valaszt mar nem er celba.
De tuzfal nat nelkul is lehet akar, kliens kikuld A kerest es ugyanakkor ugyanarrol a portrol kikuldi AAAA kerest is (ha ipv6 nincs fullra letiltva). Anno igy jelentkezett sokaknal hasonlo gond amire frissebb kernel adott megoldast (bar lehet az csak dns udp eseten?)