lefg 276 Geschrieben 10. Mai 2017 Melden Teilen Geschrieben 10. Mai 2017 @Magheinz Das NAT ist nicht die Idee von Kosta, das RZ hat es so eingerichtet, Kosta kann wohl nichts dagegen tun. Das "DHCProtokcol" wird wird nicht über das NAT umgesetzt, wird nicht geroutet, deshalb gibt es das Relaying. Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 10. Mai 2017 Autor Melden Teilen Geschrieben 10. Mai 2017 (bearbeitet) Genau so ist es, danke lefg - die NAT-Einrichtung und die jetzige Konfiguration haben 3 Kollegen gemacht - ein Kollege hier und zwei Kollegen aus dem Mutterkonzern (RZ). Ich war zu dem Zeitpunkt noch nicht mal angestellt. Grundsätzlich wie schon mehrmals geschrieben: die Netze sind unterschiedlich und die einzige Lösung ist zu NATen, da RZ vermutlich unser aktuelles lokales Netz nicht nutzen kann oder will. Verständlich, denn was passiert wenn ein anderer Kunde auch den selben lokalen Bereich hat (und der VPN-Endpunkt ja der selbe ist, wie ich bereits informiert wurde). RZ bestimmt in welches Netz wir wandeln müssen (oder wir stellen lokal auf dieses Netz um - was auch nicht möglich ist!!). DHCP am LANCOM, wie aktuell installiert, funktioniert. Jedoch weiß ich dass DHCP, wenn möglich, am DC installiert sein soll - so ist die offizielle Empfehlung (ob nur wegen Dynamischen Updates, oder sonst noch was?, weiß ich nicht... habe ich aber schon irgendwo gefragt). DHCP im RZ ist rein die Idee, um die Konfiguration schon einfach zu halten - wenn es funktioniert, ist ja nichts gediechselt und in DHCP klar dargestellt. Das ist einfach nur meine persönliche Meinung, da ich die DHCP Verwaltung im LANCOM ja kenne. bearbeitet 10. Mai 2017 von kosta88 Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 10. Mai 2017 Melden Teilen Geschrieben 10. Mai 2017 (bearbeitet) Jedoch weiß ich dass DHCP, wenn möglich, am DC installiert sein soll - Man macht es, so es eine normale Domäne. Das ist doch aber nicht zwingend. Falls Du willst und es dir möglich, es sinnvoll erscheint, kannst Du es mit dem Relaying ja testen. Andermfalls lass es so, wie es jetzt funktioniert, DHCP ist LANCOM oder das RZ. bearbeitet 10. Mai 2017 von lefg Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 29. Juni 2017 Autor Melden Teilen Geschrieben 29. Juni 2017 Mal wieder zurück zum Thema... Bin gerade dabei die Sache zu probieren, bin vorher nicht dazugekommen. Ich habe den Hot-Standby Failover zwischen lokalen Server (S02) und DC im Rechenzentrum (nennen wir im RZ-DC) konfiguriert. Failover scheint zu funktionieren, die Einträge werden repliziert. Auch die Hot-Standby Umschaltung funktioniert: funktioniert der S02, zeigt RZ-DC grünes Hackerl an, deaktiviere ich Netzwerk auf S02, schaltet nach ca. 1 Minute RZ-DC auf Failover um (orangenes Pfeil). Relaying ist konfiguriert und müsste funktionieren (weiß nicht wie ich das prüfen soll). Wie kann ich hier troubleshooten? Ich möchte grundsätzlich sehen wo die Pakete hängen bleiben... Ereignisanzeige zeigt hier nicht genug. Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 29. Juni 2017 Melden Teilen Geschrieben 29. Juni 2017 Ich vermute mal der Hot-Standby-Rechner hat eine andere IP-Adresse. Müsstest also im Relay den auch noch angeben. Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 29. Juni 2017 Autor Melden Teilen Geschrieben 29. Juni 2017 (bearbeitet) Klar, der Hot Standby DC ist der eine im RZ, und beide Server sind im Relay drin. Lokaler DC auf der 1. Stelle und RZ-DC auf der 2. Stelle. Man kann im Log des Routers auch sehen dass der Client die Anfrage tätigt und dass der Router an beide IP Adressen weiterleitet (steht im Log). Jedoch habe ich heute Nachmittag versucht die DHCP-Logs auszulesen, immer wieder zuerst brav die Anfragen gemacht, dann DHCP Dienst gestoppt und im Log nachgesehen ob was passiert ist. Und das seltsame war, dass die Anfragen vom Client drinnen nicht erscheinen - sollte aber so sein. Ich muss irgendwie verlässlich herausfinden können wo das Problem liegt. Ich hätte zuerst mal an Wireshark gedacht, nur kenne ich mich damit nicht wirklich aus. bearbeitet 29. Juni 2017 von kosta88 Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 29. Juni 2017 Melden Teilen Geschrieben 29. Juni 2017 Hmm, in dieser Konstellation wie sie bei dir ist hab ich noch nie ins Log geschaut. Stehen denn die Anfragen des Relay drin? Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 29. Juni 2017 Autor Melden Teilen Geschrieben 29. Juni 2017 Hat für mich nicht so ausgeschaut. Ich probier morgen nochmals und poste 1-2 Screenshots. Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 29. Juni 2017 Melden Teilen Geschrieben 29. Juni 2017 Es sind ja auch einige NAT dazwischen. Der Weg für den Relay zu den DHCP-Servern muß natürlich frei sein. Auf dem router brauchst da nix machen da der Relay ja von innen nach außen geht dabei genattet wird. Und die zurück kommenden Antworten sind ja in der Porttable des NAT hinterlegt und können also wieder rein. Aber die NAT beim Eingang RZ und den dortigen DHCP-Server z.B., da kommen ja die Relay-Pakete von außen auf den NAT. Da müsstest ein Loch aufmachen für auf der 67. Oder du machst vom Relay-Router einen Tunnel in das RZ und umgehst damit dieses NAT-Loch. Am Besten einen SSL-Tunnel um sich das eventuelle NAT-T zu sparen. Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 30. Juni 2017 Autor Melden Teilen Geschrieben 30. Juni 2017 (bearbeitet) Der Weg vom Relay (lokaler Router, gleiches Netz natürlich) zum DHCP (DC) im Rechnezentrum dürfte ja frei sein, da ich von meinem Rechner im lokalen Netz die IP des DHCP Servers anpingen kann, Daten übertragen usw. Für mich ist da kein NAT ersichtlich. Das N:N-NAT am LANCOM (lokaler Router) wird nur deswegen gemacht, damit die Antworten den Weg zurück finden. Lokale IPs sind aus dem RZ nicht direkt auffindbar, sondern nur mit der genateten IP. Ein IKEv2/IPSEC Site-2-Site Tunnel ist zwischen den Standorten eingerichtet. So nun, habe gerade getestet, offensichtlich kommt was an: 36,06/30/17,07:08:57,Das Paket wurde aufgrund eines abweichenden Client-ID-Hash oder aufgrund des Standbyservers verworfen.,10.146.32.0,,00155D209009,,0,6,,,,,,,,,036,06/30/17,07:09:00,Das Paket wurde aufgrund eines abweichenden Client-ID-Hash oder aufgrund des Standbyservers verworfen.,10.146.32.0,,00155D209009,,0,6,,,,,,,,,036,06/30/17,07:09:05,Das Paket wurde aufgrund eines abweichenden Client-ID-Hash oder aufgrund des Standbyservers verworfen.,10.146.32.0,,00155D209009,,0,6,,,,,,,,,036,06/30/17,07:09:14,Das Paket wurde aufgrund eines abweichenden Client-ID-Hash oder aufgrund des Standbyservers verworfen.,10.146.32.0,,00155D209009,,0,6,,,,,,,,,001,06/30/17,07:10:07,Angehalten,,,,,0,6,,,,,,,,,0 Die MAC entspricht dem Rechner. Möglicherweise liegt das Problem daran, dass gleichzeitig Relay und N:N-NAT gemacht wird. Ich weiß nämlich nicht, auf welche IP die Pakete retour gehen... das wäre wichtig rauszufinden, glaube ich. bearbeitet 30. Juni 2017 von kosta88 Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 30. Juni 2017 Melden Teilen Geschrieben 30. Juni 2017 https://technet.microsoft.com/en-us/library/dn338988(v=ws.11).aspx Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 30. Juni 2017 Autor Melden Teilen Geschrieben 30. Juni 2017 (bearbeitet) Hatte ich schon gelesen. Jedoch verstehe ich es sicher falsch. In hot standby mode, only the active server responds. Also DHCP im RZ (Hot Standby). In both cases, the DHCP server which does not respond to the client logs this message in the audit log. Also theoretisch S02, aber wie soll S02 Logs auf RZ-DC erstellen, wenn S02 offline ist?? bearbeitet 30. Juni 2017 von kosta88 Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 30. Juni 2017 Melden Teilen Geschrieben 30. Juni 2017 Ist ja vom Standbyserver ins log eingetragen. War also zu einem Zeitpunkt als beide Server up waren und der SO2 war DHCP-Server. Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 30. Juni 2017 Autor Melden Teilen Geschrieben 30. Juni 2017 Ist ja vom Standbyserver ins log eingetragen. Das ist logisch, S02 war nicht online! Standby ist ja der DHCP im RZ. War also zu einem Zeitpunkt als beide Server up waren und der SO2 war DHCP-Server. Ich werde es nochmals probieren, aber S02 war definitiv nicht online (Netzwerkkarte in der Konsole wurde deaktiviert). Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 30. Juni 2017 Melden Teilen Geschrieben 30. Juni 2017 Hmm, 10.146.32.0 ist wo? Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.