Verbindungsprobleme via RDP

[tschulian]

Hallo,

ich habe einen Root-Server, auf dem 2 VMs mit jeweils einer anderen virtuellen MAC und öffentlichen IP laufen.

Server1:

5.x.x.y läuft ohne Probleme. (RDP verbindung JEDERZEIT von zu Hause möglich)

Server2:

5.x.x.z hat Verbindungsprobleme. (RDP verbindung NICHT JEDERZEIT von zu Hause möglich)

Sachverhalt: Ich stelle fest, dass ich von Zuhause nicht auf Server2 mit RDP verbinden kann. Daraufhin verbinde ich mich zu dem Hauptserver (IP: 188.x.x.x) wechsle dort zu der Server2 VM und melde mich an. Ab diesem Zeitpunkt sind nun auch wieder RDP Verbindungen zum Server2 möglich (von Zuhause aus).

Jetzt verbinde ich mich direkt von Zuhause mit Server2, und schließe die RDP Verbindung wieder. Jetzt kann ich, wenn ich es nach 1-2 Minuten probiere, immer noch verbinden. Warte ich jedoch länger, wird wieder der typische RDP Fehler angezeigt.

Habe die Netzwerkkarte von Server2 schon deinstalliert, und wieder neu installiert, alle Einstellungen vorgenommen usw. aber das Problem besteht weiterhin.

Zusatzinfos:

- Server2 ist eine Kopie von Server1, MAC Adresse wurde aber abgeändert.

- Server2 hat die selben IP Einstellungen (Subnetzmaske, Gateway und DNS) wie Server1(welcher tadellos funktioniert.)

[Tiro]

Gehst Du mittels Namen auf Server2 oder IP?

Bei ersterem: alles mit DNS checken. Dafür spricht z.B. auch das es nach einer gewissen Zeit nicht mehr geht: DNS Cache Eintrag abgelaufen.

[Pitti1988]

stimme Tiro voll und ganz zu. Sollte dies dann wirklich der Fehler sein kannst du ja Name und IP von Server 2 in die lmhosts datei deines Heimrechners eintragen.

Gruß

Pitti

[Eye-Q]

Ich hoffe, dass Du bei dir zuhause eine statische externe IP-Adresse besitzt und die Server RDP-Anfragen nur von dieser statischen IP-Adresse annehmen, sonst wäre das Harakiri, RDP auf öffentlichen IP-Adressen so zugänglich zu machen... :eek

Kannst Du die VM zu der Zeit, wo Du dich nicht per RDP verbinden kannst, anpingen? Was heißt

wechsle dort zu der Server2 VM

? Inwiefern "wechseln"? Welcher Hypervisor ist im Einsatz? Hört sich verdächtig nach Hyper-V an. Gibt es beim Root-Server-Anbieter irgendwelche Firewalls/Loadbalancer, von denen Du weißt?

[tschulian]

Ich verbinde mich nur über IP Adressen...

Wie gesagt, sobald ich mich einmal über den Root "lokal" an der VM anmelde werden auch gleich wieder RDP verbindungen möglich...........

Das heißt euer DNS Problem wäre dadurch auch ausgeschlossen...

Bezüglich Ping: IMCP wurde ausgeschalten, deshalb ist generell kein Ping möglich.

Ich hoffe, dass Du bei dir zuhause eine statische externe IP-Adresse besitzt und die Server RDP-Anfragen nur von dieser statischen IP-Adresse annehmen, sonst wäre das Harakiri, RDP auf öffentlichen IP-Adressen so zugänglich zu machen... :eek

Kannst Du die VM zu der Zeit, wo Du dich nicht per RDP verbinden kannst, anpingen? Was heißt

? Inwiefern "wechseln"? Welcher Hypervisor ist im Einsatz? Hört sich verdächtig nach Hyper-V an. Gibt es beim Root-Server-Anbieter irgendwelche Firewalls/Loadbalancer, von denen Du weißt?

Benutze VMWare Player

Loadbalancer/Firewalls gibt es, müssten aber dazu gekauft werden, dass heißt dieses Fehlerkriterium fällt bei mir auch weg.

Bearbeitet 18. September 2014 von tschulian

[Tiro]

Wenn Du nur IP-Adressen nimmst, dann gilt meine nächste "Sympathie" den Energieoptionen der Netzwerkkarten. Die können ein ziemlicher "pain in the tocus" sein, wenn die zwischenrein ihrer Nickerchen machen.

[Eye-Q]

Auch wenn ich Gefahr laufe, mich zu wiederholen: hast Du dir über die (Un-)Sicherheit deiner Einstellungen Gedanken gemacht? Windows-Server mit öffentlichen IP-Adressen und aktiviertem RDP laden Cracker geradezu dazu ein, die Dinger zu kapern.

