Ntop virtuális interfészre

Hálózatok általános

Tiszteletem,
adott egy linuxos (Debian 5 Lenny) gateway két hálókártyával, az egyik hálókártya (eth0) egy belső hálózatot szolgál ki, a másik hálókártya (eth1) pedig csatlakozik a netre.Ezekhez a hálózati kártyákhoz hozzá vannak rendelve virtuális hálózati interfészek, a két hálózati kártya virtuális interfészei pedig NAT-olva vannak, vagyis (az IP-címek nem valósak, csak példaként szolgálnak):

eth0:1 (192.168.1.1) <== NAT ==> eth1:1 (81.182.72.2)
eth0:2 (192.168.2.1) <== NAT ==> eth1:2 (81.182.72.3)
eth0:3 (192.168.3.1) <== NAT ==> eth1:3 (81.182.72.4)
eth0:4 (192.168.4.1) <== NAT ==> eth1:4 (81.182.72.5)

Szeretném az egyik virtuális interfész (például eth0:2) forgalmát monitorozni ntoppal, tcpdumppal vagy valamilyen hasonló eszközzel, viszont az ntop (illetve a tcpdump) nem hajlandó erre, csak a fizikai interfész (tehát esetünkben az eth0) forgalmának figyelését végzi a virtuális interfész helyett. Viszont ez processzorigényes feladat.

Mint kiderítettem, a gondot az ntop, és a tcpdump által is használt libpcap okozza, ami nem tud különbséget tenni a virtuális interfészek között.

Szóval a kérdésem: hogyan tudnám monitorozni csak egy adott virtuális interfész forgalmát?

  • 1230 megtekintés

( stra | 2011. 10. 07., p – 17:45 )

"az egyik virtuális interfész (például eth0:2)"
Az interface alias nem külön interfész.

"forgalmát monitorozni [...] tcpdumppal"
A tcpdump esetében mi a probléma? Például: 

tcpdump -i eth0 -n net 192.168.4.0/24
tcpdump -i eth1 -n host 81.182.72.5

"Az interface alias nem külön interfész."
Ezért mondtam hogy virtuális - nem valódi, nem is külön - interfészről van szó.

"A tcpdump esetében mi a probléma?"
Csak annyi, hogy nem lehet egy virtuális interfész forgalmát dumpolni (tcpdump -i eth0:2 nem nyerő), csak a valósét. De a tcpdumpot egyébként csak példaként hoztam fel, a lényegesebb az ntop, ahol a fizikai interfészen átmenő nagy forgalom monitorozás eléggé processzorigényes tud lenni - ezért szeretném a kisebb forgalmú virtuális interfészre korlátozni a vizsgálódás tárgyát.

"Ezért mondtam hogy virtuális - nem valódi, nem is külön - interfészről van szó."
Én pedig azért fogalmaztam úgy, mert a lo, dummy0, eth0.2, tun0 virtuális interfész, viszont valóban külön interfészként működik, míg az interface alias nem.

"nem lehet egy virtuális interfész forgalmát dumpolni (tcpdump -i eth0:2 nem nyerő), csak a valósét."
Ez csak részben igaz. Az előző példámban lévő paraméterekkel, azaz az interface alias címtartományával kevés kivételtől eltekintve (pl.: limited broadcast, egyéb L2 forgalom) jól meghatározható és szűrhető.

"a fizikai interfészen átmenő nagy forgalom monitorozás eléggé processzorigényes tud lenni"
Az interfész alias-szal nem nyersz semmit - tekintve hogy teljesen ugyanarról az interfészről van szó.
Ha külön kezelhető interfészt szeretnél, az eth0 oldalát szétszedheted VLAN-okra, és csinálhatsz hozzájuk VLAN interfészt (eth0.2). Ez természetesen a csatlakozó eszközre (switchre) is vonatkozik, ebben az esetben ott is trönkölni kell. Vagy használhatsz 4 fizikai interfészt.

"ezért szeretném a kisebb forgalmú virtuális interfészre korlátozni a vizsgálódás tárgyát."
Szoftveresen szűrhető a figyelni kívánt forgalom típusa. Az ntop is tud ilyet, a tcpdump is. Ez a topológia ezzel jár. A PunishR által lent említett ipac-ng is, vagy például a net-acct is ebbe a kategóriába tartozik.

( subchee | 2011. 10. 07., p – 20:34 )

"Virtual and aliased interfaces cannot be monitored because the kernel doesn't provide traffic information for that type of interfaces. Such interfaces are usually named eth0:0, eth0:1, eth0:2 etc. where eth0 is the actual interface being aliased."

http://humdi.net/vnstat/man/vnstat.html

( PunishR v | 2011. 10. 07., p – 21:03 )

Régen ipac-ng segítségével lehetett szépen mérni ip/ip tartomány alapon a forgalmat.