( XMI | 2024. 08. 12., h – 14:08 )

Na, ebből nem fogjuk megfejteni. Próbállak megtanítani halászni.

Pár jótanács a hálózat-debuggoláshoz:

  • tcpdump-nak van egy -w paramétere, amivel pcap file-ba írja, amit begyűjtött. A pcap file-t utána wiresharkkal meg tudod nyitni, GUI-n kielemezni.
  • tcpdump-nál előfordulhat, hogy -s paraméterrel meg kell emelni a maximális csomagméretet, mondjuk 9000 byte-ra vagy valami hasonlóra. Bizonyos verzióknál a default túl kicsi (64 byte?) és levágja a csomagok törzsét, ami lehet, hogy lényeges infót dob el.
  • Óraszinkron nagyon fontos! Amennyire csak lehet, járjanak együtt az órák a két oldalon, különben esélyed sincs összepárosítani az egyik oldalon kiküldött, másikon megérkezett csomagokat. Ha NTP tud működni az érintett gépeken, akkor működjön. Még így sem fognak a timestamp-ek tökéletesen stimmelni, mert a csomagoknak idő kell, míg odaérnek, de legalább a kauzalitások követhetőek lesznek.
  • Amíg nincs viszonylag jók körülhatárolva hiba, addig ne szűrj portra a capture-ölésnél. Lehet, hogy pont a session-ön kívüli csomagok (pl ICMP errorok vagy ARP kérések) lesznek a megoldás kulcsai.
  • Triviálisnak hangzik, de a fentiek alapján úgy tűnik mégsem: ugyanazt az egy sessiont vedd fel szerver és kliens oldalon egyszerre. Ne egy tcp/22-es scp-t és a egy tcp/445-ös SMB másolást próbálj összehasonlítani.
  • Ha a hibát iperf-el tudtad reprodukálni, ahogy valahol írtad, (esetleg netcat-tal érdemes lehet még megpróbálni), akkor azt capture-öld le. Minél kevesebb egyéb változó (autentikáció, diszkírás stb) tudjon belezavarni.