RDP-Verbindungsproblem: Keine Verbindung zu Windows Server
Anleitung zur Behebung von RDP-Verbindungsproblemen: Path.net Firewall-Regeln, Default Block, Filterregel für RDP-Port erstellen und Fehlerbehebungsschritte.
Inhaltsverzeichnis
Einleitung
Wenn Sie sich nicht per RDP (Remote Desktop Protocol) mit Ihrem Windows Server verbinden können, wurde höchstwahrscheinlich keine Filterregel für den RDP-Port (3389) in der Path.net-Firewall erstellt.
Auf REXE Teknoloji-Servern arbeitet das Path.net DDoS-Schutzsystem automatisch anhand der Regeln. Wenn eine IP keine einzige Regel hat, sind alle Ports offen. Sobald Ihre IP jedoch mindestens eine Regel hat, wendet das System automatisch Default Block an und nur die erlaubten Ports bleiben offen. Für die RDP-Verbindung müssen Sie eine Filterregel erstellen, die den RDP-Port (3389) öffnet.
Diese Anleitung funktioniert nach der gleichen Logik wie die SSH-Verbindungsproblem-Anleitung. Der Unterschied ist nur die Portnummer: SSH → 22, RDP → 3389.
Ursache des Problems
Wenn auf Ihrer IP eine Regel vorhanden ist, wendet Path.net automatisch Default Block an; in diesem Fall wird der RDP-Port (TCP 3389) blockiert, wenn keine Regel dafür existiert:
RDP-Verbindungsanfrage → Path.net Firewall
→ Regel für Port 3389 vorhanden?
→ Nein → Verbindung blockiert (Timeout)
→ Ja → Verbindung erlaubt
Lösung: Filterregel für den RDP-Port erstellen
Für den RDP-Zugang müssen Sie eine portspezifische Filterregel über das Path Panel oder das Produkt Regelverwaltung in Ihrem Kundenbereich erstellen. Diese Regel öffnet nur den RDP-Port (3389) — alle anderen Ports bleiben durch Default Block geschlossen.
Schritte
-
Melden Sie sich im Path Panel oder im Produkt Regelverwaltung in Ihrem Kundenbereich an
-
Klicken Sie auf der Seite IP-Verwaltung auf die Server-IP
-
Erstellen Sie eine neue Regel mit folgenden Einstellungen:
Protokoll: TCP
Zielport: 3389
Beschreibung: RDP-Zugang
- Warten Sie auf den Status propagated (2-5 Minuten)
Diese Regel öffnet nur TCP-Port 3389. Alle anderen Ports bleiben durch Default Block geschlossen.
Im Regelerstellungsbildschirm gibt es zwei Modi: Standard-Filter (Sie geben nur Protokoll + Port ein) und Hard-Filter (Layer7-Filter wie TCP Symmetric). Für RDP ist der Standard-Filter ausreichend. TCP Symmetric ist ein Hard-Filter, der Layer7-Filterung durchführt, und sollte nur bei hochsensiblen Anwendungen aktiviert werden.
Regelverteilungszeit
Die Verteilung der Regel auf alle Path.net-Netzwerkknoten kann 2-5 Minuten dauern. Verfolgen Sie den Regelstatus im Path Panel:
- pending → Erstellt, wartet auf Versand
- synced → An Path.net gesendet
- propagated → Voller Schutz aktiv, Verbindung möglich
- failed → Fehlgeschlagen, erneut versuchen
Auch wenn die Regel im Panel noch als nicht verteilt (nicht aktualisiert) angezeigt wird, wurde die Regel höchstwahrscheinlich bereits innerhalb von 2-5 Minuten ausgerollt. Der Status kann sich verzögert aktualisieren – etwa wegen des Statusabfrage-Intervalls des Panels oder der Zeit, die die Regel benötigt, um auf der Path-Seite auf allen Nodes (außer unserem) angewendet zu werden. Dies ist nur eine visuelle Verzögerung im Panel; der Port ist im System tatsächlich bereits geöffnet.
Zusätzliche Überprüfungen
Wenn nach Erstellung der Filterregel die Verbindung weiterhin nicht möglich ist:
1. RDP-Dienst überprüfen
Verbinden Sie sich über die VNC/KVM-Konsole im REXE-Kundenbereich und prüfen Sie:
- Server Manager → Local Server → Remote Desktop → muss Enabled sein
- Services → Remote Desktop Services → muss Running sein
2. Windows Firewall überprüfen
Die Windows Firewall blockiert möglicherweise RDP:
# RDP-Regel in der Windows Firewall prüfen
Get-NetFirewallRule -DisplayName "Remote Desktop*" | Select-Object DisplayName, Enabled
# RDP erlauben
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
3. RDP-Portnummer überprüfen
Der Standard-RDP-Port ist 3389. Wenn Sie einen anderen Port verwenden:
# Aktuellen RDP-Port prüfen
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber
4. Network Level Authentication (NLA)
Wenn NLA aktiviert ist und der Client nicht kompatibel ist, kann die Verbindung abgelehnt werden:
# NLA-Status prüfen
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication
5. Verbindungstest
# Port von Ihrem lokalen Computer testen
Test-NetConnection -ComputerName SERVER_IP -Port 3389
Sicherheitsempfehlungen
- Starkes Passwort verwenden: RDP-Brute-Force-Angriffe sind häufig
- NLA aktiviert lassen: Network Level Authentication bietet zusätzliche Sicherheit
- Hard-Filter (optional): Layer7-Filter wie TCP Symmetric werden nur bei hochsensiblen Anwendungen benötigt; für den Standard-RDP-Zugang genügen Protokoll + Port
- RDP-Port ändern: Erwägen Sie einen anderen Port als den Standard 3389
Wenn Sie den RDP-Port geändert haben, vergessen Sie nicht, den Port in Ihrer Path Panel Filterregel ebenfalls zu aktualisieren.
Verwandte Artikel
SSH-Verbindungsproblem: Keine Verbindung zum Server möglich
Anleitung zur Behebung von SSH-Verbindungsproblemen: Path.net Firewall-Regeln, Default Block, Filterregel für SSH-Port erstellen und Fehlerbehebungsschritte.
MTR-Test durchführen und Ergebnisse an Support senden
Anleitung zum Netzwerktest mit WinMTR und Linux MTR, ICMP-Filterregel erstellen und Ergebnisse an das Support-Team senden. Paketverlust und Latenz diagnostizieren.
Paketerfassung (PCAP) durchführen und an Support senden
Anleitung zur Paketerfassung (PCAP) mit tcpdump unter Linux und Wireshark unter Windows. PCAP-Datei für Netzwerkanalyse erstellen und an das Support-Team senden.