Látom, hogy próbálkozol, de ne rángass egyszerre nyolc dolgot, mert sose jövünk rá, hol van a baj.
Először is, minden olyan gépet, ami wifin lóg, vagy a routerre van dugva felejts el egy pillanatra. A két teszt eszköz legyen a switchen. Így ki lehet zárni, hogy a sagem kever be valami obskúrus hülyeséggel (kivéve, ha még a routeok is el vannak cseszve, de az az ip r alapján talán nincs).
Másodszor is, próbáld meg átadni, hogy mit csináltál, és akkor éppen mi történt, mert így lehetetlen követni. Nem tudjuk, melyik gépen futott a tcp dump, nem tudjuk, az iptableskor ki volt-e kapcsolva a tűzfal, ilyesmi. Az sem segít, hogy szelektálva copypasztázod mondjuk a tűzfal konfig tartalmát.
Alapvetően azt kellene megnézni, hogy mikor nem megy, akkor hol akad el. A folyamat kb a következő, mikor kiadod a ping parancsot
- Először is végig megy egy arp kérés-válasz a két gép között:
- ki tudja <kliens-ip> mac címét?
- <kliens-ip> mac címe <valami>
- Aztán megy egy
- icmp-echo-request és
- rá válaszul egy icmp-echo-reply
(Kicsit bonyibb, mert nem biztos, hogy van arp, illetve simán lehet egy az icmp request és reply között, ha a szerver nem tudja épp a kliens mac címét)
Mindkét csomag a következő útvonalat járja kb be ("kissé" leegyszerűsítve a dolgot):
- kliens (ping forrás) routing tábla
- kliens tűzfal (tűzfal logolással lehet ellenőrizni, esetleg interface és tűzfalszabály számlálók bámulásával)
- kliens kimenő interface (tcpdumppal lehet ellenőrzni)
- fizikai réteg (switch)
- szerver (ping cél) bejövő interface (tcpdump)
- szerver routing
- szerver tűzfal (tűzfal log)
- szerver program válasz csomagot csinál (ez ping esetében a kernel, de az most kb mindegy), majd a csomag szépen elindul visszafele
- szerver routing
- szerver tűzfal
- szerver interface
- fizikai réteg
- kliens interface
- kliens routing
- kliens tűzfal
- a ping, amit örül a pongnak
Kb a következőt lehet tudni:
- Ha már a 3. ponton sem látszik a kimenő csomag, akkor vagy a routing van nagyon elbaszva, vagy a tűzfal output láncon megfogja a csomagot. Valószínűtlen
- Ha 3. még van, de 5 már nincs, akkor van valami nagy szar a switchel. Vagy beteg, vagy valami MTU baszás esetleg. Ez utóbbi szinte kizárható, error számlálókat érdemes nézni.
- Ha 7-ig nem jutunk el, akkor valami a szerver routingjában szar, valószínűtlen
- Normál esetben lehetne nézni, hogy van-e log az appban, de ez itt kernel, szóval sajna nem nagyon fog menni
- Szóval legközelebb az látszik, hogy a válaszüzenet átment-e a tűzfalon, akár az input láncon el tud akadni a bejövő csomag (7.), akár az outputon a válasz (10.)
- Ha a 11en még látszik a reply, akkor ezeken túl vagy
- Ha ezek után a 13. nem látja, akkor megintcsak switch para
- Ha igen, akkor jó eséllyel az utolsó dolog valami bejövő tűzfal elbaszás
Nekem az az érzésem, hogy az ufw disable meg reset nem azt jelenti, amit gondolsz, hanem egy alap, elég restiktív szabályrendszert. A durván lecsupaszított iptables default DROPjából az inputon én erre következtetnék, főleg, hogy ha jól értem, a tcpdump a szerveren készült, ahova a csomag még bejött, ki meg már nem ment, szóval valahol a 6-10 pont között halálozott el, az meg kreténül elbaszott routingot leszámítva a tűzfal. Szóval olvasd el annak az izének a manját.