Jump to content

Server 2008R2 SP1 - (schon wieder) kein RDP mehr möglich nach Speicherwechsel


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Liebe Gemeinde,

 

(dieses Thema scheint sich in abgewandelter Form als Dauerbrenner zu entwickeln und tribt mich die nackte Wand hoch) ich hatte schon mal Probleme mit RDP von extern (auch auf die virtuellen Maschinen), hier hatte sich aber meine Festplatte verabschriedet, was die Fehler verursacht hatte, und nach Neuinstallation des Servers war alles gut. Auf besagtem 2008er Server R2 spielt sich folgendes Szenario ab:

 

1. AutoLogin bei einem User, der außer der Anzeige des Anrufbrantworters nichts darf. Eine externe VNC-Sitzung von außen auf diesen Server geht.

2. Über RDP ist normalerweise auch ein externer Zugriff möglich, nämlich auf das Administrator-Konto auf den Server direkt sowie auf zwei virtuelle HyperV-Maschinen - alles bestens.

 

Ich habe nun gestern die bisherigen 16 GB Arbeitsspeicher rausgerissen und gegen 32 GB ersetzt, soweit eine feine Sache. Ich konnte auch nach ersten Tests

3. am angemeldeten Anrufbeantwort-Profil aus eine interne RDP-Sitzung starten und den Server als Admin administrieren (externe Tests hatte ich keine gemacht, ich war ja direkt am Server).

 

Ein erster Zugriff heute morgen von einem externen Standort  zeigt nun:

a) Ein externer RDP-Zugriff auf den Server ist nicht mehr möglich, es kommt die Standard-Meldung.

image.png.17b440999ac2de99c6c4d3d0fa739fda.png

b) Die externen RDP-Zugriffe auf die virtuellen Maschinen auf diesem Server gehen. Die Virtuellen haben logischerweise andere IPs, ich komme nur auf die IP des Servers selber nicht mehr drauf

c) Eine VNC-Verbindung auf den Anrufbeantwort-User und von da aus interne RDP-Sitzung auf den User des Admin gehen. Ich hätte aber gerne wieder meinen unmittelbaren externen RDP-Zugriff über DynDNS (auch dieser ist unverändert).

d) Ein externer VPN-Tunnel auf den Server läuft problemlos.

 

Sonstige Änderungen am Server (bis eben auf den Speicherwechsel): Keine.

Protokoll-Einträge, die auf Fehler hinweisen: siehe hier:

image.thumb.png.2bd70d307630ee8e01da38d9ec595bad.png

Änderungen an meinem Router bzgl. Portfreigabe etc.: Keine.

IP V6 auf dem Server aktiviert: Nein (brauchte ich vorher auch nicht)

Windows-Updates in den letzten Tagen: Keine.

"ping" / "tracert" auf externe IP oder den DynDNS-Namen: Möglich.

"netstat -a" zeigt, daß der betreffende Port abgehört wird.

Am Router sehe ich, daß beim Start der RDP-Sitzung nicht mal ansatzweise ein Verbindungsversuch stattfindet.

 

Was bitte ist da schon wieder los bzw. kennt jemand Wechselwirkungen zwischen Speichererweiterungen und toten RDP-Verbindungen?

 

bearbeitet von Hepprum Hulk
Link zu diesem Kommentar

Moin,

 

die Speichererweiterung selbst können wir als Ursache wohl praktisch ausschließen. In den meisten Fällen dieser Art handelt es sich mehr um einen zeitlichen Zusammenhang, aber nicht um einen ursächlichen: Auslöser der Verhaltensänderung ist der Neustart des Servers, der durch den Hardwaretausch nötig war. Bei diesem Neustart können dann Dinge vom OS ausgeführt worden sein, die Windows bis dahin "aufgeschoben" hat, meist Updates bzw. damit zusammenhängender Austausch von Dateien.

 

