12
Linux Router blockiert Anmeldung von WinXP CLients an W2k3 Server
Wenn sich WinXP CLients über einen Linux-ROuter am W2k3-Domänencontroller anmelden, gibt's Probleme ...
Habe 32 PCs (WInXP SP2) und einen DC (WIndows 2003) in einem Subnetz (192.168.1.0/24). Die Anmeldung der Benutzer mit serverbaiserten Profilen klappt in dieser Konfiguration wunderbar.
Möchte die beiden Bereiche (Clients und Server) aber nun auf zwei Netze aufteilen:
Clientnetz: 192.168.2.0/24
Servernetz: 192.168.1.0/24
Die Trennung bzw. das Routing besorgt ein PC mit Debian Linux, der für das 192.168.2.0-Netz auch als DHCP-Server agiert und auch brav alle Anfragen in das 192.168.1.0 Netz leitet.
Mein Problem: Beim Anmelden von Benutzer auf den WinXP-Clients am DC können plötzlich die serverbasierten Profile nicht mehr übertragen werden! Die Benutzeranmeldung geht zwar weiter, jedoch wird ein lokales Profil verwendet.
Pings zwischen Server und Clients funktionieren; ich kann von allen Clients ins Internet und auch auf alle Freigaben im Netz zugreifen.
Nur die verflixte Profilübertragung bringt Probleme - sowohl beim An- als auch beim Abmelden.
Nehme ich den Router raus und verwende wie früher den W2k3 als DHCP-Server, so funktioniert die Sache - d.h. an der Konfiguration des Win2K3-DC bzw. der Clients kann es also nicht liegen!
Möchte die beiden Bereiche (Clients und Server) aber nun auf zwei Netze aufteilen:
Clientnetz: 192.168.2.0/24
Servernetz: 192.168.1.0/24
Die Trennung bzw. das Routing besorgt ein PC mit Debian Linux, der für das 192.168.2.0-Netz auch als DHCP-Server agiert und auch brav alle Anfragen in das 192.168.1.0 Netz leitet.
Mein Problem: Beim Anmelden von Benutzer auf den WinXP-Clients am DC können plötzlich die serverbasierten Profile nicht mehr übertragen werden! Die Benutzeranmeldung geht zwar weiter, jedoch wird ein lokales Profil verwendet.
Pings zwischen Server und Clients funktionieren; ich kann von allen Clients ins Internet und auch auf alle Freigaben im Netz zugreifen.
Nur die verflixte Profilübertragung bringt Probleme - sowohl beim An- als auch beim Abmelden.
Nehme ich den Router raus und verwende wie früher den W2k3 als DHCP-Server, so funktioniert die Sache - d.h. an der Konfiguration des Win2K3-DC bzw. der Clients kann es also nicht liegen!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 57581
Url: https://administrator.de/contentid/57581
Printed on: April 19, 2024 at 10:04 o'clock
12 Comments
Latest comment
Das ist eigentlich unmöglich, denn ein Router "sieht" lediglich den OSI Layer 3, also nur die IP Adressen und sonst nichts mehr. Was dort für Applikationen drauf sind und übertragen wird ist ihm herzlich egal....
Bist du sicher dort nicht irgendwelche iptables Filter aktiv zu haben ??? Ansonsten mal den Wireshark anklemmen auf beiden Seiten und sehen wo es hakt !
Bist du sicher dort nicht irgendwelche iptables Filter aktiv zu haben ??? Ansonsten mal den Wireshark anklemmen auf beiden Seiten und sehen wo es hakt !
Das mit OSI verstehe ich; allerdings habe ich auf dem Debian-Router auch einen DHCP-Dienst laufen, der möglicherweise ein Problem verursacht(?).
Meine dhcpd.conf sieht so aus:
Ich habe den Eintrag option-domain-name in Verdacht, da es sich ja möglicherweise um ein DNS-problem handelt? Ist der hier überhaupt notwendig, wenn ohnehin alle XP-Clients in die Domäne integriert sind und den Namen somit kennen sollten???
Hier noch mein Startskript mit Firewallregeln zum Blocken (allerdings Rechner aus einem anderen Netz):
Die IP-Forwardingregeln beziehen sich jedoch nicht auf die Rechner aus 192.168.2.0/24 - diese werden ja per Default Policy nach 192.168.1.1 durchgeroutet!
Meine dhcpd.conf sieht so aus:
option domain-name "schule.local";
option domain-name-servers 192.168.1.3;
default-lease-time 600;
max-lease-time 7200;
}
{
range 192.168.2.150 192.168.2.250;
option broadcast-address 192.168.2.255;
default-lease-time 14400;
max-lease-time 2592000;
option routers 192.168.2.1;
option domain-name-servers 192.168.1.3;
option netbios-name-servers 192.168.1.3;
host R1-02 {
hardware ethernet 00:0C:76:58:29:E8;
fixed-address 192.168.2.65;
}
host R1-03 {
hardware ethernet 00:0C:76:58:29:60;
fixed-address 192.168.2.66;
}
option domain-name-servers 192.168.1.3;
default-lease-time 600;
max-lease-time 7200;
- Nur statische Adressen in 192.168.1.0/24
}
- DAS ist das Problemnetz
{
range 192.168.2.150 192.168.2.250;
option broadcast-address 192.168.2.255;
default-lease-time 14400;
max-lease-time 2592000;
option routers 192.168.2.1;
option domain-name-servers 192.168.1.3;
option netbios-name-servers 192.168.1.3;
- Die folgenden PCs erhalten immer dieselbe Adresse
host R1-02 {
hardware ethernet 00:0C:76:58:29:E8;
fixed-address 192.168.2.65;
}
host R1-03 {
hardware ethernet 00:0C:76:58:29:60;
fixed-address 192.168.2.66;
}
- ... usw
Ich habe den Eintrag option-domain-name in Verdacht, da es sich ja möglicherweise um ein DNS-problem handelt? Ist der hier überhaupt notwendig, wenn ohnehin alle XP-Clients in die Domäne integriert sind und den Namen somit kennen sollten???
Hier noch mein Startskript mit Firewallregeln zum Blocken (allerdings Rechner aus einem anderen Netz):
#!/bin/bash
ifconfig eth0 up 192.168.1.22
ifconfig eth1 up 192.168.0.1
ifconfig eth2 up 192.168.2.1
/etc/init.d/networking start
route add default gw 192.168.1.1
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -A FORWARD -s 192.168.0.0/24 –p tcp –dport 80 -j DROP
- Netzwerkinterfaces starten
ifconfig eth0 up 192.168.1.22
ifconfig eth1 up 192.168.0.1
ifconfig eth2 up 192.168.2.1
/etc/init.d/networking start
- Standard-Route definieren
route add default gw 192.168.1.1
- Routing (IP-Forwarding) mit NAT aktivieren
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
- DHCP-Serverdienst starten
- Es folgen Firewallregeln zur Filterung der MAC-Adressen
- ------------------------------------------------------------
- aus 192.168.0.0/24 nur dem Notebook http erlauben
iptables -A FORWARD -s 192.168.0.0/24 –p tcp –dport 80 -j DROP
- SSH-Serverdienst starten
- FTP-Serverdienst starten
Die IP-Forwardingregeln beziehen sich jedoch nicht auf die Rechner aus 192.168.2.0/24 - diese werden ja per Default Policy nach 192.168.1.1 durchgeroutet!
Eigentlich sollte das nicht schaden. Den Eintrag fuer 192.168.1.0 kannst du auch entfernen wenn du hier nur eine statische Vergabe machst !!!
Das sollte aber nicht das Problem sein. Das kannst du ja ganz einfach mal querchecken indem du eine Maschine mit statischer Vergabe nimmst !
Du solltest mal einen Wireshark dazwischenhaengen und nachsehen wo es hapert. Der zeigt dir sofort an wenn irgendwelche Packet geblockt werden wuerden, was aber vermutlich nicht der Fall ist oder sein sollte
Das sollte aber nicht das Problem sein. Das kannst du ja ganz einfach mal querchecken indem du eine Maschine mit statischer Vergabe nimmst !
Du solltest mal einen Wireshark dazwischenhaengen und nachsehen wo es hapert. Der zeigt dir sofort an wenn irgendwelche Packet geblockt werden wuerden, was aber vermutlich nicht der Fall ist oder sein sollte
Danke für den Hinweis - WireShark werde ich am Mo probieren!
Allerdings habe ich herausbekommen, warum díe ANmeldung mal funktioniert und mal nicht: Immer dann, wenn mehrere Anfragen durch den Router gehen, bröselt es!
Beispielsweise habe ich heute zwei "große" Dateien (32 MB) gleichzeitig vom Lanserver über den Router gleichzeitig auf zwei Clients kopiert, wobei folgendes passiert ist: Während Client R3-01 noch kopiert, wird Kopiervorgang auf Client R3-02 gestartet - und genau in dem Moment bricht Client R3-01 mit der Fehlermeldung "Kann Quelldatei nicht lesen" ab, während Client 02 den Kopiervorgang aufnimmt. Gleiches passiert mit vier, fünf oder sechs gleichzeitig laufenden Vorgängen: alle bis auf den jeweils "jüngsten" schmieren ab.
Offenbar funktioniert der gleichzeitige Zugriff nicht - scheint so, als ob Paktete "vermischt" würden...
Wenn sich jetzt 32 Leute gleichzeitig am Lanserver anmelden und die Profildaten Kopiert werden (obwohl Eigene Dateien, Desktop, Startmenü ohnehin via Ordnerumleitung laufen) ... kein Wunder, dass es da Probleme gibt!
Was mich interessieren würde ist, woran das liegen könnte! Nehme ich nämlich den Router aus der Leitung raus, geht alles problemlos! (Da melden sich im Extrenfall an die 80 bis 100 User an).
Könnte eine defekte NIC schuld sein oder ist am Routing was falsch konfiguriert?
Allerdings habe ich herausbekommen, warum díe ANmeldung mal funktioniert und mal nicht: Immer dann, wenn mehrere Anfragen durch den Router gehen, bröselt es!
Beispielsweise habe ich heute zwei "große" Dateien (32 MB) gleichzeitig vom Lanserver über den Router gleichzeitig auf zwei Clients kopiert, wobei folgendes passiert ist: Während Client R3-01 noch kopiert, wird Kopiervorgang auf Client R3-02 gestartet - und genau in dem Moment bricht Client R3-01 mit der Fehlermeldung "Kann Quelldatei nicht lesen" ab, während Client 02 den Kopiervorgang aufnimmt. Gleiches passiert mit vier, fünf oder sechs gleichzeitig laufenden Vorgängen: alle bis auf den jeweils "jüngsten" schmieren ab.
Offenbar funktioniert der gleichzeitige Zugriff nicht - scheint so, als ob Paktete "vermischt" würden...
Wenn sich jetzt 32 Leute gleichzeitig am Lanserver anmelden und die Profildaten Kopiert werden (obwohl Eigene Dateien, Desktop, Startmenü ohnehin via Ordnerumleitung laufen) ... kein Wunder, dass es da Probleme gibt!
Was mich interessieren würde ist, woran das liegen könnte! Nehme ich nämlich den Router aus der Leitung raus, geht alles problemlos! (Da melden sich im Extrenfall an die 80 bis 100 User an).
Könnte eine defekte NIC schuld sein oder ist am Routing was falsch konfiguriert?
Wäre denkbar... Was hast du für NICs ??? Sind das Realtek Chip basierende ??? Die machen ein Großteil des Packet assembling/deassembling über die Rechner CPU. Solche Karten wären tödlich für einen Ethernet Router. Bei WAN Verbindungen ist das nicht tragisch, da die meistens begrenzt sind in der Bandbreite.
Wenn du dann noch einen altersschwachen Rechner hast wäre das ein möglicher Grund. Besser ist es hier Karten zu nehmen die das gesamte Packethandling auf dem NIC Chip bedienen, wie z.B. Karten mit Chips von Intel, Marvell, Broadcom etc.....
Wenn du dann noch einen altersschwachen Rechner hast wäre das ein möglicher Grund. Besser ist es hier Karten zu nehmen die das gesamte Packethandling auf dem NIC Chip bedienen, wie z.B. Karten mit Chips von Intel, Marvell, Broadcom etc.....
Der Router.PC ist tatsächlich eine relativ alte Kiste: Compaq PIII / 750 MHz; die betreffende NIC ist von 3Com (3Com 905 T) und stammt aus einem ausrangierten P IV.
Werde nach dem langen Wochenende einfach eine funktionierende NIC (Intel -Karte!) aus einem neueren Gerät einbauen, das mal ausprobieren und das Ergebnis hier posten.
Werde nach dem langen Wochenende einfach eine funktionierende NIC (Intel -Karte!) aus einem neueren Gerät einbauen, das mal ausprobieren und das Ergebnis hier posten.
Das wird nichts bringen (wahrscheinlich). Die 3Com karten haben einen eigene Packet Chip und machen das Processing auch onboard.
Die Leistung des Rechners sollte als Ethernet Router allemal ausreichen.
Du solltest mal sniffern mit dem Wireshark auf beiden Seiten und dir den Login Prozess mal ansehen und checken was anders ist im Packetfluss (was geht rein und was kommt raus) und was zu dem unterschiedlichen verhalten führt.
Das grenzt wenigstens die Suche ein !
Die Leistung des Rechners sollte als Ethernet Router allemal ausreichen.
Du solltest mal sniffern mit dem Wireshark auf beiden Seiten und dir den Login Prozess mal ansehen und checken was anders ist im Packetfluss (was geht rein und was kommt raus) und was zu dem unterschiedlichen verhalten führt.
Das grenzt wenigstens die Suche ein !
Mit WireShark bin ich nicht klar gekommen, die Auswertung der Logfiles ist ja eine Wissenschaft für sich ...
Muss ich den am Linux-Router laufen lassen oder am Windows CLient plus WIndows Server und dann die Logfiles vergleichen?
Habe aber etwas anderes bemerkt: Aktives FTP aus dem Problemnetz 192.168.2.0/24 über den Router ins Hauptnetz 192.168.1.0/24 hat auch nicht funktioniert; da wurde der Port 500 als Problem angegeben. Passives FTP hingegen klappt einwandfrei. Erst wenn ich am Linuxrouter den Befehl
modprobe ip_nat_ftp
eingebe, geht dann auch aktives FTP!
Offensichtlich leitet der Linuxrouter die Ports für die Datei- und Druckerfreigabe nicht korrekt an die anfragenden CLients zurück - muss also mit Masquerading o.ä. zu tun haben! Gibt es dafür ein Modul, das nachgeladen werden muss?
Muss ich den am Linux-Router laufen lassen oder am Windows CLient plus WIndows Server und dann die Logfiles vergleichen?
Habe aber etwas anderes bemerkt: Aktives FTP aus dem Problemnetz 192.168.2.0/24 über den Router ins Hauptnetz 192.168.1.0/24 hat auch nicht funktioniert; da wurde der Port 500 als Problem angegeben. Passives FTP hingegen klappt einwandfrei. Erst wenn ich am Linuxrouter den Befehl
modprobe ip_nat_ftp
eingebe, geht dann auch aktives FTP!
Offensichtlich leitet der Linuxrouter die Ports für die Datei- und Druckerfreigabe nicht korrekt an die anfragenden CLients zurück - muss also mit Masquerading o.ä. zu tun haben! Gibt es dafür ein Modul, das nachgeladen werden muss?
Das ist sehr gut möglich und der Punkt mit dem FTP spricht eigentlich dafür. Ist nur komisch was der Port 500 da zu suchen hat. Der hat freilich mit FTP nicht das Geringste zu tun.
Nein, beim Mitsniffern musst du einmal den Server mit einem Sniffer zusammen auf einen Hub stecken und den Traffic der zum Server geht mitsniffern. Es muss ein Hub sein denn auf einen Switchport kannst du den Sniffer ja logischerweise nicht stecken, denn da kommen die Packet nicht an.
Vice versa musst du das auf der Clientseite vor dem Router auch machen und den Packetfluss dort bei einem Sessionaufbau auch mitsniffern. Anhand der Unterschiede des Packetflusses weisst du dann wenigstens genau was der Router blockt. Normalerweise sollte er das natürlich nicht aber sehr wahrscheinlich sind dort ip_tables oder irgendwas im Einsatz die den Traffic noch , wie auch immer, manipulieren.
Es gilt also herauszufinden was da geblockt wird.
Nein, beim Mitsniffern musst du einmal den Server mit einem Sniffer zusammen auf einen Hub stecken und den Traffic der zum Server geht mitsniffern. Es muss ein Hub sein denn auf einen Switchport kannst du den Sniffer ja logischerweise nicht stecken, denn da kommen die Packet nicht an.
Vice versa musst du das auf der Clientseite vor dem Router auch machen und den Packetfluss dort bei einem Sessionaufbau auch mitsniffern. Anhand der Unterschiede des Packetflusses weisst du dann wenigstens genau was der Router blockt. Normalerweise sollte er das natürlich nicht aber sehr wahrscheinlich sind dort ip_tables oder irgendwas im Einsatz die den Traffic noch , wie auch immer, manipulieren.
Es gilt also herauszufinden was da geblockt wird.
Problem gelöst! Da der Kanotix-Rechner als Router fungieren soll, habe ich das MASQUERADE-Statement entfernt und statische Routen zwischen den Netzen definiert. Durch die Masquerade glauben die Windowsserver nämlich, dass die Verbindung vom gleichen Rechner (dem Kanotix-Router) aus kommt. Eine neuerliche Verbindung von einem anderen Client unterbricht die vorhergehende Sitzung und es kommt zum Abbruch der Kopiervorgänge (z.B. beim Übertragen der Profildaten o.ä.).
Das sieht nun so aus:
Am Grenznetzrechner 192.168.1.1 musste ich noch folgende Route hinzufügen:
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.22
Da der Grenznetzrechner (hat eine weltweite eindeutige fixe IP) dann Masquerading betreibt, muss das der Kanotixrouter nicht extra machen.
Ach ja: Die statische Route für Ziel 192.168.2.0/255.255.255.0 nach gw 192.168.1.22 muss nun auf allen Rechnern im Grenznetz eingetragen werden (sind eh nur 4).
Herzlichen Dank für deine Bemühungen - jetzt weiß ich endlich, wie man mit WireShark umgeht; wird mir bei zukünftigen Projekten eine große Hilfe sein!
Das sieht nun so aus:
#!/bin/bash
#Netzwerkkarten aktivieren
ifconfig eth0 up 192.168.1.22 # Schnittstelle ins Grenznetz
ifconfig eth2 up 192.168.2.1 # Schnittstelle ins interne Netz
iptables -F
iptables -P FORWARD ACCEPT
#Netzwerkkarten aktivieren
ifconfig eth0 up 192.168.1.22 # Schnittstelle ins Grenznetz
ifconfig eth2 up 192.168.2.1 # Schnittstelle ins interne Netz
- Alles ins Netz 192.168.1.0 geht über eth0 raus
- Alles ins Netz 192.168.2.0 geht über eth2 raus
- Standard-Route ins Internet geht über 192.168.1.1 (Grenznetzrechner)
- IP-Forwarding einschalten
iptables -F
iptables -P FORWARD ACCEPT
Am Grenznetzrechner 192.168.1.1 musste ich noch folgende Route hinzufügen:
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.22
Da der Grenznetzrechner (hat eine weltweite eindeutige fixe IP) dann Masquerading betreibt, muss das der Kanotixrouter nicht extra machen.
Ach ja: Die statische Route für Ziel 192.168.2.0/255.255.255.0 nach gw 192.168.1.22 muss nun auf allen Rechnern im Grenznetz eingetragen werden (sind eh nur 4).
Herzlichen Dank für deine Bemühungen - jetzt weiß ich endlich, wie man mit WireShark umgeht; wird mir bei zukünftigen Projekten eine große Hilfe sein!
Ach ja: Die statische Route für Ziel 192.168.2.0/255.255.255.0 nach gw 192.168.1.22 muss nun auf allen Rechnern im Grenznetz eingetragen werden (sind eh nur 4)....
Das ist eigentlich kompletter Unsinn, denn wenn diese Geräte den Router unter der 192.168.1.1 als default Gateway eingetragen habe erledigt der das automatisch, denn du hast ihm ja die Route:
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.22
konfiguriert !!!
Auch wenn diese 4 Clients den IPCop als Gateway haben (192.168.1.22) wäre es Blödsinn, denn der hat ja:
route add -net 192.168.2.0 netmask 255.255.255.0 dev eth2
konfiguriert.
Irgendwie hast du da ein paar sinnlose, überflüssige Routen zuviel !!!
Wenns das war bitte Thread oben als gelöst markieren !
Das ist eigentlich kompletter Unsinn, denn wenn diese Geräte den Router unter der 192.168.1.1 als default Gateway eingetragen habe erledigt der das automatisch, denn du hast ihm ja die Route:
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.22
konfiguriert !!!
Auch wenn diese 4 Clients den IPCop als Gateway haben (192.168.1.22) wäre es Blödsinn, denn der hat ja:
route add -net 192.168.2.0 netmask 255.255.255.0 dev eth2
konfiguriert.
Irgendwie hast du da ein paar sinnlose, überflüssige Routen zuviel !!!
Wenns das war bitte Thread oben als gelöst markieren !
Das war's in der Tat - man lernt nie aus. Überflüssige Route entfernt - System läuft.
Danke!
Danke!
