6
2 Netzwerkkarten - Anfragen werden über falsche Karte gesendet
Wir verzeichnen auf unserer Firewall Zugriffe der Domainencontroller auf IP-Adressen, die eigentlich über eine 2.Netzwerkkarte sofort erreicht werden könnten.
Hallo zusammen,
Wir haben folgende Netzwerk-Konstellation:
Es gibt also 2 Netze (10er und 192er abgekürzt). Im 10er Netz hängt der Router, der ebenfalls Firewall spielt,
sowie alle Arbeitsstation, Drucker und Server. Alle Server haben noch eine 2.Netzwerkkarte, über die diese
nochmal in einem schnelleren Backbone untereinander verbunden sind. Wir nutzen z.B. viele Terminalserver
und Datenbankserver. So können die Anwendungen auf den TSen schneller auf die Datenbanken üder das
Backbone zugreifen. Alle Server routen nicht, d.h. man kommt nicht von einem Netz in das andere.
Nur die Server können sich gegenseitig untereinander über beide Wege erreichen.
Der DNS-Server läuft auf unseren beiden DCs, dort gibt es zwei forward-Zonen (firma.de und backbone), in denen
jeweils die Server mit den jeweiligen IPs eingetragen sind.
Nun haben wir in dem Protokoll auf der Firewall beobachtet, dass ständig Anfragen unserer beiden Domänencontroller
blockiert werden. Der Haupt-DC hat z.B. die IPs (10.0.0.43 und 192.168.6.43). Das komische ist, dass die Anfragen,
die blockiert werden, eigentlich Ziel-IPs haben, die in unserem Backbone liegen, z.B. zur IP 192.168.6.42 (ein TS).
Meist ist Port 137 betroffen. Die Meldungen sehen etwa so aus:
Deny 10.0.0.43 (Port 137) -> 192.168.6.42 (Port 137) netbios-ns/udp
Die Frage ist, wieso versucht der DC den Terminalserver mit seiner Backbone-Adresse über die falsche Netzwerk-
Karte zu erreichen? Er hat eine 2.Netzwerkkarte, die direkt in dem gesuchten Netz liegt. Die Server sind auch
tatsächlich ohne Probleme über ihre Backbone-Adressen vom DC zu erreichen (z.B. über ping). Durchschnittlich
1 mal in der Sekunde kommt eine Anrfage vom DC zu einem anderen Server über die falsche Karte bei der Firewall
an und wird dort blockiert.
Wir benutzen nur Win2008R2-Server (DCs und TS) und haben eine 2008er Domäne. Die DCs und einige andere Server
sind unter VMWare virtualisiert, so dass die Netzwerkkarten virtuell sind, aber der VMWare-Server hat 2 physikalische
Netzwerkkarten in beide Netze.
Ein Auszug der Config vom DC:
Kann mir da jemand weiterhelfen, oder hat zumindest eine Idee, wie man das Problem eingrenzen
kann?
Danke
Hallo zusammen,
Wir haben folgende Netzwerk-Konstellation:
| Internet | --- | Router+Firewall | --- | Hausnetz (PCs, Drucker) | --- | mehrere Server, u.a. DC | --- | Backbone |
|---|---|---|---|---|---|---|---|---|
| (10.0.0.31) | (10.0.0.0/16) | (haben je 2 Ethernet-Karten) | (192.168.6.0/24) |
Es gibt also 2 Netze (10er und 192er abgekürzt). Im 10er Netz hängt der Router, der ebenfalls Firewall spielt,
sowie alle Arbeitsstation, Drucker und Server. Alle Server haben noch eine 2.Netzwerkkarte, über die diese
nochmal in einem schnelleren Backbone untereinander verbunden sind. Wir nutzen z.B. viele Terminalserver
und Datenbankserver. So können die Anwendungen auf den TSen schneller auf die Datenbanken üder das
Backbone zugreifen. Alle Server routen nicht, d.h. man kommt nicht von einem Netz in das andere.
Nur die Server können sich gegenseitig untereinander über beide Wege erreichen.
Der DNS-Server läuft auf unseren beiden DCs, dort gibt es zwei forward-Zonen (firma.de und backbone), in denen
jeweils die Server mit den jeweiligen IPs eingetragen sind.
Nun haben wir in dem Protokoll auf der Firewall beobachtet, dass ständig Anfragen unserer beiden Domänencontroller
blockiert werden. Der Haupt-DC hat z.B. die IPs (10.0.0.43 und 192.168.6.43). Das komische ist, dass die Anfragen,
die blockiert werden, eigentlich Ziel-IPs haben, die in unserem Backbone liegen, z.B. zur IP 192.168.6.42 (ein TS).
Meist ist Port 137 betroffen. Die Meldungen sehen etwa so aus:
Deny 10.0.0.43 (Port 137) -> 192.168.6.42 (Port 137) netbios-ns/udp
Die Frage ist, wieso versucht der DC den Terminalserver mit seiner Backbone-Adresse über die falsche Netzwerk-
Karte zu erreichen? Er hat eine 2.Netzwerkkarte, die direkt in dem gesuchten Netz liegt. Die Server sind auch
tatsächlich ohne Probleme über ihre Backbone-Adressen vom DC zu erreichen (z.B. über ping). Durchschnittlich
1 mal in der Sekunde kommt eine Anrfage vom DC zu einem anderen Server über die falsche Karte bei der Firewall
an und wird dort blockiert.
Wir benutzen nur Win2008R2-Server (DCs und TS) und haben eine 2008er Domäne. Die DCs und einige andere Server
sind unter VMWare virtualisiert, so dass die Netzwerkkarten virtuell sind, aber der VMWare-Server hat 2 physikalische
Netzwerkkarten in beide Netze.
Ein Auszug der Config vom DC:
D:\>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : W2KDC
Primäres DNS-Suffix . . . . . . . : firma.de
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : backbone
firma.de
Ethernet-Adapter Public-LAN:
Verbindungsspezifisches DNS-Suffix: firma.de
Beschreibung. . . . . . . . . . . : VMware PCI Ethernet Adapter #4
Physikalische Adresse . . . . . . : 00-50-56-A0-55-6F
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 10.0.0.43(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . : 10.0.0.31
DNS-Server . . . . . . . . . . . : 10.0.0.43
10.0.0.41
Primärer WINS-Server. . . . . . . : 10.0.0.43
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter Gigabit:
Verbindungsspezifisches DNS-Suffix: backbone
Beschreibung. . . . . . . . . . . : VMware PCI Ethernet Adapter #3
Physikalische Adresse . . . . . . : 00-50-56-A0-09-91
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.6.43(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DNS-Server . . . . . . . . . . . : 192.168.6.43
192.168.6.41
Primärer WINS-Server. . . . . . . : 192.168.6.43
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Tunneladapter LAN-Verbindung* 8:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix: backbone
Beschreibung. . . . . . . . . . . : isatap.backbone
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter LAN-Verbindung* 11:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix: firma.de
Beschreibung. . . . . . . . . . . : isatap.firma.de
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
D:\>route print
===========================================================================
Schnittstellenliste
13 ...00 50 56 a0 55 6f ...... VMware PCI Ethernet Adapter #4
12 ...00 50 56 a0 09 91 ...... VMware PCI Ethernet Adapter #3
1 ........................... Software Loopback Interface 1
15 ...00 00 00 00 00 00 00 e0 isatap.backbone
14 ...00 00 00 00 00 00 00 e0 isatap.firma.de
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 10.0.0.31 10.0.0.43 266
10.0.0.0 255.255.0.0 Auf Verbindung 10.0.0.43 266
10.0.0.43 255.255.255.255 Auf Verbindung 10.0.0.43 266
10.0.255.255 255.255.255.255 Auf Verbindung 10.0.0.43 266
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
192.168.6.0 255.255.255.0 Auf Verbindung 192.168.6.43 266
192.168.6.43 255.255.255.255 Auf Verbindung 192.168.6.43 266
192.168.6.255 255.255.255.255 Auf Verbindung 192.168.6.43 266
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 10.0.0.43 266
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.6.43 266
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 10.0.0.43 266
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.6.43 266
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 10.0.0.31 Standard
0.0.0.0 0.0.0.0 10.0.0.31 Standard
===========================================================================
IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 306 ::1/128 Auf Verbindung
1 306 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
KeineKann mir da jemand weiterhelfen, oder hat zumindest eine Idee, wie man das Problem eingrenzen
kann?
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 173587
Url: https://administrator.de/contentid/173587
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
6 Kommentare
Neuester Kommentar
Moin
Klar habe ich ein Idee: Indem du zuallererst einmal den vortrefflichen Artikel von dog zum Thema Multihomed DCs durchliest und auch abarbeitest.
Das, was du da konfiguriert hast ist nicht ganz so trivial, wie es auf den ersten Blick erscheint...
Gruß
Hubert
Klar habe ich ein Idee: Indem du zuallererst einmal den vortrefflichen Artikel von dog zum Thema Multihomed DCs durchliest und auch abarbeitest.
Das, was du da konfiguriert hast ist nicht ganz so trivial, wie es auf den ersten Blick erscheint...
Gruß
Hubert
Hallo Hubert,
Danke für den interessanten Link. Ich habe ihn durchgelesen und auf unseren beiden DCs kontrolliert.
Die Einstellungen stimmten weitestgehend mit der Anleitung überein.
Ich glaube aber nicht, dass ein DNS-Problem vorliegt. Der DC hat ja die korrekt IP des TS ermittelt,
jedoch versucht er (manchmal?) diesen über die falsche Ntzwerkkarte zu erreichen.
Gruß
Danke für den interessanten Link. Ich habe ihn durchgelesen und auf unseren beiden DCs kontrolliert.
Die Einstellungen stimmten weitestgehend mit der Anleitung überein.
Ich glaube aber nicht, dass ein DNS-Problem vorliegt. Der DC hat ja die korrekt IP des TS ermittelt,
jedoch versucht er (manchmal?) diesen über die falsche Ntzwerkkarte zu erreichen.
Gruß
Hast du Routing aktiviert auf den NICs oder bedienen sie getrennt diese beiden Segmente ??
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Falls ja, auf allen Servern (Gefahr der Backdoor Route !) oder nur auf einem ?
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Falls ja, auf allen Servern (Gefahr der Backdoor Route !) oder nur auf einem ?
Nein, es ist kein Routing auf den Servern konfiguriert. Man kommt nicht von einem Netz ins andere.
Beide Netze sind daher nur von den Servern selbst gleichzeitig zu erreichen, da sie jeweils zwei
NICs haben.
Das Problem ist aber genau auf zweien dieser Serve, nämlich den beiden DCs. Obwohl alles
funktioniert, kommt aud der Firewall, die nur im 10er-Netz hängt, Anfragen von den beiden DCs für
das 192er-Netz an.
Beide Netze sind daher nur von den Servern selbst gleichzeitig zu erreichen, da sie jeweils zwei
NICs haben.
Das Problem ist aber genau auf zweien dieser Serve, nämlich den beiden DCs. Obwohl alles
funktioniert, kommt aud der Firewall, die nur im 10er-Netz hängt, Anfragen von den beiden DCs für
das 192er-Netz an.
Folglich hast du also irgendwo im Netz eine "wilde" Backdoor Bridge (Layer 2 Verbindung) die Pakete aus diesem Netz illegalerweise forwardet. Das ist natürlich tödlich für die IP Kommunikation und für die Sicherheit.
Finde also heraus WO diese Löcher sind !! Das ist ganz einfach indem du dir mit dem Wireshark Sniffer oder dem MS NetMonitor einmal diese Pakete ganz genau ansiehst die dort ankommen.
Anhand deren Layer 2 Adresse sprich also der Mac Adresse bekommst du in Minutenschnelle raus WO diese Pakete herkommen bzw. WER sie sendet.
Dann kannst du diese Loch stopfen und das sollte dein Problem im Handumdrehen lösen !!
Finde also heraus WO diese Löcher sind !! Das ist ganz einfach indem du dir mit dem Wireshark Sniffer oder dem MS NetMonitor einmal diese Pakete ganz genau ansiehst die dort ankommen.
Anhand deren Layer 2 Adresse sprich also der Mac Adresse bekommst du in Minutenschnelle raus WO diese Pakete herkommen bzw. WER sie sendet.
Dann kannst du diese Loch stopfen und das sollte dein Problem im Handumdrehen lösen !!
Ich habe Wireshark mal auf einem der Server installiert, von denen die falschen Pakete ausgehen.
Auf dem Server mit den IPs 10.0.0.43 bzw. 192.168.6.43 habe ich beide NICs mal separat getracet.
Die 192er NIC schient in Ordnung zu sein, Dort gibt es nur Datenpakete aus dem eigenen 192er Netz.
Das Problem scheint aber auf der 10er NIC zu liegen. Dort werden manchmal Pakete rausgeschickt,
die eigentlich in das 192er-Netz gehören. Sende- und Empfangsport ist immer 137 (NetBios).
Beispiel eines solchen Datenpakets:
Source Dest Protocol Length Info
10.0.0.43 192.168.6.140 NBNS 98 Name query response, Requested name does not exist
Diese Pakete kommen bei unserer Firewall an und werden dort blockiert. Sie stammen also direkt vom
Absender und kommen nicht durch eine Backdoor-Bridge. Der sendende Server schickt die NetBios-Anfrage
einfach fälschlicherweise über das falsche Interface raus (10.0.0.43) und nicht über das Interface (192.168.6.43).
Ich habe gerade durch Tests festgestellt, dass die WINS-Einstellungen in den Eigenschaften der NICs eine
Rolle spielen:
Wenn ich die NetBIOS-Einstellungen dort ändere auf "NetBIOS über TCP/IP deaktivieren", dann erscheinen die
Pakete nicht mehr. Sicherlich liegt dies daran, dass ich damit NetBIOS ganz ausschalte. Hat vielleicht jemand
eine Lösung bei eingeschaltetem NetBIOS?
Auf dem Server mit den IPs 10.0.0.43 bzw. 192.168.6.43 habe ich beide NICs mal separat getracet.
Die 192er NIC schient in Ordnung zu sein, Dort gibt es nur Datenpakete aus dem eigenen 192er Netz.
Das Problem scheint aber auf der 10er NIC zu liegen. Dort werden manchmal Pakete rausgeschickt,
die eigentlich in das 192er-Netz gehören. Sende- und Empfangsport ist immer 137 (NetBios).
Beispiel eines solchen Datenpakets:
Source Dest Protocol Length Info
10.0.0.43 192.168.6.140 NBNS 98 Name query response, Requested name does not exist
Diese Pakete kommen bei unserer Firewall an und werden dort blockiert. Sie stammen also direkt vom
Absender und kommen nicht durch eine Backdoor-Bridge. Der sendende Server schickt die NetBios-Anfrage
einfach fälschlicherweise über das falsche Interface raus (10.0.0.43) und nicht über das Interface (192.168.6.43).
Ich habe gerade durch Tests festgestellt, dass die WINS-Einstellungen in den Eigenschaften der NICs eine
Rolle spielen:
Wenn ich die NetBIOS-Einstellungen dort ändere auf "NetBIOS über TCP/IP deaktivieren", dann erscheinen die
Pakete nicht mehr. Sicherlich liegt dies daran, dass ich damit NetBIOS ganz ausschalte. Hat vielleicht jemand
eine Lösung bei eingeschaltetem NetBIOS?
