DNS bzw Netzwerkproblem
Guten Morgen.
Folgender Aufbau: Fritzbox - Server 2012 R2 - Switch - mehrere Clients
Der Server hat Internetzugriff, die Clients komischerweise nur über WLAN, aber nicht über LAN (nur über IPv6 und auch nur https).
Was hab ich bereits gemacht:
DNS-Serverrolle neu installiert und konfiguriert.
DHCP-Serverrolle neu installiert und konfiguriert.
Hat beides nix gebracht.
nslookup funktioniert, ping nicht (auch bei deaktivierter Windows Firewall).
Edit: tracert meldet Zeitüberschreitung
An den Clients Netzwerk zurückgesetzt, DNS geflusht, bringt auch nix.
Hat jemand einen Denkanstoß, wo ich noch ansetzen könnte?
Danke
Folgender Aufbau: Fritzbox - Server 2012 R2 - Switch - mehrere Clients
Der Server hat Internetzugriff, die Clients komischerweise nur über WLAN, aber nicht über LAN (nur über IPv6 und auch nur https).
Was hab ich bereits gemacht:
DNS-Serverrolle neu installiert und konfiguriert.
DHCP-Serverrolle neu installiert und konfiguriert.
Hat beides nix gebracht.
nslookup funktioniert, ping nicht (auch bei deaktivierter Windows Firewall).
Edit: tracert meldet Zeitüberschreitung
An den Clients Netzwerk zurückgesetzt, DNS geflusht, bringt auch nix.
Hat jemand einen Denkanstoß, wo ich noch ansetzen könnte?
Danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 588194
Url: https://administrator.de/contentid/588194
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
68 Kommentare
Neuester Kommentar
Zitat von @aqui:
- DHCP Server in der FritzBox deaktiviert ?
- DNS Server Weiterleitung korrekt auf den Provider DNS oder einen Datenschutz freundliche Alternative wie Quad 9 konfiguriert ?
- was sagt ein ipconfig -all (Winblows) zur DNS IP im Client ?
Und DHCP Server in Windows authorisiert?
Wie viele Netzwerkkarten hat der Server? Vielleicht falsche Netzwerkkarte gesteckt bzw. DHCP Server an falsche Netzwerkarte gebunden?
Server wird getestet: Default-First-Site-Name\FRANKBT-SRV
Starting test: DNS
DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige
Minuten...
......................... Der Test DNS für FRANKBT-SRV ist
fehlgeschlagen.
Starting test: DNS
DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige
Minuten...
......................... Der Test DNS für FRANKBT-SRV ist
fehlgeschlagen.
Irgendiwe wird Dein DNS wohl nicht erreicht. Die Zonen korrekt eingerichtet?
🖖
Zitat von @FFSephiroth:
@Dr.Bit: Ich hab die DNS Rolle auch schon mal deinstalliert und neu installiert...gleiches Problem.
@Dr.Bit: Ich hab die DNS Rolle auch schon mal deinstalliert und neu installiert...gleiches Problem.
Ja, aber hast Du auch die Zonen korrekt eingerichtet? Kommt das dcdiag vom Server? Dann findet er sich ja nicht einmal selbst.
🖖
Also, was mir schon einmal aufgefallen ist, ist daß der Server wieder die 127.0.0.1 als Primary DNS eingetragen hat. Das kann funktionieren, nach meiner Erfahrung kann es aber auch schief gehen. Die lokale IP des DNS Servers eintragen funktioniert aber immer. Sprich, in Deinem Fall 192.168.200.250.
Neues Phänomen: Hab jetz meinen Laptop einfach mal an den Switch gesteckt und da geht Internet über LAN. Nur an den Bestandsgeräten nicht.
Hast Du denn das WLAN vom Laptop abgeschaltet? Nicht nur trennen, sondern die Karte abschalten.
🖖
Also, mal zusammenfassen:
1. Bis auf das Laptop kommt kein Rechner ins Internet über LAN.
2. Über WLAN kommen alle ins Internet und die WLAN Clients bekommen ihre Netzwerkeinstellungen vom Server und nicht von der Fritzbox.
3. Der Server hat als DNS seine eigen IP eingetragen und auf dem DNS Server ist die Konfiguration richtig und als Forwarder ist ein DNS im Internet und nicht die Fritzbox eingetragen.
4. Der Server selber kommt ins Internet, obwohl er die gleichen Netzwerkeinstellungen hat wie die Clients.
5. Alle Clients (auch die Laptops) sind in der gleichen Domäne und bekommen über die GPO die gleichen Vorgaben.
6. Der DHCP Server funktioniert und verteilt die IP´s korrekt mit den gewünschten Einstellungen für DNS und Gateway.
7. Keine Firewall funkt irgendwo dazwischen
Hab ich was vergessen?
🖖
1. Bis auf das Laptop kommt kein Rechner ins Internet über LAN.
2. Über WLAN kommen alle ins Internet und die WLAN Clients bekommen ihre Netzwerkeinstellungen vom Server und nicht von der Fritzbox.
3. Der Server hat als DNS seine eigen IP eingetragen und auf dem DNS Server ist die Konfiguration richtig und als Forwarder ist ein DNS im Internet und nicht die Fritzbox eingetragen.
4. Der Server selber kommt ins Internet, obwohl er die gleichen Netzwerkeinstellungen hat wie die Clients.
5. Alle Clients (auch die Laptops) sind in der gleichen Domäne und bekommen über die GPO die gleichen Vorgaben.
6. Der DHCP Server funktioniert und verteilt die IP´s korrekt mit den gewünschten Einstellungen für DNS und Gateway.
7. Keine Firewall funkt irgendwo dazwischen
Hab ich was vergessen?
🖖
Was soll das heißen? Welcher DNS und wo trägst Du den ein?
🖖
Mit "Weiterleitung" meinst Du den Forwarder im DNS Server? Dann geht es doch. So soll es dann ja auch sein. Und die Lpatops müßten dann über WLAN auch wieder reinkommen.
🖖
🖖
Die Rechner neu starten und 15 min warten, bis die sich berappelt haben. Sind schon einmal 4 mehr als vorher. Trotzdem hast Du nicht auf mine Frage geantwortet. Was soll Weiterleitung bedeuten und wo hast Du die eingetragen?
Du bist ja nun nicht erst seit gestern hier und solltest wissen, wie es läuft.
🖖
Du bist ja nun nicht erst seit gestern hier und solltest wissen, wie es läuft.
🖖
Trag doch da bitte die Adresse des DNS-Servers deines Providers ein.
@aqui hat es ja oben auch schon beschrieben.
So langsam wird das eine Meisterprüfung! ist der DHCP auf der Fritte auch wirklich deaktiviert? Wenn Du ein ipconfig auf allen Clients machst, müßte, bis auf die IP, bei allen das Gleiche stehen. Auf allen Clients ist die Firewall deaktiviert? Also nur die Firewall deaktivieren, NICHT den Dienst deaktivieren.
So langsam gehen mir die Ideen aus.
🖖
So langsam gehen mir die Ideen aus.
🖖
Moin,
OK, auf dem Server geht alles richtig.
Im WLAN geht's auch richtig. Das WLAN ist im selben IP Netz wie das LAN. Die Einstellungen (DNS, Router etc.) sind die gleichen wie beim LAN.
Damit scheiden DNS-Probleme imho aus. Wenn Server und WLAN-Clients funktionieren und den gleichen DNS wie die LAN-Clients benutzen, dann kann es nicht das DNS sein. Dann würde es beim Server und im WLAN auch nicht gehen. Außerdem meine ich, Du hast irgendwo oben geschrieben, dass nslookup auch auf den nicht funktionierenden Clients funktioniert, also die richtigen Ergebnisse liefert.
Diese Aussage ist widersprüchlich. Geht es nicht? Oder geht nur IPv6 mit https? Denn wenn es mit IPv6 und https funktioniert, dann heißt das, dass die Verbindung prinzipiell funktioniert, aber die anderen Protokolle warum auch immer blockiert werden. Damit scheiden imho alle Hardwareprobleme aus, denn Hardware unterscheidet nicht zwischen IPv6 und IPv4. Außerdem habe ich das so verstanden, dass die interne Kommunikation ja reibungslos klappt. Nur der Internetzugriff nicht. Damit können die internen Hardwarekomponenten (NICs, Switches, Kabel usw.) als funktionsfähig angenommen werden.
Also musst Du nach dem Grund suchen, warum Pakete nicht ins Internet gelangen oder die Antworten nicht richtig zurück kommen. Da hilft nur Wireshark. Lass den mal mitlaufen, wenn es nicht geht, wenn es mit IPv6 und https geht und wenn es geht. Das wird allerding eine Menge werden, die man dann da auswerten muss. Ich fürchte fast, dass wir da nicht drum herum kommen, dass Du das in irgend einer Cloud als Dateien zur Verfügung stellst. Die Ergebnisse hier einzustellen, macht wenig Sinn. Oder kannst Du das selbst auswerten?
Liebe Grüße
Erik
OK, auf dem Server geht alles richtig.
die Clients komischerweise nur über WLAN,
Im WLAN geht's auch richtig. Das WLAN ist im selben IP Netz wie das LAN. Die Einstellungen (DNS, Router etc.) sind die gleichen wie beim LAN.
Damit scheiden DNS-Probleme imho aus. Wenn Server und WLAN-Clients funktionieren und den gleichen DNS wie die LAN-Clients benutzen, dann kann es nicht das DNS sein. Dann würde es beim Server und im WLAN auch nicht gehen. Außerdem meine ich, Du hast irgendwo oben geschrieben, dass nslookup auch auf den nicht funktionierenden Clients funktioniert, also die richtigen Ergebnisse liefert.
aber nicht über LAN (nur über IPv6 und auch nur https).
Diese Aussage ist widersprüchlich. Geht es nicht? Oder geht nur IPv6 mit https? Denn wenn es mit IPv6 und https funktioniert, dann heißt das, dass die Verbindung prinzipiell funktioniert, aber die anderen Protokolle warum auch immer blockiert werden. Damit scheiden imho alle Hardwareprobleme aus, denn Hardware unterscheidet nicht zwischen IPv6 und IPv4. Außerdem habe ich das so verstanden, dass die interne Kommunikation ja reibungslos klappt. Nur der Internetzugriff nicht. Damit können die internen Hardwarekomponenten (NICs, Switches, Kabel usw.) als funktionsfähig angenommen werden.
Also musst Du nach dem Grund suchen, warum Pakete nicht ins Internet gelangen oder die Antworten nicht richtig zurück kommen. Da hilft nur Wireshark. Lass den mal mitlaufen, wenn es nicht geht, wenn es mit IPv6 und https geht und wenn es geht. Das wird allerding eine Menge werden, die man dann da auswerten muss. Ich fürchte fast, dass wir da nicht drum herum kommen, dass Du das in irgend einer Cloud als Dateien zur Verfügung stellst. Die Ergebnisse hier einzustellen, macht wenig Sinn. Oder kannst Du das selbst auswerten?
Liebe Grüße
Erik
Zitat von @erikro:
Damit scheiden DNS-Probleme imho aus. Wenn Server und WLAN-Clients funktionieren und den gleichen DNS wie die LAN-Clients benutzen, dann kann es nicht das DNS sein. Dann würde es beim Server und im WLAN auch nicht gehen. Außerdem meine ich, Du hast irgendwo oben geschrieben, dass nslookup auch auf den nicht funktionierenden Clients funktioniert, also die richtigen Ergebnisse liefert.
Da , nach der Neukonfiguration des DNS Servers, die meisten Clients ins Internet kamen und die Wlan Clients nicht mehr, kann es nur am DNS gelegen haben. Ich vermute, das auf den Clients und WLAN Clients noch irgendetwas krum ist. Vielleicht irgendwelche Einträge in der hosts oder sonstwo, man kann ja leider nicht über die Schulter gucken.Damit scheiden DNS-Probleme imho aus. Wenn Server und WLAN-Clients funktionieren und den gleichen DNS wie die LAN-Clients benutzen, dann kann es nicht das DNS sein. Dann würde es beim Server und im WLAN auch nicht gehen. Außerdem meine ich, Du hast irgendwo oben geschrieben, dass nslookup auch auf den nicht funktionierenden Clients funktioniert, also die richtigen Ergebnisse liefert.
aber nicht über LAN (nur über IPv6 und auch nur https).
Diese Aussage ist widersprüchlich. Geht es nicht? Oder geht nur IPv6 mit https? Denn wenn es mit IPv6 und https funktioniert, dann heißt das, dass die Verbindung prinzipiell funktioniert, aber die anderen Protokolle warum auch immer blockiert werden. Damit scheiden imho alle Hardwareprobleme aus, denn Hardware unterscheidet nicht zwischen IPv6 und IPv4.
Daher meine Frage nach einer Firewall, die irgendwo im Netzwerk hängt oder auf den Clients noch läuft.
Außerdem habe ich das so verstanden, dass die interne Kommunikation ja reibungslos klappt. Nur der Internetzugriff nicht. Damit können die internen Hardwarekomponenten (NICs, Switches, Kabel usw.) als funktionsfähig angenommen werden.
Dem ist ja nicht so. Er kann von zwei Clients aus nur den Server anpingen und nicht die Fritte, was ja eigentlich gar nicht sein kann und kommt demetsprechend mit den Beiden auch nicht ins i-net. Daher lohnt es sich auf jeden Fall die Hardware / Verkabelung mal durchzuprüfen. Man kann gar nicht so dumm denken wie es kommt.
Also musst Du nach dem Grund suchen, warum Pakete nicht ins Internet gelangen oder die Antworten nicht richtig zurück kommen.
Da hilft nur Wireshark. Lass den mal mitlaufen, wenn es nicht geht, wenn es mit IPv6 und https geht und wenn es geht. Das wird allerding eine Menge werden, die man dann da auswerten muss. Ich fürchte fast, dass wir da nicht drum herum kommen, dass Du das in irgend einer Cloud als Dateien zur Verfügung stellst. Die Ergebnisse hier einzustellen, macht wenig Sinn.
Das sehe ich auch so.
Man gut, in 5 St.d is Urlaub.
🖖
Nich Dein Ernst, wir haben doch nun wirklich oft genug gefragt, ob der DNS richtig konfiguriert ist. Dann korrigier das mal schnell, dann sollte es auch funktionieren.
Vielleicht solltest Du dir das hier nochmal zu Gemüte führen: http://openbook.rheinwerk-verlag.de/windows_server_2012r2/09_001.html#d ...
🖖
Vielleicht solltest Du dir das hier nochmal zu Gemüte führen: http://openbook.rheinwerk-verlag.de/windows_server_2012r2/09_001.html#d ...
🖖
Moin
wenn die Rechner die Fritzbox nicht anpingen können, können wir eventuelle DNS-Themen wohl hinten anstellen.
Bitte mal von einem Rechner, der die Fritzbox NICHT anpingen kann
a) ein ipconfig /all
b) ein arp -a
c) nslookup auf irgendwas z.B. www.administrator.de
Und von der Fritzbox die IP-Konfiguration (theoretisch könnte eine falsche Subnet-Mask an der Fritzbox für derart lustige Probleme sorgen)
Gruß
Bernhard
wenn die Rechner die Fritzbox nicht anpingen können, können wir eventuelle DNS-Themen wohl hinten anstellen.
Bitte mal von einem Rechner, der die Fritzbox NICHT anpingen kann
a) ein ipconfig /all
b) ein arp -a
c) nslookup auf irgendwas z.B. www.administrator.de
Und von der Fritzbox die IP-Konfiguration (theoretisch könnte eine falsche Subnet-Mask an der Fritzbox für derart lustige Probleme sorgen)
Gruß
Bernhard
Moin,
Mein reden. Das Ganze klingt so gar nicht nach DNS.
Die Idee ist gut. Das könnte auch erklären, warum es mit IPv6 geht.
Liebe Grüße
Erik
Zitat von @BernhardMeierrose:
wenn die Rechner die Fritzbox nicht anpingen können, können wir eventuelle DNS-Themen wohl hinten anstellen.
wenn die Rechner die Fritzbox nicht anpingen können, können wir eventuelle DNS-Themen wohl hinten anstellen.
Mein reden. Das Ganze klingt so gar nicht nach DNS.
Und von der Fritzbox die IP-Konfiguration (theoretisch könnte eine falsche Subnet-Mask an der Fritzbox für derart lustige Probleme sorgen)
Die Idee ist gut. Das könnte auch erklären, warum es mit IPv6 geht.
Liebe Grüße
Erik
Moin,
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Ist das Problem eingentlich gelöst? Was war denn die Lösung? Ich war im Urlaub.
Liebe Grüße
Erik
Zitat von @Ex0r2k16:
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Ist das Problem eingentlich gelöst? Was war denn die Lösung? Ich war im Urlaub.
Liebe Grüße
Erik
Zitat von @FFSephiroth:
Update:
Wenn ich den LAN CLients eine feste IP außerhalb des DHCP-Bereichs gebe, klappt alles. Ping, tracert, web...alles.
Also muss es am DHCP liegen.
Moinsens,Update:
Wenn ich den LAN CLients eine feste IP außerhalb des DHCP-Bereichs gebe, klappt alles. Ping, tracert, web...alles.
Also muss es am DHCP liegen.
bin nun auch aus dem Urlaub zurück.
Da hast Du doch den Fehler. Irgendetwas an Deinem DHCP ist/war ja wohl nicht korrekt eingestellt.
Wie erikro schon fragte, ist es denn inzwischen erledigt? Wenn ja, was war denn tatsächlich das Problem?
🖖
Zitat von @erikro:
Moin,
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Moin,
Zitat von @Ex0r2k16:
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Nö stimmt so nicht. Best Practise ist die IP ausserhalb der Range zu reservieren:
Siehe hier: https://community.sophos.com/products/xg-firewall/f/network-and-routing/ ...
Und ich glaube Sophos verwendet da auch nur irgend nen Standard Linux DHCP Server. Reserviert man in der Range, kommt es zu doppelten IPs. Zumindest bei ner älteren UTM Version ging das noch. Vielleicht ham sies aber langsam mal gepatched.
Watt? Wenn ich in der Range reserviere, dann in der Regel um bestimmten MAC Adressen eine bestimmte IP zuzuordnen, ohne diese direkt am Gerät einstellen zu müssen. Oder um bestimmte IP Adressen (z.B. für Server und Drucker usw.) von der Verteilung auszuschließen (is dämlich, kann man aber so machen). Wenn ich diese Range von der Verteilung ausschließe, kann ich gar keine doppelten IP´s vergeben, wenn ich das ordentlich dokumentiert habe.
Grundsätzlich, bei einem Windows DHCP, bestimme ich die Range die ich haben will und schließe dann IP´s von der Verteilung für eine betimmte Range von IP Adressen aus, die für feste IP´s oder über MAC Adressen zuteilbare vorgesehen sind.
Ich lege immer von 1 bis 254 fest und schließe dann aus. Ist am einfachsten und ich bin flexibel.
🖖
Moin,
Nur weil das Sophos so macht, ist das noch lange nicht Best Practice. Wir sprechen hier über einen Windows-DHCP-Server. Bei dem geht das nicht anders. Du musst die Reservierungen aus der Range nehmen. Sonst gibt es eine Fehlermeldung.
Liebe Grüße
Erik
Zitat von @Ex0r2k16:
Nö stimmt so nicht. Best Practise ist die IP ausserhalb der Range zu reservieren:
Zitat von @erikro:
Moin,
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Moin,
Zitat von @Ex0r2k16:
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Nö stimmt so nicht. Best Practise ist die IP ausserhalb der Range zu reservieren:
Nur weil das Sophos so macht, ist das noch lange nicht Best Practice. Wir sprechen hier über einen Windows-DHCP-Server. Bei dem geht das nicht anders. Du musst die Reservierungen aus der Range nehmen. Sonst gibt es eine Fehlermeldung.
Liebe Grüße
Erik
Zitat von @FFSephiroth:
was ich bis jetzt rausfinden konnte ist, dass der DHCP anscheinend keine IPs mehr vergibt. Er verhält sich so, als ob alle IPs vergeben wären.
Falls Du es noch nicht wußtest: ein Windows DHCP Server schaltet sich automatisch ab, oder besser gesagt verteilt keine IP´s mehr, wenn er einen anderen DHCP Server im Netzwerk findet. Sicher, daß der Windows Server der Einzige im LAN ist?was ich bis jetzt rausfinden konnte ist, dass der DHCP anscheinend keine IPs mehr vergibt. Er verhält sich so, als ob alle IPs vergeben wären.
🖖
Zitat von @erikro:
Moin,
Nur weil das Sophos so macht, ist das noch lange nicht Best Practice. Wir sprechen hier über einen Windows-DHCP-Server. Bei dem geht das nicht anders. Du musst die Reservierungen aus der Range nehmen. Sonst gibt es eine Fehlermeldung.
Liebe Grüße
Erik
Moin,
Zitat von @Ex0r2k16:
Nö stimmt so nicht. Best Practise ist die IP ausserhalb der Range zu reservieren:
Zitat von @erikro:
Moin,
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Moin,
Zitat von @Ex0r2k16:
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern. Dort dürfen reservierte IPs nie in der DHCP Range liegen, da sonst die Möglichkeit besteht, dass diese doppelt vergeben werden. Vielleicht hilft das?
Andersherum wird ein Schuh daraus. Wenn die Adresse außerhalb des DHCP-Bereichs liegt, dann besteht bei vergessener Dokumentation, dass die Adresse vergeben ist, die Gefahr, dass ein anderer Admin die Adresse noch einmal händisch vergibt. Liegt die Adresse aber innerhalb dieses Bereichs, dann besteht die Gefahr nicht. Ein Admin, der händisch Adressen vergeben darf, sollte wissen, dass die innerhalb des DHCP-Bereichs tabu sind. Deshalb ist das bei Windows-DHCP auch so.
Nö stimmt so nicht. Best Practise ist die IP ausserhalb der Range zu reservieren:
Nur weil das Sophos so macht, ist das noch lange nicht Best Practice. Wir sprechen hier über einen Windows-DHCP-Server. Bei dem geht das nicht anders. Du musst die Reservierungen aus der Range nehmen. Sonst gibt es eine Fehlermeldung.
Liebe Grüße
Erik
deswegen schrieb ich doch auch:
Ich kenn ein solches Verhalten nur von linux basierten DHCP Servern
:D