Sziasztok,
jelezte az ügyfél, hogy néha (napota, kétnaponta egyszer) connection timeoutot kap egy két kliensgép az egyik szerverünkről (Red Hat 7).
Az egyik kliensgép (legyen a neve A) a saját környezetünkben fut, ahol az érintett szerver (legyen a neve S) is van. Míg a másik kliensgép (legyen a neve B) egy külső szolgáltatónál fut, erről semmi infónk nincs és hozzáférésünk sincs.
A szerveren futtattam 3 napig tcpdumpot és a "mi" kliensünkön (A) is. 3 nap alatt egyszer fordult elő timeout e két gép között (3 nap dumpja 14 mega, 47 ezer csomag). Ping is ment 3 napig, nem volt packet loss, illetve az összes többi gép többi (tcp) kapcsolata rendben volt.
tcpdump szerint a szerverre bejött a syn csomag, és a szerver válaszolt is a kliensnek, megy ki az ack, de a kliensen nem látszik, hogy bejött volna a válaszcsomag.
A kliens vár, majd küld egy retransmission syn-t, de arra sem érkezik meg a válasz, majd megint megy ki egy rts syn és így tovább... végül 1 perc után timeoutol.
Szerver oldalon minden csomag beérkezik és mindre ki is megy a válasz.
B kliensen, ami nem a mi környezetünkben van, nem tudtam tcpdumpot futtatni, de a szerveroldali dump ugyan úgy néz ki, mint az A kliens esetében. Bejönnek az rts sny csomagok a szerverre, ő válaszol is rájuk, mégis timeout lesz, valószínűleg a B kliens sem kapja meg a csomagokat. Mindez naponta, kétnaponta 1x fordul elő egy tcp kapcsolatnál. Az összes többi kapcsolat a két gép között rendben van, azok is amik ugyan erre a portra (az ügyfélnek valami egyedi alkalmazása figyel rajta) jönnek.
Linux tűzfal kizárva, mert alaposan utánaolvastam és a tcpdump a bejövő csomagokat még az iptables előtt rögzíti. Van központi tűzfalunk is, de azon engedélyezve vannak a szükséges dolgok, illetve máskülönben egyáltalán nem menne a dolog és nem csak napi 5-10 csomag tűnne el. Alkalmazás hibát is kizárnám, hiszen megy ki válasz. Létezhet, hogy mégsem megy ki a csomag a hálózatra, hanem tcpdump után még eltűnik valamelyik bufferből vagy ilyesmi? Bár néztem a net.ip4.tcp_rmem és wmem paramétereket 6 mega a max, és a timeout időszakban (éjszaka) nem volt semmi extra hálózati vagy cpu terhelés a gépen, ami miatt a buffer tele lett volna...
Van ötletetek, hogy mit lehetne megnézni még OS vagy hálózati szinten?
Köszi előre is! Íme a tcpdump:
Szerveren:
Source Destination Protocol Length Info
A S TCP 74 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670891310 TSecr=0 WS=128
S A TCP 54 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670892312 TSecr=0 WS=128
S A TCP 54 [TCP Dup ACK 31921#1] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670894316 TSecr=0 WS=128
S A TCP 54 [TCP Dup ACK 31921#2] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670898320 TSecr=0 WS=128
S A TCP 54 [TCP Dup ACK 31921#3] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670906336 TSecr=0 WS=128
S A TCP 54 [TCP Dup ACK 31921#4] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670922368 TSecr=0 WS=128
S A TCP 54 [TCP Dup ACK 31921#5] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670954432 TSecr=0 WS=128
S A TCP 54 [TCP Dup ACK 31921#6] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
Kliensen:
Source Destination Protocol Length Info
A S TCP 74 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670891310 TSecr=0 WS=128
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670892312 TSecr=0 WS=128
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670894316 TSecr=0 WS=128
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670898320 TSecr=0 WS=128
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670906336 TSecr=0 WS=128
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670922368 TSecr=0 WS=128
A S TCP 74 [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670954432 TSecr=0 WS=128
Hozzászólások
ujra kell inditani a routert meg a switchet hatha
neked aztan fura humorod van...
tisztázni kellene, hogy S és A között pontosan milyen eszközök vannak, van rajtuk bármilyen connection tracking, mert az beleszólhat
mi az a "központi tűzfal"? van rajta bármilyen védelem bekapcsolva?
A gépek közötti hálózat milyen? Csak egy-két switch fix ip-vel és kész, vagy van összetettebb hálózat.
Ha utóbbi, akkor nézd át, nincs-e valami, ami abban a pillanatban konfigurál újra, mint amikor a hiba jelentkezik (pl újra tárcsázott kapcsolat, tunnel, dinamikus routing, ami akkor változik, stb...).
Zavard össze a világot: mosolyogj hétfőn.
A szerver SYN/ACK-ot kell, hogy válaszoljon a kliens felőli SYN-re, nem ACK-t. Talán a kliens oldali firewall eldobja ezt a nem várt ACK-t. A szerver oldali TCP stack-et nézném meg.
Source Destination Protocol Length Info
A S TCP 74 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670891310 TSecr=0 WS=128
S A TCP 54 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0
Sziasztok,
a hálózat elég összetett, eleve virtuális gépekről van szó, van 30+ vas, amiken fut 700+ vm, a fizikai gépek cisco switchekre vannak kötve, a vm-ek pedig külön vlanokban vannak (több tucat vlan van), a tűzfal pedig azt hiszem valami fortinet termék.
Én csak linuxos vagyok, a hálózatot mások csinálják és nincs hozzáférésem az eszközökhöz. Már jeleztem a problémát nekik, de szerintük os vagy alkalmazás oldalon kell keresni a hibát. Úgy gondolom a tcpdump-al már 95%-ra kizártam, hogy os vagy app hiba, mert a csomag elvileg kimegy, de jó lenne 100% kizárni os szinten a hibát.
Kicsit fura ez a tcpdump kimenet, de pár anomália látszik.
- Egyrészt ahogy fentebb mondták, a helyes sorrend SYN, SYN|ACK, ACK. A vissza jövő nem tudni mire ACKot egy jól szituált stateful csomagszűrő el fogja dobni, mert még nincs a connection established állapotban.
-
Másrészt elég látványos, hogy TCP proto 74en jön be a kérés, és 54en megy ki, ami, hát elég gyanús, ráadásul ilyen elborult izékja, az a length, nem szóltam- kissé fura, hogy seq=0 és 1 miközben az ACK valami rendesnek látszó sequence numberre van (az a normális, hogy a seq number nem 0-val kezdődik). Persze lehet, hogy az ott nem a seq number csak valami absztrakció, jó volna látni az igazit.
"Linux tűzfal kizárva, mert alaposan utánaolvastam és a tcpdump a bejövő csomagokat még az iptables előtt rögzíti" -> ebből pont az következik, hogy bizony akár még a szerver tűzfala is el tudja dobni a hibás ACKt. Mondjuk ha tippelnem kellene, inkább valamelyik router csinálja, mert ez már max az OUTPUTon akadna fent, ott meg nem szokott szabály lenni sűrűn Meg akkor jó eséllyel nem is látszana a dumpban, mert:
Ráadásul az van, hogy ez a kijelentés nem is teljesen igaz. A tcpdump a kártyán captureol (kissé pongyolán fogalmazva), szóval befele a local tűzfal előtt, kifele viszont utána. Vagyis befele még látod, ha eldobja is majd, kifele viszont nem látod, amit eldobott. Szóval simán lehet, hogy a local tűzfal dobta el a SYN|ACKot és nem látod. Mondjuk, hogy akkor mire válasz az az ACK
Szóval de, ez egyébként valami szerver oldali elkeffnek tűnik, vagy a tűzfalban, vagy a network stackben, vagy az alkalmazás hálózat kezelésében (ez a legkevésbé valószínű, de java alkalmazást láttam már hasonló szitut szarul kezelni)
- kissé fura, hogy seq=0 és 1 miközben az ACK valami rendesnek látszó sequence numberre van (az a normális, hogy a seq number nem 0-val kezdődik). Persze lehet, hogy az ott nem a seq number csak valami absztrakció, jó volna látni az igazit.
Ez nem hiba. Az ACK mindig a következős sequence numberre mutat. Ha a SYN seq=0, akkor SYN/ACK seq=1. Valójában a Wireshark a tényleges (random) sequence number helyett az első SYN esetén 0-t ír.
nem a 0 után jövő eggyel volt bajom, hanem hogy annak nem kéne nullának lenni, és nem passzolt a leackolttal. De írtam is, hogy lehet, hogy csak valami "okos" :)
Köszönöm lcsaszar és kroozo! Valóban nem vettem észre, hogy ack megy syn-ack helyett... Ez nagy segítség.
Valami anomália van, mert a 2 gép között a timeout előtti bő 5 percben semmi forgalom nem volt.
Az utolsó "jó" csomag beérkezése 21:00:04, ezután a következő csomag 21:05:03-kor jön be, ez pedig a syn-es csomag, amire ack megy azonnal a syn-ack helyett... ráadásul valami nagyon beteg ack number-el...
Igen fut valami javas cucc a szerveren, docker is, és persze hozzá egy rakat iptables szabály... ááá
Esetleg arp-t is erdemes lehet megnezni, hatha valami rossz hirdetest kap/kuld egyik eszkoz es mig ujra frissul a helyessel addig nem jut jo helyre a csomag.
Mintha azt emlitetted vm-ekrol van szo, van esetleg automata online vm migralas hostok kozott, hatha az okozza?
Mennyi routing hop-on megy at forgalom 2 vegpont kozott? Ha sok akkor megprobalhatod traceroute/mtr-el nezni hatha az latszik valamelyik hop-nal akad el olyankor a forgalom.
A linux szerverek logjaban arra az idoszakra esetleg valami kernel bejegyzes (contrack full, drop packet stb.)?
dmesget is, az időnként rejt olyan csodákat, amik nem másznak bele a rendes logba.
Sziasztok, talán megvan a megoldás, ma elkezdtük tesztelni. Majd jelentkezem, hogy megoldotta-e a problémát.
Dióhéjban annyi, hogy az az ack válasz syn/ack helyett nem hiba, hanem "challenge ack" válasz... és ezt viszont a központi tűzfalunk DDoS védelme megfogja, ezért nem jut el a klienshez a challenge ack. A tűzfalon az érintett IP címekre kikapcsolták az anti-reply védelmet a kollegák. Meglátjuk, bizakodó vagyok :)
Bővebben:
https://www.networkdefenseblog.com/post/wireshark-tcp-challenge-ack
https://www.reddit.com/r/fortinet/comments/lho9gm/ack_instead_of_synack/
ui.: egyébként a messages-ben és dmesgben semmi releváns hibaüzenetet nem találtam. Viszont az okos üf minden dockeres és appos logja a messagesbe megy... így hetente 2-3 gigásra hízik.
Eddig ilyesmit csak IIS server komminikációjában láttam... aki feltételezte hogy a böngésző IE, és így gyorsította a kpacsolatot.
zrubi.hu
Ma is tanultunk valamit, köszi :)
Egyébként funky, hogy az RFC hosszan értekezik arról, hogy a middleboxnak nevezett routerek hogyan fogják beszopni, ha nincs rajtuk a proposed FIX, dehát az csak cornercase, és ha majd implementálták a fixet, akkor jó lesz.
Pötyeringet ilyenért már máglyára vetik. :)
Sziasztok,
és igen, megoldotta a problémát, hogy a központi tűzfalon ki lett kapcsolva az anti reply védelem az érintett IP címekre így a "challenge ack" csomagok eljutnak a szervertől a kliensig, azaz megkapja a (nem várt típusú) választ.
Köszi a segítséget! :)
Üdv.