iptables TRACE ID=0

Linux-haladó

készítettem az iptables TRACE target moduljára épülő web-es frontendet, ami a tűzfalunk debuggolására való.
http://code.google.com/p/iptables-trace-utility/
a kernel log-ba soronként kerülő, egy csomag útvonalát leíró lépéseket az ID= mező alapján társítom össze, ez alapján jelenik meg a Packets fieldset-ben a csomagot szimbolizáló szám és a Trace dobozban a csakis hozzá tartozó lépések.
viszont sokszor előfordul olyan trace log (jellemzően egy csomaghoz tartozóan, ami leginkább udp), ahol ID=0, ebből nem egy van, így nem tudom egyértelműen megkülönböztetni, mely log sorok tartoznak össze.

mit jelent igazából az ID mező, okos dolog-e ez alapján csoportosítani? (icmp-k esetében 2 is van)
bug-e az ID=0?
mi alapján csoportosítsam a csomag lépéseinek log bejegyzéseit ha nem az ID mező alapján?
érdemes-e heurisztikusan (időbélyeg alapján) külön csomaghoz tartozónak feltételezni az ID=0-ás sorokat?

( secretx v | 2014. 11. 11., k – 14:36 )

Tudomásom szerint az egyik ID= a process ID-ja ami generálja a packetet a TRACE-ben ( a második ID=...).
Pl. elkezdesz pingelni a hostról, akkor a ping id-ját kapja meg.
Az első jó kérdés mi lehet, remélem lesz aki tudja és elmondja, már engem is érdekel :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( bAndie9100 | 2014. 11. 11., k – 15:07 )

nat-olt hálózaton belülről pingelek a világba', a gateway-en fut az iptables trace.
a ping csomagoknak az 1. ID értéke csomagonként növekszik (valószínűleg jó az egyedi azonosításhoz), a 2. ID állandó egy ping session-ön belül.
a pong csomagoknak az 1. ID-ja 0, a 2. szintén állandó de nem azonos a ping-ek 2. ID-jával.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

tényleg az az IP fejléc ID-ja!
már csak a pong csomagok 2. ID-ját nem tudom honnan veszi.
de igazából nem is az a fő kérdés, hanem hogy mitől lesz egy IP ID 0, vagy hogy vehetem rá a tűzfalat, hogy legalább ő adjon neki egy azonosító számot, hogy követni lehessen?

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Az Echo Reply ugyanazt az ICMP ID-t tartalmazza, mint a Request.

Nem teljesen értem ezt a követést. Ha a logban, a trace kimenetében akarod követni a csomagot, akkor pingelésről beszélve a (src IP, dst IP, IP identifier, ICMP identifier, ICMP Sequence) alapján tudod ezt megtenni. Ha a Reply-t akarod a Requesthez kikeresni, akkor IP ID nélkül, a forrás és a cél felcserélve.

Ugye jól sejtem, hogy nem általánosan szeretnéd a visszirányt az előreirány csomagjaihoz társítani?

az icmp csomagok csak azért merültek fel, mert ezekben tapasztaltam hogy 0-ás ID-juk lenne. és igen, a pong-oknál 0 az IP ID:
ID=0 PROTO=ICMP TYPE=0 CODE=0 ID=9661 SEQ=1
az icmp ID az oké (a ping-pong ID különbséget valószínűleg félrenéztem).

én megelégszem az IP-szintű követéssel, tehát egy csomagnak csak a tűzfalon való haladását szeretném látni (iptables szabályok debuggoló cucca ugye).
nem akarok request-reply csomagokat összerendelni vagy tcp stream-et követni. bőségesen elég az IP csomagok követése.
ezért nincs visszirány, előreirány. csak az iptables chain-ek, táblák érdekelnek, amit a TRACE is loggol.

egyedül az egyes lépések (mangle:FORWARD:policy:1, filter:FORWARD:rule:5, ...) összekapcsolása a gondom, mivel semmi nem garantálja, hogy a több csomag útját leíró log sorok nem keveredjenek egymás közé.

nem akartam eddig bonyolultabb összerendelési módszert csinálni, annál minthogy az azonos ID= mezőket tartalmazó sorokat tekintem egy csomag állomásainak.
tehát ip src, ip dst mezőket figyelni... kiváltképp azért mert azok egyszerűbb tűzfalakon is simán változhatnak (SNAT, DNAT), protokol-specifikus mezőket mégkevésbé kevernék a dologba.

az ip header id-ja eddig jó választásnak tűnt, eltekintve hogy olykor zéró.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack