Schritt-für-Schritt-Anleitung zur Diagnose von Serverzugriffsproblemen: Ping, SSH, Port-Prüfung, Firewall und Netzwerk-Routing.
Wenn Sie nicht auf Ihren Server zugreifen können, kann dies verschiedene Ursachen haben: Netzwerkprobleme, Firewall-Regeln, Dienstausfälle oder Hardwarefehler. In dieser Anleitung erklären wir Ihnen systematisch die Schritte zur Diagnose von Serverzugriffsproblemen.
Prüfen Sie zunächst, ob Ihr Server im Netzwerk erreichbar ist:
# Einfacher Ping-Test
ping -c 10 SERVER_IP
# Ping mit Timeout-Einstellung
ping -c 10 -W 3 SERVER_IP
| Ergebnis | Bedeutung | Mögliche Ursache |
|---|---|---|
| Antwort erhalten | Server ist im Netzwerk erreichbar | Problem auf Dienstebene möglich |
| Request timeout | Pakete erreichen das Ziel nicht | Firewall, Netzwerkproblem oder Server heruntergefahren |
| Destination unreachable | Routing-Problem | Falsche IP, Netzwerkkonfigurationsfehler |
| 100% Paketverlust | Vollständiger Zugriffsverlust | Server heruntergefahren oder keine Netzwerkverbindung |
Bei REXE-Servern sind alle Ports offen, solange eine IP keine einzige Regel hat. Wenn Ihre IP Regeln hat, wird automatisch Default Block aktiviert; in diesem Fall kann auch für ICMP (Ping) eine Regel (Ping-Schalter) im Path Panel erforderlich sein.
Wenn Ping funktioniert, testen Sie die SSH-Verbindung:
# SSH-Verbindungstest (Verbose-Modus)
ssh -v root@SERVER_IP
# SSH mit Timeout-Einstellung
ssh -o ConnectTimeout=10 root@SERVER_IP
# SSH über bestimmten Port
ssh -p 2222 root@SERVER_IP
# Connection refused — SSH-Dienst läuft nicht oder falscher Port
ssh: connect to host SERVER_IP port 22: Connection refused
# Connection timed out — Firewall blockiert oder Server nicht erreichbar
ssh: connect to host SERVER_IP port 22: Connection timed out
# No route to host — Netzwerk-Routing-Problem
ssh: connect to host SERVER_IP port 22: No route to host
# Permission denied — Authentifizierungsfehler
Permission denied (publickey,password)
Prüfen Sie, ob bestimmte Ports geöffnet sind:
# Port-Prüfung mit telnet
telnet SERVER_IP 22
telnet SERVER_IP 80
telnet SERVER_IP 443
# Port-Prüfung mit nc (netcat)
nc -zv SERVER_IP 22
nc -zv SERVER_IP 80
nc -zv -w 5 SERVER_IP 22
# Port-Scan mit nmap
nmap -p 22,80,443 SERVER_IP
# Mehrere Ports prüfen
nmap -p 1-1000 SERVER_IP
| Status | Bedeutung |
|---|---|
| open | Port ist offen und Dienst lauscht |
| closed | Port erreichbar aber kein Dienst |
| filtered | Firewall blockiert den Port |
| timeout | Verbindungs-Timeout |
Bei REXE-Servern sind alle Ports offen, solange eine IP keine einzige Regel hat. Sobald Ihre IP mindestens eine Regel hat, wird automatisch Default Block aktiviert und für den Zugriff muss der entsprechende Port mit einer Filterregel geöffnet werden:
Path Panel-Regeln können 2-5 Minuten benötigen, um den propagated-Status zu erreichen. Neu erstellte Regeln sind möglicherweise nicht sofort aktiv.
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.
Wenn Sie Konsolenzugriff auf den Server haben:
# iptables-Regeln prüfen
sudo iptables -L -n -v
# UFW-Status
sudo ufw status verbose
# firewalld-Status
sudo firewall-cmd --list-all
# nftables-Regeln
sudo nft list ruleset
# UFW deaktivieren
sudo ufw disable
# iptables-Regeln löschen
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
# firewalld stoppen
sudo systemctl stop firewalld
Das Deaktivieren der Firewall macht Ihren Server verwundbar. Verwenden Sie dies nur zu Testzwecken und aktivieren Sie die Firewall sofort nach dem Test wieder.
Wenn Sie Konsolenzugriff haben, prüfen Sie den Status der Dienste:
# SSH-Dienststatus
sudo systemctl status sshd
# Webserver-Status
sudo systemctl status nginx
sudo systemctl status apache2
# Alle laufenden Dienste auflisten
sudo systemctl list-units --type=service --state=running
# Fehlgeschlagene Dienste auflisten
sudo systemctl list-units --type=service --state=failed
# Lauschende Ports prüfen
sudo ss -tlnp
sudo netstat -tlnp
# Pfadanalyse mit Traceroute
traceroute SERVER_IP
# Detaillierte Analyse mit mtr
mtr -r -c 50 SERVER_IP
# Lokale Routing-Tabelle
ip route show
# ARP-Tabelle
arp -a
Wenn kein Netzwerkzugriff möglich ist, versuchen Sie alternative Zugriffsmethoden:
#!/bin/bash
# Server-Zugriff Fehlerbehebungs-Skript
SERVER_IP="SERVER_IP"
echo "=== Server-Zugriffsprüfung: $SERVER_IP ==="
# 1. Ping-Prüfung
echo -e "\n[1] Ping-Prüfung:"
ping -c 5 -W 3 $SERVER_IP 2>&1 | tail -2
# 2. SSH-Port-Prüfung
echo -e "\n[2] SSH-Port (22) Prüfung:"
nc -zv -w 5 $SERVER_IP 22 2>&1
# 3. HTTP-Port-Prüfung
echo -e "\n[3] HTTP-Port (80) Prüfung:"
nc -zv -w 5 $SERVER_IP 80 2>&1
# 4. HTTPS-Port-Prüfung
echo -e "\n[4] HTTPS-Port (443) Prüfung:"
nc -zv -w 5 $SERVER_IP 443 2>&1
# 5. Traceroute
echo -e "\n[5] Traceroute:"
traceroute -m 15 $SERVER_IP 2>&1
echo -e "\n=== Prüfung abgeschlossen ==="
| Szenario | Mögliche Ursache | Lösung |
|---|---|---|
| Ping funktioniert nicht, kein Port offen | Server heruntergefahren oder keine Netzwerkverbindung | Server über REXE-Panel neu starten |
| Ping funktioniert aber SSH verbindet nicht | SSH-Dienst abgestürzt oder Port blockiert | Filterregel für SSH-Port im Path Panel erstellen |
| SSH verbindet aber Website öffnet nicht | Webserver-Dienst abgestürzt | Per SSH verbinden und nginx/apache neu starten |
| Alle Ports erscheinen als filtered | Firewall blockiert gesamten Datenverkehr | Path Panel-Regeln überprüfen |
| Intermittierende Verbindungsabbrüche | Netzwerk-Paketverlust oder DDoS | mtr-Bericht erstellen und an REXE-Support senden |
Für die Lösung von Serverzugriffsproblemen ist ein systematischer Ansatz wichtig. Beginnen Sie mit der Ping-Prüfung und überprüfen Sie schrittweise Port-Zugriff, Firewall-Regeln und Dienststatus. Vergessen Sie bei REXE-Servern nicht, die Path Panel Firewall-Regeln zu überprüfen. Wenn das Problem weiterhin besteht, wenden Sie sich mit dem mtr-Bericht und den Ergebnissen der durchgeführten Prüfungen an das REXE-Support-Team.
Überprüfen Sie zunächst den Status Ihres Servers im REXE-Kundenpanel (my.rexe.tr). Wenn der Server läuft, versuchen Sie den Zugriff über die VNC-Konsole. Überprüfen Sie Ihre Firewall-Regeln im Path Panel. Wenn das Problem weiterhin besteht, eröffnen Sie ein Support-Ticket.
Dies bedeutet in der Regel, dass die Firewall den SSH-Port blockiert. Erstellen Sie im Path Panel eine TCP Symmetric Filterregel für den SSH-Port (22) und warten Sie, bis die Regel den propagated-Status erreicht (2-5 Minuten).
Der SSH-Dienst ist möglicherweise abgestürzt. Greifen Sie über die VNC-Konsole auf den Server zu und starten Sie den SSH-Dienst mit 'sudo systemctl restart sshd' neu. Überprüfen Sie auch den SSH-Port (22), er könnte geändert worden sein.
Es kann 2-5 Minuten dauern, bis die Regel den propagated-Status erreicht. Überprüfen Sie den Status der Regel im Path Panel. Stellen Sie außerdem sicher, dass Sie die richtige IP-Adresse, den richtigen Port und das richtige Protokoll ausgewählt haben.
Überprüfen Sie die Angriffsprotokolle im Path Panel. Null Route könnte aktiv sein. Das REXE DDoS-Schutzsystem wird automatisch aktiviert. Wenn der Angriff anhält, kontaktieren Sie das Support-Team.
Anleitung zur Behebung von SSH-Verbindungsproblemen: Path.net Firewall-Regeln, Default Block, Filterregel für SSH-Port erstellen und Fehlerbehebungsschritte.
Anleitung zur Behebung von RDP-Verbindungsproblemen: Path.net Firewall-Regeln, Default Block, Filterregel für RDP-Port erstellen und Fehlerbehebungsschritte.
Anleitung zum Netzwerktest mit WinMTR und Linux MTR, ICMP-Filterregel erstellen und Ergebnisse an das Support-Team senden. Paketverlust und Latenz diagnostizieren.