Ich verstehe es richtig, dass das Problem sich nur auf RDP-Verbindungen zum Hyper-V-Host bezieht, die von "außen" kommen? Zu diesem eigentlichen Problem habe ich keine heiße Spur, nur allgemeine Hinweise:

  • Windows Server 2008 R2 ist veraltet. Gerade im Netzwerk ist Hyper-V da auch noch sehr eingeschränkt.
    (Wobei solche Probleme da natürlich nicht auftreten sollten.)
  • IPv6 abzuschalten, ist fast nie eine gute Idee. Auch nicht, wenn man es "nicht braucht" (Windows "braucht" es i.d.R. sehr wohl.)
  • Typischerweise liegen in der Netzwerkkonfiguration des Hosts Fehler vor, wenn solche Phänomene auftreten. Das liegt daran, dass die Netzwerkkonfig an der Stelle leider sehr unübersichtlich und "eigen" ist. Ich würde also vermuten, dass da der Hase im Pfeffer liegt.

Gruß, Nils

 

Link zu diesem Kommentar
vor 10 Minuten schrieb NilsK:

Ich verstehe es richtig, dass das Problem sich nur auf RDP-Verbindungen zum Hyper-V-Host bezieht, die von "außen" kommen?

 

IPv6 abzuschalten, ist fast nie eine gute Idee. Auch nicht, wenn man es "nicht braucht" (Windows "braucht" es i.d.R. sehr wohl.)

 

Richtig, alles läuft normal in dieser Richtung, nur der Host nicht.

IP6 habe ich eben wieder aktiviert. Brachte nix.

 

Die Sache mit "2008 ist veraltet" ist soweit korrekt, das Ding läuft aber, steht in meinem HomeOffice, und bisher habe ich noch keinen Spender gefunden, der mir einen 2012er oder 2016er schenkt ;-). Der 2008er konnte ich legal als Enterprise für unter € 100 kriegen, gleichlautende Angebote für neuere Versionen sind bisher Fehlanzeige.

vor 9 Minuten schrieb Gulp:

... mit nicht passender Firewallkonfiguration .......

 

Firewall ist aus, ich habe nur den Defender sowie eine MalwareBytes-AntiRansomWare.

bearbeitet von Hepprum Hulk
Link zu diesem Kommentar

Moin,

 

vor 28 Minuten schrieb Hepprum Hulk:

 

Firewall ist aus, ich habe nur den Defender sowie eine MalwareBytes-AntiRansomWare.

das ist eine ganz schlechte Idee. Aber zumindest können wir die Windows-Firewall damit als Störfaktor ausschließen. Dann kommt aber natürlich dein Malwarebytes-Gelöt in den Kreis der Verdächtigen.

 

Als nächstes käme jetzt aber die Netzwerkkonfig des Hosts ins Spiel. Wie ist die denn gebaut?

 

Gruß, Nils

 

Link zu diesem Kommentar

Firewall kann ich ein- oder ausschalten, das ändert nix. Und das Malwarebytes-Gelöt läuft ja auch unverändert (also keine Updaes derzeit oder so). Außerdem ist das nicht vergleichbar mit "normaler" AV-Software, also hat beinhaltet keine Firewall oder so.

Siehe https://forums.malwarebytes.com/topic/211708-latest-version-mbarw-beta-09-v-0918807-download/

 

 

 

Meine Netzwerkkonfig:

 

image.png.9f15d5b47effdb7ca0c141911258a20c.png

 

LAN-Verbindung:

image.png.dd84b1781e6a3c753bce8369147c8df8.png

 

LAN-Verbindung 3 (IP 200 ist der Router und der 2. DNS-Server):

image.png.89434adcca627e180d887ee396955b7a.png

image.png.ba7dd2e2d6df392967d8c6cce3e47d18.png

image.png.ada726a94b71f4c61af725d15dccd90f.png

 

 

 

 

bearbeitet von Hepprum Hulk
Link zu diesem Kommentar
vor 31 Minuten schrieb Nobbyaushb:

Dort gehören nur Windows DNS Server rein, fertig.

200 aus der Liste entfernt. Hat sich aber nichts geändert.

Ich denke auch eher, daß sich das Problem irgendwo zwischen Internet, der FritzBüchse und dem Host abspielt, nicht auf dem Host in Sachen DNS oder so. Leider sehe ich im Fritz keine Protokolle, die irgendwie auf Verbindungsversuche hindeuten (das kann das Ding nicht). In sofern kann man auch nicht diagnostizieren, ob der Fritz die Anfragen über RDP aus dem INet überhaupt registriert oder zumindest mal abweist. Der Server würde mir ja in den Protokollen wenigstens erzählen, daß ein Versuch des Connect stattgefunden hat. Fehlanzeige,

 

 

