Serververbindungsprobleme: Diagnoseschritte
Schritt-für-Schritt-Anleitung zur Diagnose von Serverzugriffsproblemen: Ping, SSH, Port-Prüfung, Firewall und Netzwerk-Routing.
Inhaltsverzeichnis
Einführung
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.
Schritt 1: Erreichbarkeitsprüfung mit Ping
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
Ping-Ergebnisse interpretieren
| 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.
Schritt 2: SSH-Verbindungstest
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
SSH-Fehlermeldungen
# 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)
Schritt 3: Port-Zugriffsprüfung
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
Port-Status
| Status | Bedeutung |
|---|---|
| open | Port ist offen und Dienst lauscht |
| closed | Port erreichbar aber kein Dienst |
| filtered | Firewall blockiert den Port |
| timeout | Verbindungs-Timeout |
Schritt 4: Firewall-Prüfung
REXE Path Panel Prüfung
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:
- Melden Sie sich im Path Panel oder über das Regelmanagement-Produkt in Ihrem Kundenpanel an
- Klicken Sie auf die entsprechende IP-Adresse
- Überprüfen Sie, ob Filterregeln für die erforderlichen Ports vorhanden sind
- Bestätigen Sie, dass die Regeln den Status propagated haben
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.
Server-seitige Firewall
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
Firewall vorübergehend deaktivieren (nur zum Testen)
# 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.
Schritt 5: Dienststatus-Prüfung
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
Schritt 6: Netzwerk-Routing-Prüfung
# 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
Schritt 7: Konsolenzugriff
Wenn kein Netzwerkzugriff möglich ist, versuchen Sie alternative Zugriffsmethoden:
REXE Kundenpanel
- Melden Sie sich unter my.rexe.tr an
- Klicken Sie auf den entsprechenden Dienst
- Verwenden Sie den VNC-Konsolen- oder IPMI-Zugriff
- Versuchen Sie die Option zum Neustart des Servers
Fehlerbehebungs-Checkliste
#!/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 ==="
Häufige Szenarien und Lösungen
| 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 |
Fazit
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.
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.
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.
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.