dhcpd és dhcp-relay esete az iptables-al

UNIX haladó

Sziasztok!

Egy (beismerem kissé kusza) DHCP/DHCP-RELAY egyveleg szivat, ebben kéne egy kis segítség vagy infó.
Ez egy főiskola hálózata, ahol van két Windows AP fa, és egy jópár vlan. A Windows domain-ben lévő gépek DHCP szervere a megfelelő Windows szerver. Ahol nem kapcsolódnak közvetlenül a kliensek, ott (általában) egy ProCurve 5406zl switch továbbítja a DHCP kéréseket, és a switch a router is.
Néhány VLAN-ban ahol a gépek nincsennek a domain-ben, ott a DHCP szerver (és a defaulr router/tőzfal-is) egy ubuntu szerver (8.04). Van egy VLAN (ez keverte meg a dolgokat), ahol a gépek Windows kliensek, beléptetve a domain-ba, de ezek egyébb okok miatt az Ubuntu tűzfal mögött vannak. Ennek néhány következméne:
Mivel ebben a VLAN-ban az 5406zl-nek nincs IP címe (nem ő rout-ol) nem lehet ő a DHCP-RELAY sem.
Egyébb okokból a tűzfal nem kapcsolódik ahhoz a VLAN-hoz amiben a DHCP SZERVER van:
(kliens gépek, VLAN3038)---[tűzfal ubuntu]---(VLAN3001)---[router 5406zl]---( DHCP szerver, VLAN3016 ).
A VLAN3001-ben is van ugye egy DHCP szerver, de az egy másik domain.
A felállás tulajdonképpen működik, csak van egy szépséghibája. A tűzfalon futó dhcp-relay szerver hallgatózik a vlan3038, és vlan3001-es interfészen is, ezért ha a vlan3001-ből jön egy DHCP kérés, akkor azt is továbbítja a vlan3016-ban lévő DHCP szerver felé, amit a DHCP szerver eldobb, mert a 3001-es vlan nem rá tartozik.
Úgy gondoltam, hogy ezt a kis szépséghibát tűzfal szabályokkal megszüntetem. Megírtam a tűzfalszabályokat, és nem működnek, csak annyi derült ki számomra, hogy valamit NAGYON NEM ÉRTEK.
A jelenség:
A tűzfal szabályok (input oldal, számlálókat töröltem, hogy ne legyenek tú hosszú sorok):
Chain INPUT (policy DROP 0 packets, 0 bytes)
target prot opt in out source destination
ACCEPT all -- lo any anywhere anywhere
internetioi all -- eth1 any anywhere anywhere
ACCEPT icmp -- any any anywhere anywhere
tunioi all -- tun+ any anywhere anywhere
dhcpdioi udp -- any any anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc
...
Az INPUT láncban (az eth1-az internet felé néz) a DHCP-vel kapcsolatba hozható csomagok mennek a dhcpdioi láncra:
Chain dhcpdioi (1 references)
target prot opt in out source destination
ACCEPT udp -- eth0 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3059 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3060 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3038 any anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT udp -- vlan3001 any anywhere anywhere udp spt:bootps dpt:bootps
LOG all -- any any anywhere anywhere LOG level warning prefix `DROP_DHCPi'
DROP all -- any any anywhere anywhere
Az eth0, vlan3059, vlan3060, vlan3038 -on fogadom a DHCP kéréseket a kliens felöl, a vlan3001-en fogadom a választ a DHCP szerver felől, minden mást loggolok, és eldobok. Ez alapján eldobom (el kellene dobni) a vlan3001-ből jövö DHCP kéréseket is.
Ehez képest a tcpdump eredménye, ha egy DHCP kérés érkezik a vlan3001-ből:
08:29:27.015699 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:f1:e4:c9:70, length 300
08:29:27.016106 IP 172.20.1.253.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
08:29:27.018611 IP 172.20.1.3.67 > 172.20.16.254.67: BOOTP/DHCP, Request from 00:0c:f1:e4:c9:70, length 300
A kliens kérésére (1.blokk) megjön a válasz az ottani dhcp szervertől (172.20.1.253), majd a harmadik blokkban látszik, hogy a dhcp-relay is továbbítja a kérést az általa ismert DHCP szervernek. Ha az első blokk el vagyon dobva, akkor mit keres a dump-ban, és miért válaszol rá bárki. A dhcpdioi láncban látszik is a találat az utolsó két szabályra, és ez a kernel log-ban is látszik:
Mar 20 08:51:33 mano kernel: [169919.075936] DROP_DHCPiIN=vlan3001 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:f1:e4:c9:70:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308

Bár ez a kis anomália nem okoz a kliensek szempontjából problémát, de engem nagyon elbizonytalanított.
Valaki homályosítson fel, mi a fene történik itt.

  • 2417 megtekintés

( kadlec | 2009. 03. 20., p – 11:34 )

A VLAN-ok Layer 2 szinten vannak: ebtables-el tudod kiszűrni, hogy a DHCP az adott VLAN-ba maradjon. Az iptables egy réteggel följebb van, ezért hatástalan.

Bevallom őszíntén én a válaszodat nem nagyon értem.
Nekem eddig úgy tűnt, és úgy gondoltam hogy ezt a részt értem is, hogy a DHCP mindíg az adot VLAN-ban marad, ezért kell a DHCP-RELAY, hogy az egyik VLAN-bol áttegye a kérést a másikba.
Eddig én úgy gondoltam, az hogy jelenleg VLAN-ok vannak, az csak annyit jelent, a jelenlegi probléma szempontjából, hogy a különbözö szegmensekhez (amik most VLAN-ok) nem kellenek fizikailag különböző switch-ek és interfészek. Az eth0-hoz rendelt vlan3001 és vlan3038 interfészek az iptables-ben logikai szemponból egyedi interfészek.
Rosszul tudom ?

A dhcp-relay-el az egyik VLAN DHCP forgalma belekeveredik a másikéba, nem ez a probléma?

Az iptables számára IP szinten a vlan3001 és vlan3038 egyedi interfészek, persze. De a DHCP Layer 2 szinten van és a dhcp-relay már az előtt elkapta a csomagot, hogy az iptables láthatta és kiszűrhette volna.

Nem áll szándékomban vitatkozni, de itt most az lenne a cél, hogy én is értsem, bár ez jelentősen megnehezíti a feladatot :). Javíts ki ha tévedek, de a DHCP az UDP csomagokkal kommunikál, számomra ebből nem következik, hogy Layer 2 lenne.
Amúgy logikusan hangzik, hogy a dhcp-relay még a iptables elött megkapj a csomagot.
Egy kicsit gugliztam is, többen állítják, hogy a DHCP layer 2, és többen azt is hogy nem, már ahol ez szóbakerül (csak a magyar nyelvűeket néztem egyenlőre).

Alapvető tévedésben éltek, én nem vontam kétségbe egyetlen állítást sem, meg szerettem volna érteni a dolgot, amiben néhány (vélt) ellentmondás megakadályozott, és amiről eddig a válaszokban nem sok szó esett.
Végeztem néhány tesztett, és ebbő arra a következtetésre jutottam, hogy a dhcpd és a dhcp-relay az iptables-től függetlenül működik, de azt továbbra sem értem, hogy miért.
Azt, hogy nincs a kliensnek IP címe, azt elvi kérdésnek tartom, elvei embereknek vannak, programoknak nincs ojanjuk. A DHCP protokol általam olvasott "népszerű tudományos" leírásai arra utalnak, hogy az IP cím hiányát azzal hidalják át, hogy broadcast csomagokat küldenek, layer-ekről pedig nem esik szó. Persze születhetett olyan döntés, hogy elvi okokból a DHCP-t layer2-ként kell kezeli, de ezzel engem jól megkavartak (ez persze nem szempont, csak nekem kellemetlen). És kezelhetik a DHCP-t layer2 ként olyan okból is amit én nem ismerek, és amiről eddig nem volt szó.

Ha lerövidítem a DHCP kérés útját, akkor egyébb helyen és egyébb szempontból ütközöm olyan problémába, amit jelenleg nem tudok orvosolni, és amivel nem akartam terhelni senkit. Induljunk ki abból, hogy oka van.

OK, de számomra rejtély, hogy a 5406zl egyik oldalán vlan3001 van másik oldalán meg vlan3016. Legalább az egyik felesleges.
Anélkül, hogy ismerném a hálózatod én így csinálnám ill. részben csinálom is:
- alapfeltétel, minden eszköz vlan képes
- 5406zl-ben a kliensek felé untagged módban a vlan3001 néz.
- 5406zl-ben a dhcp szerver felé tagged módban a vlan3001 néz.
- a dhcp szerverben van vlan3001 megfelelő ip címmel, kiosztható tartománnyal stb.
- az ubuntu tűzfalat a 5406zl egy üres portjára rádugnám, belelógatnám a vlan3001-be meg valami másik vlanba és aztmondanám, hogy mostantól a klienseknek ez az átjárójuk. Tűzfalconfig, routing config. Késsz. (a 5406zl-nek nem is kell ip-nek lennie a vlan3001-ben)

De mégszer mondom, kívülrűl könnyű okosnak lenni, nehéz átlátni.

Mik

A hálózatban van 2db Windows AD fa, az egyikhez tartozik a vlan3001, a másikhoz a 3016, a hálózat egy része független a windows rendszertől. A routing-ot azon vlan-ok között, ahol nem létszükséglet a tűzfal, ott az 5406zl végzi, mert nincs olyan linux vasam, amelyik birná a forgalmat (végpontok száma 1000 felett, kb 30 kiszolgáló, 3 tűzfal, kb. 60 vlan).
Három lehetőségem van:
Az ominózus linux tűzfal a 3016-ra csatlakozik, más szempontok alapján viszont jobb a 3001-es vlan.
A tűzfal a 3001 és 3016-ra is csatlakozik, ekkor a routing lessz egy kicsit áttekinthetetlen a redundáns utak miatt.
Két tűzfalat használok, de kétlem, hogy ettől egyszerűbb lenne az életem. És a "fűtőtestek" száma már így elég nagy.
Biztos lehet javítani a logikai topológián, de nem hiszem, hogy ennek megtérgyalása/kitalálása ide tartozik. Persze ha sok a szabadidőd, szivesen megmutatom a rendszert, és tanácsokat is szivesen fogadok :).

( Zs | 2009. 03. 20., p – 16:56 )

Alapvetően az a problémám, hogy a DHCP arról szól, hogy a gép elkéri a DHCP szervertől, hogy milyen beállításokkal is fusson. Addíg, amíg nincs értékelhető válasz, addíg a gépnek nincs IP címe.
Innen kezdve mit akarunk szűrni iptables beállításokkal? Az csak IP alapú forgalom szűrésére/manipulálására szolgál.
Tehát vagy ahogy fentebb is írták: ebtables, vagy a dhcp-relay-t úgy belőni, hogy csak az egyik szegmensből a másikba dolgozik, nem pedig bárhonnan tol tovább.

A DHCP csomagokban van IP cím: 0.0.0.0 vagy 255.255.255.255, ha az IP cím még nem ismert (látszik a dump-ban is, és eljut a csomagszűrőhöz is ld. log, de el mégsem dobja).
A DHCP protokol UDP alapú (az UDP meg IP alapú), van portja is, ez alapján pedig layer 4.
Guglin a "dhcp layer"-re rákeresve az összes dukumentáció szerű iromány a DHCP-t layer 3-as protokolként pozicionálja. Néhány forumon pedig layer 2-nek gondolják, mivel az ip cím ismeretlen.
Én a fentiekben több ellentmondást is vélek felfedezni, ez pedig erősen akadályoz a megvilágosodásban.
Ha ismételten kinyilatkozzuk, hogy a DHCP az layer 2, az megmagyarázza az iptables fura működését (a megfigyeléssel nem ellentétes), de nem oldja fel az ellentmondásokat, és nem visz előrébb a probléma megértésében.
A dhcp-relay-t szivesen beállítanám, ahogy mondtad, de eddigi tudásom szerint nem lehet. Ha Te tudsz rá módszert ne kímélj.

Az, hogy a DHCP protokollt UDP-ben, IP fölött valósították meg, szerintem pusztán azért van, mert (nagyon helyesen) a Layer 2 rétegtől akarták függetleníteni: lehessen használni Etherneten, PPP-n, WLAN-on, bármin, ami IP továbbítására képes.

De ez nem jelenti azt (megint csak szerintem), hogy ténylegesen nem Layer 2 szinten működő protokoll: a DHCP "kliensnek" még nincs IP címe, tehát IP szinten csomagot sem tud fogadni. Kénytelen a link rétegben elfogadni és kezelni a megfelelő formátumú csomagot. Ez már onnan is látszik, hogy a dhcp szerver/kliens raw socketet nyit és nem INET socketet (ahogy az IP/UDP-ből következne). És ezért - amit a tapasztalataid is megerősítenek - az iptables nem tud hatással lenni a DHCP-re. Talán segít még, ha megnézed a http://jengelh.medozas.de/images/nf-packet-flow.png rajzot: a DHCP a kék színű rétegben zajlik, míg az iptables a zöld rétegben.

Jó, akkor ezt a megértés témát most feladom.
Egy kérdésem viszont lenne:
Milyen iptables szabályok kellenek a DHCP-hez. El kell/lehet dobni a csomagokat?
Eddig mindig beírtam a szabályok közé a DHCP forgalom engedélyezését, próbaképpen kikommenteztem, és a log tele van azzal, hogy dobálja a csomagokat, de eddig nem látszik más hatás.