Văd o problemă ciudată cu o conexiune prin cablu la un router de pe LAN, unde traficul TCP este eliminat și înregistrat ca un pachet fragmentat.
Scenariul are MTU setat la 1500 pe clienții de rețea și pe adaptorul Ethernet al routerului (conform afișează adresa ip).
Exemplu de mesaj de pachet eliminat (divizat în mai multe linii pentru a fi lizibil):
12 mai 09:44:05 kernel: DROP IN=eth0 OUT=tun11 MAC=<eliminat>
SRC=<IP desktop> DST=<IP destinație externă>
LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=54356 DF PROTO=TCP SPT=53370 DPT=443 SEQ=3216568911 ACK=0
WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080A002E76880000000001030307) MARK=0x8000000
Dintr-o citire ușoară pe TCP/IP, pot vedea că opțiunea 0204 se referă la MSS și dimensiunea pare să fie 1460, deși mă chinui să înțeleg la ce se referă octeții rămași (0402 080A 002E 7688 0000 0000 0103 0307). Nu văd nicio regulă de firewall pe router care aplică deloc un marcaj, dar am cunoștințe detaliate limitate despre netfilter.
Când încerc să calculez dimensiunea maximă MTU prin ping -M do <IP router> -c 2 -s 1500 răspunsul clientului este eroare locală: mesaj prea lung, mtu=1500 sau când ping cmd folosește o dimensiune MTU mai mică pentru a testa, niciun răspuns / toate pachetele eșuate.
În primul, reduc MTU-ul cu 28 și apoi obțin scenariul din urmă. Presupun că acest lucru înseamnă că MTU este adecvat, dar pachetul este încă abandonat. Exemplu de intrare în jurnal de router pentru această picătură:
12 mai 13:01:01 kernel: DROP IN=eth0 OUT= MAC=<eliminat>
SRC=<IP desktop> DST=<IP router>
LEN=1378 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=ICMP TYPE=8 CODE=0 ID=5 SECV=1 MARK=0x8000000
Când identific un MTU mai adecvat folosind ping testați și reporniți desktopul, pachetele continuă să fie fragmentate și ping testul returnează apoi un MTU mai mic (cu 28 de octeți mai puțin de fiecare dată).
Desktopul rulează Kubuntu 20.04.4.
După un timp semnificativ în care am încercat să înțeleg mai multe despre acest scenariu, am încercat să adaug urmând regulile iptables pe router:
-A INPUT -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
Dar asta nu a rezolvat problema.
Asta face nu se întâmplă pe dispozitivele Android conectate la același router prin WiFi. Routerul este repornit peste noapte conform unui program și Xbox-urile se confruntă cu același scenariu de fragmentare/scădere de pachete până când sunt repornite cel puțin o dată. Un XBox se conectează prin WiFi, unul prin cablu la un router conectat la routerul problematic.
Traficul dintre routerul WiFi și routerul edge pare a fi neafectat - niciun semn de scădere a pachetelor din cauza fragmentării la nivelul respectiv.
Soluție
Am descoperit că alergarea a traceroute din bash pe desktop deblochează cumva problema
Înainte și după această „remediere”, adaptorul LAN pentru desktop este listat cu același MTU, în timp ce dacă MTU ar fi trebuit ajustat, m-aș fi așteptat ca această valoare să fie schimbată (și apoi l-aș putea seta ca implicită):
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
Totuși nu înțeleg De ce cel traceroute se pare că rezolvă problema. Orice sugestie va fi primită cu recunoștință în acest moment.