Ach so, EINE Änderung habe ich doch noch gemacht: Ich habe beiden virtuellen Maschinen gestern nach der Erweiterung je 2 GB mehr Arbeitsspeicher zugeteilt.

bearbeitet von Hepprum Hulk
Link zu diesem Kommentar

Update: Nach kleinen Problemen mit der Lizenzierung (ich habe versucht, die Lizenz zu lösen und wieder zuzuteilen; an anderer Stelle sprach einer davon, daß das die Lösung sein könnte) und einem Gespräch mit Microsoft geht der Server nun zumindest nicht mehr alle Stunde einmal aus und ist wieder aktiviert. Man sollte nicht rumspielen ;-) Da ich aber mit dem Problem selber noch keinen Meter weiter bin, habe ich mal AVM kontaktiert mit der Frage, ob ich in der FritzBox irgend welche erweiterten Protokolle finden kann. Die Frage wäre nämlich, ob schon die Box die Einwahl blockt oder auf dem Weg von der Box zum Server irgend was in die Hose geht. Ich habe die Serverprotokolle nochmal gelöscht und den Server neu gestartet in der Hoffnung, irgend welche Hinweise auf eine Portblockierung o. ä zu finden - Fehlanzeige ...

bearbeitet von Hepprum Hulk
Link zu diesem Kommentar

