69011
Sep 08, 2011, updated at Oct 18, 2012 (UTC)
9194
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
Please also mark the comments that contributed to the solution of the article
Content-Key: 172829
Url: https://administrator.de/contentid/172829
Printed on: April 26, 2024 at 13:04 o'clock
11 Comments
Latest comment
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
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
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.
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 !