Aussage "Router macht DHCP ins Netz" - was soll das bedeuten?
Hallo,
ein Mitarbeiter unseres Providers war soeben bei uns im Büro und hat geschimpft, dass von uns aus "DHCP ins Netz" gespeist wird und dadurch andere Kunden verwirrt sind. Er meinte, dass er Port 67 nun am DSLAM gesperrt habe.
Als Router ist bei uns ein Cisco 1921 ISR im Einsatz. DHCP ist aktiviert um Gastgeräte mit Adressen zu versorgen. Aber dass die DHCP-Adressen auch in das WAN gehen Wir haben hier nie etwas bemerkt und auch keine Probleme nach der Sperrung des Ports.
Kann mir vielleicht jemand sagen, was der Mitarbeiter gemeint hat?
ein Mitarbeiter unseres Providers war soeben bei uns im Büro und hat geschimpft, dass von uns aus "DHCP ins Netz" gespeist wird und dadurch andere Kunden verwirrt sind. Er meinte, dass er Port 67 nun am DSLAM gesperrt habe.
Als Router ist bei uns ein Cisco 1921 ISR im Einsatz. DHCP ist aktiviert um Gastgeräte mit Adressen zu versorgen. Aber dass die DHCP-Adressen auch in das WAN gehen Wir haben hier nie etwas bemerkt und auch keine Probleme nach der Sperrung des Ports.
Kann mir vielleicht jemand sagen, was der Mitarbeiter gemeint hat?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 253674
Url: https://administrator.de/forum/aussage-router-macht-dhcp-ins-netz-was-soll-das-bedeuten-253674.html
Ausgedruckt am: 23.12.2024 um 14:12 Uhr
4 Kommentare
Neuester Kommentar
Hi,
ggf ist das DHCP Binding auf ein Interface nicht erfolgt...
Edit: Hier ist ein Link zur DHCP-Configuration: http://www.cisco.com/c/en/us/td/docs/routers/access/1800/1801/software/ ...
Gruß
ggf ist das DHCP Binding auf ein Interface nicht erfolgt...
Edit: Hier ist ein Link zur DHCP-Configuration: http://www.cisco.com/c/en/us/td/docs/routers/access/1800/1801/software/ ...
Gruß
Das bedeutet das der Cisco Router einen DHCP Server in Richtung Providerport konfiguriert hat. Klar das der Kollege dann etwas ungehalten ist, denn das ist natürlich falsch konfiguriert von deiner Seite, klar ! Es zeigt aber auch die fehlerhafte Konfig des Providers, denn der blockt generell solche ungewollten Protokolle wie DHCP, Spanning-Tree, CDP, LLDP usw. usw. in seinen Netze.
Leider hast du hier ja nicht die Konfig des Routers mal gepostet was hilfreich wäre um dir zu helfen. So zwingst du uns zum wilden Raten im freien Fall
Im folgenden Tutorial kannst du eine saubere Cisco Standard Konfig für sowas sehen und wie man das für den Provider wasserdicht und ohne DHCP auf seinem Port umsetzt:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Leider hast du hier ja nicht die Konfig des Routers mal gepostet was hilfreich wäre um dir zu helfen. So zwingst du uns zum wilden Raten im freien Fall
Im folgenden Tutorial kannst du eine saubere Cisco Standard Konfig für sowas sehen und wie man das für den Provider wasserdicht und ohne DHCP auf seinem Port umsetzt:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Nach deiner Konfiguration (und wenn diese authentisch ist) bist du ganz sicher NICHT der Verursacher der DHCP Pakete !
Es sei denn du bekommst am Interface GigabitEthernet0/1 was ja dein Provider Interface ist auch einen 10.88er IP was vermutlich aber nicht der Fall ist.
Zudem würde der Cisco dann über "duplicate IPs" meckern !
5 Tips zu deiner Konfig:
1.) Auf dem Provider Interface solltest du zwingend auch CDP deaktivieren, da sonst jeder in der Welt weiss wessen Router mit allen Daten an dem Port hängt !
2.) Deine ip nat inside source list Definition ist mit Verlaub gesagt etwas unsinnig.
Sinnvollerweise zieht man das in ein gemeinsames ACL Statement zusammen so das es nachher so aussieht:
access-list 101 permit ip 10.80.1.0 0.0.0.255 any
access-list 101 permit ip 10.80.10.0 0.0.0.255 any
access-list 101 permit ip 10.80.20.0 0.0.0.255 any
access-list 101 permit ip 10.80.30.0 0.0.0.255 any
access-list 101 permit ip 10.80.50.0 0.0.0.255 any
access-list 101 permit ip 10.80.90.0 0.0.0.255 any
access-list 101 permit ip 10.80.99.0 0.0.0.255 any
!
ip nat inside source list 101 interface GigabitEthernet0/1 overload
Es reicht dann ein einziges NAT Statement um das gleiche zu bewirken !
Das access-list 101 permit ip ip 10.80.10.0 0.0.0.255 10.80.100.0 0.0.0.255 ist dabei auch völlig überflüssig, denn es wird logischerweise schon mit dem Statement access-list 101 permit ip 10.80.10.0 0.0.0.255 any mit erschlagen !
Willst du es noch einfacher haben geht es auch noch weit übersichtlicher mit nur 2 simplen Konfig Zeilen:
access-list 101 permit ip 10.80.0.0 0.0.127.255 any
!
ip nat inside source list 101 interface GigabitEthernet0/1 overload
Das erreicht dann das gleiche und NATet alle internen IP Netze von 10.80.0.0 bis 10.80.127.254 !
Also warum umständlich machen wenns einfacher auch geht
3.) Ein HTTP Server auf einem Internet Router ist eigentlich ein NoGo ! Wenn überhaupt dann nur HTTPS !
4.) Besser und sicherer wäre es noch wenn du ein Firewall Image hast die SPI Firewall zu aktivieren (ip inspect xyz) und mit CBAC am WAN/Provider Port zu arbeiten. Beispiel zeigt das o.a. Tutorial.
5.) Die Sommerzeit Umschaltung ist falsch ! Richtig ist:
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
Ist aber nur kosmetisch... Wenn du die genaue Zeit haben willst fürs Router log solltest du mit ntp server 130.149.17.8 source GigabitEthernet 0/1 immer einen Zeitserver konfigurieren.
Ggf. auf eine interne IP ändern solltest du einen eigenen Zeitserver (z.B. Winblows Server) im Netz betreiben !
Es sei denn du bekommst am Interface GigabitEthernet0/1 was ja dein Provider Interface ist auch einen 10.88er IP was vermutlich aber nicht der Fall ist.
Zudem würde der Cisco dann über "duplicate IPs" meckern !
5 Tips zu deiner Konfig:
1.) Auf dem Provider Interface solltest du zwingend auch CDP deaktivieren, da sonst jeder in der Welt weiss wessen Router mit allen Daten an dem Port hängt !
2.) Deine ip nat inside source list Definition ist mit Verlaub gesagt etwas unsinnig.
Sinnvollerweise zieht man das in ein gemeinsames ACL Statement zusammen so das es nachher so aussieht:
access-list 101 permit ip 10.80.1.0 0.0.0.255 any
access-list 101 permit ip 10.80.10.0 0.0.0.255 any
access-list 101 permit ip 10.80.20.0 0.0.0.255 any
access-list 101 permit ip 10.80.30.0 0.0.0.255 any
access-list 101 permit ip 10.80.50.0 0.0.0.255 any
access-list 101 permit ip 10.80.90.0 0.0.0.255 any
access-list 101 permit ip 10.80.99.0 0.0.0.255 any
!
ip nat inside source list 101 interface GigabitEthernet0/1 overload
Es reicht dann ein einziges NAT Statement um das gleiche zu bewirken !
Das access-list 101 permit ip ip 10.80.10.0 0.0.0.255 10.80.100.0 0.0.0.255 ist dabei auch völlig überflüssig, denn es wird logischerweise schon mit dem Statement access-list 101 permit ip 10.80.10.0 0.0.0.255 any mit erschlagen !
Willst du es noch einfacher haben geht es auch noch weit übersichtlicher mit nur 2 simplen Konfig Zeilen:
access-list 101 permit ip 10.80.0.0 0.0.127.255 any
!
ip nat inside source list 101 interface GigabitEthernet0/1 overload
Das erreicht dann das gleiche und NATet alle internen IP Netze von 10.80.0.0 bis 10.80.127.254 !
Also warum umständlich machen wenns einfacher auch geht
3.) Ein HTTP Server auf einem Internet Router ist eigentlich ein NoGo ! Wenn überhaupt dann nur HTTPS !
4.) Besser und sicherer wäre es noch wenn du ein Firewall Image hast die SPI Firewall zu aktivieren (ip inspect xyz) und mit CBAC am WAN/Provider Port zu arbeiten. Beispiel zeigt das o.a. Tutorial.
5.) Die Sommerzeit Umschaltung ist falsch ! Richtig ist:
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
Ist aber nur kosmetisch... Wenn du die genaue Zeit haben willst fürs Router log solltest du mit ntp server 130.149.17.8 source GigabitEthernet 0/1 immer einen Zeitserver konfigurieren.
Ggf. auf eine interne IP ändern solltest du einen eigenen Zeitserver (z.B. Winblows Server) im Netz betreiben !