Update von Update: Ich habe die Protokolle der Firewall aktiviert. Interne RDP-Sitzungen auf den Server werden sauber aufgezeichnet. Bei externen benimmt sich der Server so, als ob in keinster Weise irgend was von außen kommt. Im Beispiel hier ist die 192.168.1.152 die virtuelle Maschine, die ich von außen erreiche, und die IP 192.168.1.1 ist der "echte" Server, der nicht mehr von außen erreichbar ist.

 

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2018-09-03 15:56:16 ALLOW UDP 192.168.1.152 192.168.1.1 137 137 0 - - - - - - - RECEIVE
2018-09-03 15:56:17 ALLOW UDP 192.168.1.2 192.168.1.1 137 137 0 - - - - - - - RECEIVE
2018-09-03 15:56:23 ALLOW UDP 192.168.1.1 239.255.255.250 49385 3702 0 - - - - - - - SEND
2018-09-03 15:56:23 ALLOW UDP 127.0.0.1 239.255.255.250 49385 3702 0 - - - - - - - SEND
2018-09-03 15:56:23 ALLOW UDP 127.0.0.1 239.255.255.250 49385 3702 0 - - - - - - - RECEIVE
2018-09-03 15:56:23 ALLOW UDP 127.0.0.1 239.255.255.250 49385 3702 0 - - - - - - - RECEIVE
2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - SEND
2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - RECEIVE
2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - SEND
2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - RECEIVE
2018-09-03 15:56:30 ALLOW TCP 192.168.1.152 192.168.1.1 56021 3301 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:30 ALLOW TCP 192.168.1.152 192.168.1.1 56022 3301 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55861 445 0 - 0 0 0 - - - SEND
2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55861 445 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55862 135 0 - 0 0 0 - - - SEND
2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55862 135 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55864 389 0 - 0 0 0 - - - SEND
2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55864 389 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55865 389 0 - 0 0 0 - - - SEND
2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55865 389 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:39 ALLOW UDP 192.168.1.1 255.255.255.255 22936 22936 0 - - - - - - - SEND
2018-09-03 15:56:40 ALLOW UDP 192.168.1.1 255.255.255.255 49386 22936 0 - - - - - - - SEND
2018-09-03 15:56:40 ALLOW UDP 192.168.1.1 255.255.255.255 49387 22936 0 - - - - - - - SEND
2018-09-03 15:56:45 ALLOW UDP 192.168.1.1 192.168.1.255 49388 22936 0 - - - - - - - SEND
2018-09-03 15:56:50 ALLOW UDP 192.168.1.1 192.168.1.210 49389 9 0 - - - - - - - SEND
2018-09-03 15:56:53 ALLOW UDP 192.168.1.1 255.255.255.255 22936 22936 0 - - - - - - - SEND
2018-09-03 15:56:53 ALLOW UDP 192.168.1.1 255.255.255.255 49390 22936 0 - - - - - - - SEND
2018-09-03 15:56:54 ALLOW UDP 192.168.1.1 255.255.255.255 49391 22936 0 - - - - - - - SEND
2018-09-03 15:56:57 ALLOW TCP 127.0.0.1 127.0.0.1 55867 389 0 - 0 0 0 - - - SEND
2018-09-03 15:56:57 ALLOW TCP 127.0.0.1 127.0.0.1 55867 389 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:56:58 ALLOW UDP 192.168.1.1 192.168.1.255 49392 22936 0 - - - - - - - SEND
2018-09-03 15:57:03 ALLOW UDP 192.168.1.1 192.168.1.210 49393 9 0 - - - - - - - SEND
2018-09-03 15:57:04 ALLOW TCP ::1 ::1 55868 135 0 - 0 0 0 - - - SEND
2018-09-03 15:57:04 ALLOW TCP ::1 ::1 55868 135 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55870 389 0 - 0 0 0 - - - SEND
2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55870 389 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55872 389 0 - 0 0 0 - - - SEND
2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55872 389 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:57:33 ALLOW UDP 192.168.1.1 239.255.255.250 49394 3702 0 - - - - - - - SEND
2018-09-03 15:57:33 ALLOW UDP 127.0.0.1 239.255.255.250 49394 3702 0 - - - - - - - SEND
2018-09-03 15:57:33 ALLOW UDP 127.0.0.1 239.255.255.250 49394 3702 0 - - - - - - - RECEIVE
2018-09-03 15:57:33 ALLOW UDP 127.0.0.1 239.255.255.250 49394 3702 0 - - - - - - - RECEIVE
2018-09-03 15:57:34 ALLOW TCP 192.168.1.152 192.168.1.1 56023 445 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:57:36 ALLOW 2 192.168.1.200 224.0.0.1 - - 0 - - - - - - - RECEIVE
2018-09-03 15:57:38 ALLOW 2 192.168.1.1 224.0.0.22 - - 0 - - - - - - - SEND
2018-09-03 15:57:38 ALLOW UDP 192.168.1.150 192.168.1.1 137 137 0 - - - - - - - RECEIVE
2018-09-03 15:57:44 ALLOW UDP 192.168.1.210 192.168.1.255 137 137 0 - - - - - - - RECEIVE
2018-09-03 15:57:45 ALLOW 2 192.168.1.1 224.0.0.22 - - 0 - - - - - - - SEND
2018-09-03 15:57:52 ALLOW TCP 192.168.1.1 192.168.1.200 55873 49443 0 - 0 0 0 - - - SEND
2018-09-03 15:57:57 ALLOW TCP 127.0.0.1 127.0.0.1 55875 389 0 - 0 0 0 - - - SEND
2018-09-03 15:57:57 ALLOW TCP 127.0.0.1 127.0.0.1 55875 389 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:16 ALLOW UDP 192.168.1.152 192.168.1.1 137 137 0 - - - - - - - RECEIVE
2018-09-03 15:58:17 ALLOW UDP 192.168.1.2 192.168.1.1 137 137 0 - - - - - - - RECEIVE
2018-09-03 15:58:21 ALLOW TCP 192.168.1.152 192.168.1.1 56024 135 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:21 ALLOW TCP 192.168.1.152 192.168.1.1 56025 49158 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW UDP 192.168.1.152 192.168.1.1 62025 389 0 - - - - - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56026 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56027 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56028 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56029 445 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56030 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56031 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56032 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56033 49155 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56034 88 0 - 0 0 0 - - - RECEIVE
2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56035 445 0 - 0 0 0 - - - RECEIVE

Link zu diesem Kommentar

Die Antworten hier im Board haben den TO bisher nicht befriedigt, also postet man gleich in weiteren Foren: https://social.technet.microsoft.com/Forums/de-DE/940b87ab-feda-453d-b257-924a1be285c5/server-2008r2-externe-rdp-nicht-mehr-mglich?forum=windows_Serverde

 

Steht so in den Regeln, bitte in Zukunft freiwillig posten, Danke. https://www.mcseboard.de/terms/ No. 19 ist es.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...