Dringende Empfehlung meinerseits deshalb: Installiere dir einen VPN-Server und sichere das Teil ab, ansonsten kannst Du in Teufels Küche kommen!

[tschulian]

Ähm, Port 3389 wird nur für bestimmte IPs freigegeben. Auf den Root kommt jeder, gut, aber diese IP kennt keiner. Die IP, die jeder kennt hat eine Firewall-Regel, die solche administrativen Zugriffe nur für die dort eingetragenen IPs zulässt.

Mein Problem besteht immer noch, vllt hier noch etwas das mir, bzw euch um mir zu helfen, helfen könnte:

Diese E-Mail ist eben genau auf den Server mit RDP Problemen bezogen:

Guten Tag,

über die Failover-IP 5.x.x.x Ihres Servers ns33xxxx.ip-188-xxx-xxx.xx wird eine unverhältnismäßig große Anzahl an Suchanfragen auf dem Netzwerk ausgeführt. Dies hängt mit der Konfiguration Ihrer Failover-IP zusammen.

------- AUSZUG DER ANFRAGEN -------

Wed Sep 17 17:03:55 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Wed Sep 17 21:59:18 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Wed Sep 17 22:04:18 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 02:59:40 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 07:59:13 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 08:01:31 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 09:40:00 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 09:42:55 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 12:59:34 2014 : arp who-has 188.x.x.xtell 5.x.x.x

Thu Sep 18 14:11:26 2014 : arp who-has 188.x.x.xtell 5.x.x.x

------- ENDE DES AUSZUGS -------

Habe jetzt einmal "arp -d *" ausgeführt, also den Arp Cache gelöscht.

Wobei ich nicht glaube das, dass was Hilft, da ich ja sobald ich mich einmal lokal an der VM anmelde, ja ohne Probleme auch Remote wieder anmelden kann für ein paar Minuten...

Bearbeitet 19. September 2014 von tschulian

[tschulian]

Edit: Ich habe jetzt auf dem virtuellen Server mit den RDP Problemen die ICMP Firewall Regel wieder deaktiviert um mal einen Dauerping auszuwerten.

Fazit nach einer Stunde: keine Abbrüche.

[Eye-Q]

Ähm, Port 3389 wird nur für bestimmte IPs freigegeben.

Wenn Du das schon als Antwort auf meinen ersten Kommentar geschrieben hättest, hätte ich das nicht noch mal angesprochen.

Auf den Root kommt jeder, gut, aber diese IP kennt keiner.

Als ob das jemanden hindern würde, einen Portscanner laufen zu lassen...

Diese E-Mail ist eben genau auf den Server mit RDP Problemen bezogen:

Ah, man kommt dem Problem näher - ich gehe davon aus, dass bei solchen (Fehl-)Konfigurationen das Netzwerk des Server-Anbieters den Server automatisch blockiert, weil eben zu viel Traffic von dem Server ausgeht.

Hast Du schon mal einen Virenscan (am besten per virtueller Live-CD an den Player weitergegeben und die virtuelle Maschine davon gestartet) gemacht? Evtl. hat sich da ein Virus/Trojaner eingenistet, der vom (hoffentlich vorhandenen) Virenscanner nicht erkannt wurde.

[tschulian]

Wieso denkt ihr denn alle so negativ?

Also, der Portscanner bringt garnichts, da die IPs der VMs direkt Bridged ist. Die Haupt-IP des "richtigen Servers" mit der IP 188.x.x.x ist dadruch geschützt.

Wie auch immer, der Dauerping läuft immer noch ohne Abbrüche durch.

Und Sorry, deinen ersten Port über die RDP unsicherheit auf Public Servern habe ich übersehen.

[Crash2001]

Äääähm Stichwort FAILOVER.... wie ist das denn mit der Failover-IP? Ist die überhaupt im Normalfall erreichbar von aussen, oder wird diese erst freigeschaltet, wenn per Failover auf diesen Server rumgeschwenkt wird? Und ist das die IP-Adresse des einen Servers, auf den du per RDP nicht problemlos draufkommst?

Ich kenne da verschiedene Möglichkeiten und habe keine Ahnung, wie das bei deinem Provider gehandhabt wird, bzw. was da mit Failover nun dort genau gemeint ist.

[*]Failover-IP ist von aussen nur erreichbar, wenn die andere IP nicht erreichbar ist. Für Administrative Zwecke gibt es noch eine andere IP.

[*]Beide IP-Adressen sind jederzeit von aussen erreichbar. Administration über diese IP-Adresse.

[*]Beide IP-Adressen sind jederzeit von aussen erreichbar. Zusätzliche administrative IP-Adresse.

