ISC DHCP 2 Subnetze
Hallo,
ich betreibe bei mir im Netzwerk einen ISC DHCP Server auf Debian,
der DHCP verwaltet aktuell ein /24 ,was auch super funktioniert.
nun soll ein weiteres Flash /24 hinzugefügt werden.
Aktuell schaut meine Config so aus:
authoritative;
default-lease-time 86400;
max-lease-time 86400;
subnet 192.168.0.1 netmask 255.255.255.0 {
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name local
hinzukommen soll jetzt noch das Netz 192.168.1.1/24
wie muss ich meine Konfig anpassen ?
einfach das Subnet erweitern geht nicht, da eich es so nicht routen kann.
ich betreibe bei mir im Netzwerk einen ISC DHCP Server auf Debian,
der DHCP verwaltet aktuell ein /24 ,was auch super funktioniert.
nun soll ein weiteres Flash /24 hinzugefügt werden.
Aktuell schaut meine Config so aus:
authoritative;
default-lease-time 86400;
max-lease-time 86400;
subnet 192.168.0.1 netmask 255.255.255.0 {
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name local
hinzukommen soll jetzt noch das Netz 192.168.1.1/24
wie muss ich meine Konfig anpassen ?
einfach das Subnet erweitern geht nicht, da eich es so nicht routen kann.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 365541
Url: https://administrator.de/contentid/365541
Ausgedruckt am: 09.11.2024 um 01:11 Uhr
24 Kommentare
Neuester Kommentar
Hier findest du alle Antworten auf deine Frage und eine Abtipp fertige Konfig:
Netzwerk Management Server mit Raspberry Pi
Netzwerk Management Server mit Raspberry Pi
Hi,
soll das über eine NIC laufen?
Falls ja, habe ich folgendes Beispiel gefunden:
Ein anschließender
sollte dann schicken.
Netzwerknamen & interfaces sind natürlich an deine Umgebung anzupassen.
Quelle meiner Informationen
Gruß Yannosch
soll das über eine NIC laufen?
Falls ja, habe ich folgendes Beispiel gefunden:
shared-network my-net {
subnet 10.1.1.0 netmask 255.255.255.0 {
...
}
subnet 10.1.2.0 netmask 255.255.255.0 {
...
}
subnet 10.1.3.0 netmask 255.255.255.0 {
...
}
}
Ein anschließender
dhcpd -4 eth2
sollte dann schicken.
Netzwerknamen & interfaces sind natürlich an deine Umgebung anzupassen.
Quelle meiner Informationen
Gruß Yannosch
Debian / Ubuntu Clients bekommen so keine Default route mehr.
Mmmhhh...wie sollen wir das jetzt verstehen ?? Ist das jetzt gut oder schlecht und ein Fehler ??Kann auch niemals stimmen, denn das was dort im Server unter "Gateway" definiert ist, ist immer das Default Gateway was per DHCP propagiert wird.
Und zwar an alle Clients egal ob Winblows, Linux, MacOS, Smartphones oder was auch immer.
Ich zeig dir mal ein Beispiel aus unserem Netz:
Zur Erklärung: Der DHCP Server steht mit seiner eigenen Adresse im Netz: 10.0.0.128 in einem Netz. In diesem Netz soll KEIN DHCP gemacht werden. Damit der Dienst läuft (sonst meckert er) muss man aber das Subnetz was auf dem Interface liegt anlegen. Wie kommentiert ist, halt ohne eine Range zu definieren.
Dann folgen zwei andere Netze die der DHCP-Server versorgt. Die Netze werden über Cisco Switche und die ip adress helper an den DHCP-Server weitergeleitet. In dem Fall sind das WLAN Netze die in einem VLAN laufen und in dem Vlan steht als ip helper eben der dhcp server drin.
Das ganze läuft über ein Interace. Die Option mit shared-network würde ich dafür nicht verwenden. Ich weiß gerade nicht mehr warum, aber das hat nicht funktioniert. Dafür gab es einen Grund. Müsste ich mal grübeln. Einfach die Subnetze so anlegen wie in meinem Beispiel.
Deine Config könnte dann so aussehen:
Dafür brauchst du aber auch in dem Netz 1.1 einen Router/DNS Server. Der eben das Netz verbindet und die Adressen Routet. Soll einfach nur der DHCP-Bereich vergrößert werden von 192.168.0.0 bis 192.168.1.1 machst du folgendes:
Denk aber daran auch deinen Router entsprechend auf das größere Netz zu konfigurieren.
Fertig Noch fragen? :D
pi@lxraspberrydhcp:~ $ cat /etc/dhcp/dhcpd.conf
authoritative;
ddns-update-style none;
ignore client-updates;
log-facility local7;
default-lease-time 86400;
max-lease-time 604800;
option domain-name-servers 10.97.XXX.YY,10.97.XXX.YY;
# Subnets for internal hosts
subnet 10.0.0.128 netmask 255.255.255.128 {
# note that no range is given so dhcpd will not try to
# assign IP addresses
}
# Subnet for WLAN1
subnet 10.1.1.0 netmask 255.255.255.128 {
range 10.1.1.10 10.1.1.120;
option routers 10.1.1.1;
option subnet-mask 255.255.255.128;
}
#Subnet for WLAN2
subnet 10.2.2.0 netmask 255.255.255.0 {
range 10.2.2.10 10.2.2.250;
option routers 10.2.2.1;
option subnet-mask 255.255.255.0;
}
Zur Erklärung: Der DHCP Server steht mit seiner eigenen Adresse im Netz: 10.0.0.128 in einem Netz. In diesem Netz soll KEIN DHCP gemacht werden. Damit der Dienst läuft (sonst meckert er) muss man aber das Subnetz was auf dem Interface liegt anlegen. Wie kommentiert ist, halt ohne eine Range zu definieren.
Dann folgen zwei andere Netze die der DHCP-Server versorgt. Die Netze werden über Cisco Switche und die ip adress helper an den DHCP-Server weitergeleitet. In dem Fall sind das WLAN Netze die in einem VLAN laufen und in dem Vlan steht als ip helper eben der dhcp server drin.
Das ganze läuft über ein Interace. Die Option mit shared-network würde ich dafür nicht verwenden. Ich weiß gerade nicht mehr warum, aber das hat nicht funktioniert. Dafür gab es einen Grund. Müsste ich mal grübeln. Einfach die Subnetze so anlegen wie in meinem Beispiel.
Deine Config könnte dann so aussehen:
authoritative;
default-lease-time 86400;
max-lease-time 86400;
subnet 192.168.0.1 netmask 255.255.255.0 {
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name local
}
subnet 192.168.1.1 netmask 255.255.255.0 {
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option domain-name local
}
Dafür brauchst du aber auch in dem Netz 1.1 einen Router/DNS Server. Der eben das Netz verbindet und die Adressen Routet. Soll einfach nur der DHCP-Bereich vergrößert werden von 192.168.0.0 bis 192.168.1.1 machst du folgendes:
subnet 192.168.0.1 netmask 255.255.254.0 {
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name local
}
Denk aber daran auch deinen Router entsprechend auf das größere Netz zu konfigurieren.
Fertig Noch fragen? :D
zumal mir die routen vom Bird zur Firewall Static
Mmmhhh... nun kommen wieder andere Details ans Tageslicht Daraus schliessen wir mal das du dynamisch routest wenn du mit Bird die Router Implementation meinst, oder ?? Wenn ja welches Protokoll ?? Und wo hast du dann noch andere Router die mit der pfSense kommunizieren ?
Um mal beim normalen Routing zu bleiben.
Per se routet die pfSense ja zwischen allen diesen 4 IP Netzen. FW Regeln lassen wir jetzt mal außen vor !
Das macht die pfSense also ganz ohne.
Vermutlich vergibt die pfSense dann in den Segmenten 2 und 3 die IP Adressen per DHCP ? Ist dem so ?
Wenn ja dann wird sie ja an die Clients sich selbst als Gateway per DHCP propagieren.
Soweit so gut....
Knackpunkt ist dann das Segment 4. Hier schreibst du:
wurde in kleinere Netze aufgeteilt, z.b ein /30 als GW für die Firewall.
Wie ist das jetzt zu verstehen ??Die pfSense kann NICHT eine /24er Maske haben im Segment 4 wenn du dahinter /30er oder kleiner gesubnetete Netze betreibst. Damit hättest du einen Subnet Mask Mismatch im Netz der Fatal wäre und dir das Routing durcheinanderwürfelt.
Die zweite Frage ist in welchem Netzsegment dann der DHCP Server steht und vor allem für welche Netze er dann Adressen liefern soll ?
Generell macht man das dann ja mit der pfSense. Mit einem zentralen DHCP Server musst du auch ein UDP Forwarding einrichten (ip helper Adresse) ansonsten kannst du die UDP Broadcasts der DHCP Requests aus den gerouteten Client IP Segmenten ja niemals auf den zentralen DHCP Server forwarden.
Es klingt etwas wirr, da nicht vollkommen klar ist WIE die Netzstruktur und die dazu korrespondierende Adressierung bzw. das Routing aussieht.
Ein kleine Skizze wäre hier sehr hilfreich ?!
So wie oben kann die Konfig logischerweise niemals funktionieren. Bei einer Subnetz Definition wird sofern dort ein entsprechender Gateway Eintrag fehlt immer das der Globalen Konfig genommen mit dann fatalen Folgen.
Durch diesen Konfig Fehler bekommst du in deinem Subnetz .2.1 dann die .1.1 als Gateway für die Clients.
Das geht dann natürlich in die Hode, denn wie sollen die Clients im 2er Netz ein Gateway erreichen können was im 1er Netz liegt wenn sie selber gar kein Gateway haben ?
OK, der DHCP Server soll IP Adressen an Netze verteilen die hinter den beiden Core Routern liegen ??
Wenn ja musst du zwingend dort einen UDP Helper installieren (Forwarding Agent oder auch DHCP Relay).
Ansonsten können die Client DHCP UDP Broadcasts aus diesen Netzen ja niemals auf deinen DHCP Server geforwardet werden.
Siehe auch hier:
http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9
https://en.wikipedia.org/wiki/UDP_Helper_Address
Vlans und DHCP (IP-Helper?)
Wenn ja musst du zwingend dort einen UDP Helper installieren (Forwarding Agent oder auch DHCP Relay).
Ansonsten können die Client DHCP UDP Broadcasts aus diesen Netzen ja niemals auf deinen DHCP Server geforwardet werden.
Siehe auch hier:
http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9
https://en.wikipedia.org/wiki/UDP_Helper_Address
Vlans und DHCP (IP-Helper?)
Jetzt ist die Verwirrung komplett. Sorry verstehe im Monent nur Bahnhof...
Anders gefragt:
WO, in welchen Netzen sitzen denn die Clients die sich per DHCP von diesem Server IP Adressen holen ??
Wenn man das jetzt richtig versteht dann liegen diese Client Netze alle auf der pfSense Seite, richtig ?
Dann gilt aber wieder das gleiche... UDP Broadcasts und damit DHCP Broadcasts werden NICHT über Routergrenzen übertragen.
WIE kommen denn die DHCP Requests aus dem Subnetzen zum Server ??
Anders gefragt:
WO, in welchen Netzen sitzen denn die Clients die sich per DHCP von diesem Server IP Adressen holen ??
Wenn man das jetzt richtig versteht dann liegen diese Client Netze alle auf der pfSense Seite, richtig ?
Dann gilt aber wieder das gleiche... UDP Broadcasts und damit DHCP Broadcasts werden NICHT über Routergrenzen übertragen.
WIE kommen denn die DHCP Requests aus dem Subnetzen zum Server ??
Zitat von @janosch12:
UDP Broadcasts und damit DHCP Broadcasts werden NICHT über Routergrenzen übertragen.
Ah.... also müsste ich dem DHCP einfach mit einer weitere Netzwerkkarte bestücken, und dieser eine IP aus dem anderen Netz geben.
UDP Broadcasts und damit DHCP Broadcasts werden NICHT über Routergrenzen übertragen.
Ah.... also müsste ich dem DHCP einfach mit einer weitere Netzwerkkarte bestücken, und dieser eine IP aus dem anderen Netz geben.
Deswegen meine Frage zu Beginn auch: Ob alles über eine NIC laufen soll ... ne zweite wäre denke ich die einfachere Lösung.
WIE kommen denn die DHCP Requests aus dem Subnetzen zum Server ??>
Übern Switch.
Firewal -> Switch -> DHCP Server und Clients alle hinter dem Switch
also müsste ich dem DHCP einfach mit einer weitere Netzwerkkarte bestücken
Nein, natürlich nicht !Das wäre kompletter Blödsinn. Bei 10 Netzen müsstest du dann 10 Netzwerkkarten in den Server stecken. Wäre ja Unsinn...
Das Zauberwort heisst DHCP Relay oder UDP Helper !!
https://doc.pfsense.org/index.php/DHCP_Relay
Darauf wurdest du oben schon mehrfach hingewiesen, also bitte auch mal lesen !!!
http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9
https://en.wikipedia.org/wiki/UDP_Helper_Address
Vlans und DHCP (IP-Helper?)
Usw. usw.
Ich kenne die pfSense nicht, aber wie es scheint kann die eben DHCP Relay. Die erhält dann vom Client die DHCP Anfrage und leitet Sie zum DHCP Server weiter. Bei Cisco-Switchen/Routern bzw. in VLANs macht man es mit IP Helper Adressen. Ist nichts anderes.
Der Relay weiß ja in welchem Netz er sich befindet und tagt den DHCP Request mit eben jener Netzkennung und daher weiß der DHCP Server aus welchem Netz der Request kommt und sendet seinen IP-Vorschlag über diesen Relay an den Clienten.
Der Relay weiß ja in welchem Netz er sich befindet und tagt den DHCP Request mit eben jener Netzkennung und daher weiß der DHCP Server aus welchem Netz der Request kommt und sendet seinen IP-Vorschlag über diesen Relay an den Clienten.
Ich kenne die pfSense nicht
Zeit sie kennenzulernen:Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
und
https://www.amazon.de/Pfsense-Definitive-Christopher-M-Buechler/dp/09790 ...
Hardware zum Spielen:
https://www.amazon.de/VPN-Router-Netzwerksicherheit-Industrieller-Barebo ...
aber wie es scheint kann die eben DHCP Relay
Es "scheint" nicht nur so sie kann es wirklich.macht man es mit IP Helper Adressen. Ist nichts anderes.
Yepp, richtig, ist das gleiche Verfahren ! (Übrigens nicht nur bei Cisco, machen alle anderen Switch Hersteller auch so !)...und daher weiß der DHCP Server aus welchem Netz der Request kommt und sendet seinen IP-Vorschlag über diesen Relay an den Clienten.
Bingo !Du hast deine Hausaufgaben perfekt gemacht !!!
Zitat von @Yannosch:
Hi,
soll das über eine NIC laufen?
Falls ja, habe ich folgendes Beispiel gefunden:
Ein anschließender
sollte dann schicken.
Netzwerknamen & interfaces sind natürlich an deine Umgebung anzupassen.
Quelle meiner Informationen
Gruß Yannosch
Hi,
soll das über eine NIC laufen?
Falls ja, habe ich folgendes Beispiel gefunden:
shared-network my-net {
subnet 10.1.1.0 netmask 255.255.255.0 {
...
}
subnet 10.1.2.0 netmask 255.255.255.0 {
...
}
subnet 10.1.3.0 netmask 255.255.255.0 {
...
}
}
Ein anschließender
dhcpd -4 eth2
sollte dann schicken.
Netzwerknamen & interfaces sind natürlich an deine Umgebung anzupassen.
Quelle meiner Informationen
Gruß Yannosch
Moin Moin Yannosch,
vielen vielen Dank, du hast mir den Abend bzw. die Nacht gerettet!!!
Ich küsse deine Augen! Danke dir!!!!
Bei dem Problem hast du mir geholfen:
ISC DHCP Server fail bei zwei Subnetzen=756#comment-4339069165
Liebe Grüße