[Linux] dhcrelay-agent probleem

Pagina: 1
Acties:

  • HolyCorn
  • Registratie: Juli 2002
  • Niet online
Ik heb een linux bak die als server/firewall dient voor ons interne netwerk. Intern draait het netwerk op de 192.168.0 reeks. De server heeft 2 NIC's, 1 met 192.168.0.1, en 1 met een vast door DHCP toegewezen (extern) IP.
We hebben echter 4 externe IP's toegewezen gekregen, en nu wilde ik op 1 client ook een extern IP via DHCP aanvragen.
Zou op zich moeten kunnen via dhcrelay, maar hier gaat het dus fout. De DHCP-requests worden wel ontvangen op de linux-bak, en doorgestuurd naar de DHCP-server, maar deze geeft hierop geen antwoord. Na een tcp-dump viel het me op dat de request die doorgestuurd wordt naar de dhcp-server, poort 67 voor zowel sourceport als voor destinationport gebruikt.
Zou dit het probleem kunnen zijn? Want een normaal DHCP-request heeft als sourceport poort 68. Kan het zijn dat er op de DHCP-server zo streng gefilterd wordt dat een request van poort 68 moet komen?
Iemand een idee wat er fout gaat? (En hoe op te lossen natuurlijk ;) )

  • HolyCorn
  • Registratie: Juli 2002
  • Niet online
*beschaafd schopje..*
Ik heb zelf nog geprobeerd om via iptables de source-port van de uitgaande DHCP-request te veranderen naar 68, maar uit een dump van het verkeer lijkt het request nog steeds van poort 67 te komen :? Heb hiervoor de volgende regel toegevoegd aan m'n firewall-script:
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -p udp --sport 67 --dport 67 \
-j SNAT --to-source $INET_IP:68
Met:
$INET_IFACE voor de nic verbonden met internet,
$INET_IP voor het internet IP (duh...)
Toch wordt de sourceport niet veranderd.

Ik weet zowiezo niet of het hieraan ligt, maar waarom wordt de poort niet naar 68 gemapt?

Edit:
logfile van de firewall:
on INPUT : IN=eth1 OUT= SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=57869 PROTO=UDP SPT=68 DPT=67 LEN=308
on OUTPUT: IN= OUT=eth0 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=13840 DF PROTO=UDP SPT=67 DPT=67 LEN=308

xxx.xxx.xxx.xxx is dus m'n externe IP van de linux-server
Je ziet dus dat de requests worden ontvangen op de box (on INPUT), en dat ze worden doorgestuurd naar de dhcp-server (yyy.yyy.yyy.yyy on OUTPUT), maar wel met source-port 67 ipv. 68 8)7

[ Voor 35% gewijzigd door HolyCorn op 09-05-2003 21:42 ]


  • HolyCorn
  • Registratie: Juli 2002
  • Niet online
Helemaal niemand? :'(

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 02-05 18:38

deadinspace

The what goes where now?

Je voegt de rule aan de POSTROUTING chain van het nat target toe... Als ik me niet vergis gaat daar alleen verkeer doorheen dat van het ene netwerk-segment naar het andere geroute wordt. Die DHCP requests daarentegen worden (technisch gezien) niet geroute, maar ontvangen door dhcp-relay en even later weer verstuurd door dhcp-relay.

Omdat dhcp-relay dus een lokaal draaiend process is, is dat gewoon uitgaand verkeer, geen gerouted verkeer. Waarschijnlijk moet je dus een dergelijke regel in de OUTPUT chain opnemen.

Alternatief zou je het DHCP request met iptables kunnen proberen te forwarden. Dan is de source port sowieso de port waarvandaan de machine op je interne netwerk hem verstuurde (dat is neem ik aan wel 68).

  • HolyCorn
  • Registratie: Juli 2002
  • Niet online
Hmm, als je kijkt naar het volgende plaatje, dan lijkt het dat al het uitgaande verkeer ook door de postrouting-chain moet: Afbeeldingslocatie: http://iptables-tutorial.frozentux.net/images/tables_traverse.jpg

Maar ik heb ook nog wat zitten klooien in de output-chain, maar daar kun je dus geen source-port veranderen, maar alleen de destination.. |:(
Ik heb ook al zitten denken om het gewoon via iptables te proberen te forwarden, maar het probleem is dat de linux-box zelf ook via DHCP z'n IP krijgt, dus dan gaat dat weer conflicteren...

Ik weet het echt niet meer, wat ik verder nog kan proberen.. 8)7