69011
Sep 08, 2011, updated at Oct 18, 2012 (UTC)
9188
11
1
RDP auf Server mit 2 LAN Karten geht nicht
Hallo,
hänge gerade fest...
möchte von einem Laptop aus auf einen Windows Server 2003 mit der IP 192.168.100.1 --> alles gut
aktivieren ich auf dem Server eine zweite NIC mit der IP 172.16.30.100 geht meine RDP Verbindung nicht mehr.
habe bereits an der Bindungsreihenfolge der NICs gearbeitet aber ohne Erfolg. Woran kann es liegen? Sobald ich die 172er Karte deaktiviere geht auch das RDP wieder.
danke und gruss
hänge gerade fest...
möchte von einem Laptop aus auf einen Windows Server 2003 mit der IP 192.168.100.1 --> alles gut
aktivieren ich auf dem Server eine zweite NIC mit der IP 172.16.30.100 geht meine RDP Verbindung nicht mehr.
habe bereits an der Bindungsreihenfolge der NICs gearbeitet aber ohne Erfolg. Woran kann es liegen? Sobald ich die 172er Karte deaktiviere geht auch das RDP wieder.
danke und gruss
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: 172829
Url: https://administrator.de/contentid/172829
Printed on: April 20, 2024 at 06:04 o'clock
11 Comments
Latest comment
Hallo,
hast du für die zweite Karte ein Gateway eingetragen?
Das wird dann nichts werden
brammer
hast du für die zweite Karte ein Gateway eingetragen?
Das wird dann nichts werden
brammer
nein hab ich nicht, für die erste ja und soweit geht alles...
sobald die zweite aktiviert wird funktioniert RDP auf die erste IP nicht mehr...
sobald die zweite aktiviert wird funktioniert RDP auf die erste IP nicht mehr...
Hallo,
mit welcher Quell IP vervindest du dich auf den Rechner`?
brammer
mit welcher Quell IP vervindest du dich auf den Rechner`?
brammer
ich habe ein laptop mit der lokalen IP 172.16.100.100 und will damit per RDP auf die 192.168.100.1, das ganze geht durch eine Firewall die in eine Richtung nur Port 3389 erlaubt...
wenn ich einmal auf dem Server per RDP bin, möchte ich von hier aus dann weiter in das Netz 172.16.30.x, deshalb habe ich eine zweite Karte aus dem Bereich installiert damit der Server in beide Netze einen Fuss hat... das ganze wollte ich dann noch per RAS steuern...
und hier scheitert das ganze eben...
wenn ich einmal auf dem Server per RDP bin, möchte ich von hier aus dann weiter in das Netz 172.16.30.x, deshalb habe ich eine zweite Karte aus dem Bereich installiert damit der Server in beide Netze einen Fuss hat... das ganze wollte ich dann noch per RAS steuern...
und hier scheitert das ganze eben...
Hallo,
jetzt noch zu den beiden 172.16. Netzen die Netzwerkmaske und das Problem dürfte einfach zu lösen sein.
Für den Tunnel dürfte eine 172.16.x.x /16 definiert sein.
Die 2 NIC hat eine IP in dem Bereich 172.16.x.x das heißt im selben Netz.
Jetzt muss der Server entscheiden wohin er die Pakete für 172.16.x.x schickt.
In das entfernte Netz irgendwo hinter dem Tunnel oder in das Netz das er direkt angeschlossen sieht...
Also, entweder die Masken der beiden Netze etwas besser definieren, oder die 2 Netzwerkkarte in ein anderes IP Netz schieben.
brammer
jetzt noch zu den beiden 172.16. Netzen die Netzwerkmaske und das Problem dürfte einfach zu lösen sein.
Für den Tunnel dürfte eine 172.16.x.x /16 definiert sein.
Die 2 NIC hat eine IP in dem Bereich 172.16.x.x das heißt im selben Netz.
Jetzt muss der Server entscheiden wohin er die Pakete für 172.16.x.x schickt.
In das entfernte Netz irgendwo hinter dem Tunnel oder in das Netz das er direkt angeschlossen sieht...
Also, entweder die Masken der beiden Netze etwas besser definieren, oder die 2 Netzwerkkarte in ein anderes IP Netz schieben.
brammer
Wie Brammer schon sagte: Schau nach den Netzmasken. Sind die kleiner als /24 hast Du vermutlich das Problem gefunden.
Spannend auch die Frage ob er Routing oder ICS/NAT macht mit den 2 Nics auf dem Server:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
ne es geht um was ganz anderes... ich finde die idee beknackt aber meine vorgesetzten wollen das so...
unsere Liveumgebung hat eben die 172.16.x.x/16 Netz....
nun kamen wir auf die idee "lasst uns eine testumgebung machen um neue Dinge zuerst dort zu probieren"
also machte ich mich mit einem Azubi an die Arbeit, DC, SQL, Exchange usw usw.... lief alles reibungslos auf einem VMWare Cluster
das ganze ist dann mit der Zeit gewachsen, nicht nur wir sondern auch Entwickler aus anderen Abteilungen sollten auf die Testumgebung zugreifen, bevor Module und Anwendungen in das Livesytem übertragen werden...
Also bekam ich den Auftrag unsere Liveumgebung zu Klonen, sprich alle Server 1:1 in die Testumgebung zu porten, gleiche Hostnames, gleiche Domain, gleiche IP Adressen... Hintergedanke war der "wenn die Entwickler was testen und es klappt dann können die das 1:1 in unsere Liveumgebung rüberkopieren und gut ist"
Also hab ich jetzt meine Liveumgebung Domäne "asdf.local" mit einem 172.16.x.x/16 Netz und eine identische Testumgebung, die zwei dürfen sich natürlich nicht in die Quere kommen und wurden mittels Firewall voneinander physikalisch getrennt...
so... und jetzt kommts....
mein Client mit der IP 172.16.1.1 in der Liveumgebung soll per RDP in die 172.16.x.x/16 Testumgebung.... und auch nur per RDP in eine Richtung...
also dachte ich daran ich erstelle einen Server der als "Brücke" dient, ich schalte mich per RDP auf diese "brücke" mit der 192.168.100.1, der hat wiederrum eine NIC mit der 172.16er Adresse um in die Testumgebung zu kommen, auch nur per RDP in eine Richtung....
was für ein Gangbang....
unsere Liveumgebung hat eben die 172.16.x.x/16 Netz....
nun kamen wir auf die idee "lasst uns eine testumgebung machen um neue Dinge zuerst dort zu probieren"
also machte ich mich mit einem Azubi an die Arbeit, DC, SQL, Exchange usw usw.... lief alles reibungslos auf einem VMWare Cluster
das ganze ist dann mit der Zeit gewachsen, nicht nur wir sondern auch Entwickler aus anderen Abteilungen sollten auf die Testumgebung zugreifen, bevor Module und Anwendungen in das Livesytem übertragen werden...
Also bekam ich den Auftrag unsere Liveumgebung zu Klonen, sprich alle Server 1:1 in die Testumgebung zu porten, gleiche Hostnames, gleiche Domain, gleiche IP Adressen... Hintergedanke war der "wenn die Entwickler was testen und es klappt dann können die das 1:1 in unsere Liveumgebung rüberkopieren und gut ist"
Also hab ich jetzt meine Liveumgebung Domäne "asdf.local" mit einem 172.16.x.x/16 Netz und eine identische Testumgebung, die zwei dürfen sich natürlich nicht in die Quere kommen und wurden mittels Firewall voneinander physikalisch getrennt...
so... und jetzt kommts....
mein Client mit der IP 172.16.1.1 in der Liveumgebung soll per RDP in die 172.16.x.x/16 Testumgebung.... und auch nur per RDP in eine Richtung...
also dachte ich daran ich erstelle einen Server der als "Brücke" dient, ich schalte mich per RDP auf diese "brücke" mit der 192.168.100.1, der hat wiederrum eine NIC mit der 172.16er Adresse um in die Testumgebung zu kommen, auch nur per RDP in eine Richtung....
was für ein Gangbang....
Zitat von @69011:
mein Client mit der IP 172.16.1.1 in der Liveumgebung soll per RDP in die 172.16.x.x/16 Testumgebung.... und auch nur per RDP in
eine Richtung...
also dachte ich daran ich erstelle einen Server der als "Brücke" dient, ich schalte mich per RDP auf diese
"brücke" mit der 192.168.100.1, der hat wiederrum eine NIC mit der 172.16er Adresse um in die Testumgebung zu
kommen, auch nur per RDP in eine Richtung....
mein Client mit der IP 172.16.1.1 in der Liveumgebung soll per RDP in die 172.16.x.x/16 Testumgebung.... und auch nur per RDP in
eine Richtung...
also dachte ich daran ich erstelle einen Server der als "Brücke" dient, ich schalte mich per RDP auf diese
"brücke" mit der 192.168.100.1, der hat wiederrum eine NIC mit der 172.16er Adresse um in die Testumgebung zu
kommen, auch nur per RDP in eine Richtung....
Wie Du schon gemerkt hast, funktioniert das so nicht.
Du mußt im prinzip doppelte Adressüebrsetzung machen:
Im Produktivnetz kanns Du z.B. das Testnet als 10.17.0.0/16 aussehen lassen und im Testnetz das Produktivnetz als 10.18..0.0/16.
Ein Client im Produktivnetz kontaktiert dann halt 10.17.host und das gateway üebrsetzt dann source und destination jeweils in das andere Netz. Das geht ist aber etwas knifflig aufzusetzen.
Einfacher wäre ein NAT und ein Portforwarding, d.h. Du hast zwei NAT-Router, die ein gemeinsames von 172.16.0.0/16 verschiedenes Netz haben. Du evrbindest Dich vom Client auf den zweiten Router der dann das portforwarding zum gewünschten System macht. da der erste Router die Source-Adresse schon genattet hat, sollten keine Koflikte auftreten.
Das sind aber alles Lösungen nach dem Motto "von hinten durch die Brust ins Auge". Sinnvoller wäre es, einfach die IP-Adressverteilung ordentlich zu gestalten.
ja ich weiss 
ich hatte ja schon die lösung gefunden, die Testumgebung befand sich einen VMWare Cluster, netzwerktechnisch komplett getrennt von unserer Liveumgebung
du musst nur den VMWare Client öffnen und TaDAAAAAAAA, grosse Überraschung!! du hast alle Server in der Testumgebung auf einem Blick und kannst machen was du willst....
aber....
meinen Jungs hier ist der VMWare Client zu "umständlich"....
und deshalb wollen die jetzt unbedingt RDP, weil DAS ja auch so viel einfacher ist.... angeblich sind das alles studierte Entwickler, Ingenieure und weiss was ich.... langsam habe ich Zweifel daran...
ich hatte ja schon die lösung gefunden, die Testumgebung befand sich einen VMWare Cluster, netzwerktechnisch komplett getrennt von unserer Liveumgebung
du musst nur den VMWare Client öffnen und TaDAAAAAAAA, grosse Überraschung!! du hast alle Server in der Testumgebung auf einem Blick und kannst machen was du willst....
aber....
meinen Jungs hier ist der VMWare Client zu "umständlich"....
und deshalb wollen die jetzt unbedingt RDP, weil DAS ja auch so viel einfacher ist.... angeblich sind das alles studierte Entwickler, Ingenieure und weiss was ich.... langsam habe ich Zweifel daran...
Das mit einer Netzwerkbrücke zu lösen ist natürlich großer Unsinn, denn damit hängen die netze wieder komplett zusammen und "sehen" sich untereinander !
Genau also das was du bzw. die Vorgesetzten gerade ja NICHT willst.
Mal davon abgesehen das eine Bridge ein Performance Fresser sondergleichen ist durchs Broadcast und Unicast Forwarding. Das Szenario kannst du also gleich ganz vergessen.
Wenn die Testumgebung und Produktivumgebung wirklich komplett gleich ist IP seitig und du keinerlei Chancen hast das zu ändern von der Adressierung benötigt du einen Router der beide netze koppelt und statisches NAT oder Pool NAT macht und die IP Adressen umsetzt.
Kleine Ciscos, Mikrotik 750 usw. können sowas. Damit könnte man das "Problem" dann auch lösen ohne die Endgeräte anfassen zu müssen !
Genau also das was du bzw. die Vorgesetzten gerade ja NICHT willst.
Mal davon abgesehen das eine Bridge ein Performance Fresser sondergleichen ist durchs Broadcast und Unicast Forwarding. Das Szenario kannst du also gleich ganz vergessen.
Wenn die Testumgebung und Produktivumgebung wirklich komplett gleich ist IP seitig und du keinerlei Chancen hast das zu ändern von der Adressierung benötigt du einen Router der beide netze koppelt und statisches NAT oder Pool NAT macht und die IP Adressen umsetzt.
Kleine Ciscos, Mikrotik 750 usw. können sowas. Damit könnte man das "Problem" dann auch lösen ohne die Endgeräte anfassen zu müssen !