[*]Es gibt eine externe IP-Adresse, die auf die als aktiv markierte IP-Adresse des Server umgemappt wird (statisches NAT o.ä.). Administration erfolgt über die internen IP-Adressen.

[*][andere weitere Möglichkeiten]...

Failover-IP-Adressen sind eigentlich nicht dazu da, um diese durchgehend zu nutzen, sondern - wie der Name es schon sagt - um beim Ausfall einzuspringen.

Daher kann es dann auch durchaus sein, dass der Provider den Traffic einschränkt oder blockiert, wenn die andere IP-Adresse aktiv ist.

[tschulian]

Hey crash,

FoIP ist nur deren Begriff.

Diese IPs sind auch für virtualisierungen (im bridge-modus) verwendbar, gibt sogar eine offizielle Anleitung.

Beide Server benutzen eine FoIP, bzw vielmehr jeder eine eigene öffentliche IP.

Habe das Problem nun gefunden.

Da Server2 eine Kopie von Server1 ist, wurde auch der arp & dns Cache von Server1 übernommen. Nachdem ich den arp Cache geleert hatte, war der Server immer erreichbar.

Was auch sein kann: der Provider hat wie es scheint die Gateways für die Subnetze ohne Ankündigungen geändert. Glücklicherweise habe ich damals zum einrichten Screenshots gemacht, und auf denen sind ganz klar andere Providerangaben zu sehen. Der Gateway war vorher x.x.x.94 und wurde nun auf x.x.x.254 geändert. Das hat übrigens auch vorhin auf Server1 durchgeschlagen und hat den produktiven Server für ca. 1,5h lahmgelegt!!!

[orioon]

Dringende Empfehlung meinerseits deshalb: Installiere dir einen VPN-Server und sichere das Teil ab, ansonsten kannst Du in Teufels Küche kommen!

Wieso betreibt man bei Windows hier so einen Aufwand?

Bei ssh wird schließlich auch oftmals kein weiteres Sicherheitslayer benutzt.

Es gab zwar vor einigen Monaten eine riskante RDP Lücke, das war aber eine große Ausnahme und kam bei ssh auch schon in ähnlicher Form vor.

Server die über das Internet erreichbar sind, stellen stets ein Sicherheitsrisiko, das sollte man nicht an einzelnen Produkten festmachen.

Es wäre super wenn hier mal jemand ein handfestes Argument bringen könnte, wieso RDP und SSH nicht vergleichbar sein sollen.

Schließlich handelt es sich nicht um Telnet o.ä.

Siehe auch: http://windows.microsoft.com/de-de/windows7/what-is-a-remote-desktop-gateway-server

Bearbeitet 25. September 2014 von orioon

[RipperFox]

Auch wenn ich Gefahr laufe, mich zu wiederholen: hast Du dir über die (Un-)Sicherheit deiner Einstellungen Gedanken gemacht? Windows-Server mit öffentlichen IP-Adressen und aktiviertem RDP laden Cracker geradezu dazu ein, die Dinger zu kapern.!

Darf ich mal fragen, wie Du Terminalserver denn einrichtest, welche ohne VPN öffentlich zugänglich sein sollen (eben via Citrix oder RDP)? Ist ja nicht so, als könnte man z.B. nicht einstellen, nach wievielen fehlgeschlagenen Anmeldungen ein Account gesperrt werden sollte oder welche Benutzer sich überhaupt Remote anmelden können, etc.

Ich stimme hier orioon zu: RDP/ICA haben - richtig konfiguriert - imho ein ähnliches höhes Sicherheitsrisiko wie z.B. SSH.

Warum denkst Du so anders darüber?

Grüße

Sascha

[Eye-Q]

Darf ich mal fragen, wie Du Terminalserver denn einrichtest, welche ohne VPN öffentlich zugänglich sein sollen (eben via Citrix oder RDP)?

Ganz einfach: gar nicht.

Wir betreuen kleine und mittlere Kunden, die alle einen sehr eingeschränkten Kreis an Mitarbeitern haben, die die Möglichkeit haben sollen, von extern auf den Terminalserver zuzugreifen. Per VPN ist es sehr viel einfacher, diese Restriktion durchzusetzen, wenn alle anderen Mitarbeiter von intern auf den Terminalserver zugreifen dürfen/müssen.

[orioon]

Beispiel: Webserver für die Public Domain

Ich erachte das Risiko höher diesen in die bestehende Infrastruktur aufzunehmen, als einen Zugang per SSH/RDP zu ermöglichen.

Einbrüche in solche Server sind relativ häufig, ein fortschreiten in gewisse Teile der Infrastruktur katastrophal.

Lücken in SSH/RDP sind vergleichsweise Nadeln im Heuhaufen verglichen mit den üblichen Sicherheitslücken bei Webservern.

Wie schätzt du hier die Situation ein?