Ich habe Probleme mit der Firewall-Richtlinie, woran kann das liegen?

ICMP-Regel erstellen, wenn Windows trotz ICMP-Freigabe nicht pingt

Es kann sein, dass ein Windows-Server auch dann nicht pingt, obwohl ICMP in der Firewall im Cloud Panel explizit erlaubt wurde.

Ursache ist in diesem Fall wahrscheinlich die Windows-Firewall, da diese bei den Windows-Images ebenfalls mit der Haupt-Regel "Alles verbieten" vorkonfiguriert ist. Daher benötigen Sie auch hier eine entsprechende ICMP-Regel.

Lösungen:

• Sie deaktivieren die Windows-Firewall komplett, sofern Ihnen die Firewall aus dem Cloud Panel ausreicht.
• Sie aktivieren die bereits vorhandene Regel für ICMP:
  Windows-Firewall > Erweiterte Einstellungen > Eingehende Regeln > Datei- und Druckerfreigabe (Echoanforderung - ICMPv4-eingehend)

Hinweise zur externen Firewall

In der STRATO ServerCloud-Infrastruktur befinden sich alle Server hinter einen externen Hardware-Firewall. Diese können Sie über Ihr Cloud Panel mittel Regelsätzen konfigurieren.

Wenn Sie einen Server neu erstellen, erhält dieser automatisch einen vordefinierten (nicht konfigurierbaren) Systemregelsatz zugewiesen (Linux / Windows).

Standardfreigaben der Systemregelsätze

Erstellung eigener Regelsätze

Wenn Sie von den Systemregelsätze abweichende Freigaben benötigen, müssen Sie einen eigenen Regelsatz erstellen und diesen anstelle des Systemregelsatzes zuweisen.

Server-Dienst / Port ist nicht erreichbar

Ist zum Beispiel der Webserver auf Port 80 (HTTP) nicht mehr, oder grundsätzlich nicht erreichbar, handelt es sich wahrscheinlich um eine der folgenden Ursachen:

a) Der Dienst ist abgestürzt.
b) Der Dienst ist falsch konfiguriert.
c) Die System- oder externe Firewall ist nicht/falsch konfiguriert.

Für die Fehlerbehebung können Sie sich an den folgenden Fragen orientieren:

Lauscht der Dienst auf dem Port?

Bevor Sie tiefer in die Fehleranalyse einsteigen, sollten Sie prüfen, ob der Dienst tatsächlich läuft, und, falls ja, auf welchem Port dieser lauscht. Ggf. genügt es dann bereits, den Dienst (neu) zu starten. Oder, wenn das nicht hilft, einen Serverneustart durchzuführen.
Ob auf einem bestimmten Port ein Dienst lauscht, können Sie mit dem Kommando netstat prüfen.

Anwendungsbeispiele für netstat:

• Beispiel 1: Um zu prüfen, ob auf Windows-Systemen der Remotedesktop-Dienst auf Port 3389 lauscht, geben Sie folgenden Befehl ein:
  C:\>netstat -an | find ":3389"
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP $IP:3389 $IP:42900 ESTABLISHED
TCP [::]:3389 [::]:0 LISTENING
UDP 0.0.0.0:3389 *:*
UDP [::]:3389 *:*
  
  In diesem Beispiel steht  $IP (in Zeile 3) für die öffentliche Server-IP-Adresse.
• Beispiel 2: Um auf Linux-Systemen zu prüfen, ob sshd auf Port 22 lauscht, geben Sie folgenden Befehl ein:
  [root@localhost ~]# netstat -tlnp | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1531/sshd
tcp 0 0 :::22 :::* LISTEN 1531/sshd

  Wird der Befehl netstat nicht gefunden, versuchen Sie es stattdessen mit dem Befehl ss, der Rest (parameter, grep) bleibt gleich.
  Ggf. kann es auch notwendig sein, den Dienst - bzw. das entsprechende Software-Paket - neu zu installieren.

Wurde auf dem Server eine Firewall aktiviert?

Wenn auf dem Server selbst eine Firewall aktiv ist - zum Beispiel die Windows-Firewall - sollten Sie sicherstellen, dass der jeweilige Port dort für eingehende Verbindungen geöffnet ist.

Wurde im Cloud Panel die richtige Firewall-Richtlinie zugewiesen?

Es kann sein, dass dem Server in der externen (über das Cloud Panel zu konfigurierenden) Hardware-Firewall nicht die gewünschte Firewall-Richtlinie zugewiesen ist. Dies können Sie prüfen, indem Sie unter Infrastruktur > Server den Server anklicken und in der Funktionsübersicht nachsehen.
Um die für eine Richtlinie definierten Regeln anzuzeigen, klicken Sie im Menü auf Netzwerk > Firewall-Richtlinien und dann auf die entsprechende Richtlinie.

Erreichbarkeit prüfen

Um die Erreichbarkeit eines Ports von außerhalb zu testen, eignet sich das Tool nmap.
Beispielausgabe für einen Windows Server, auf dem Remotedesktop-Verbindungen (Port 3389 /TCP) erlaubt sind:
C:\>nmap -p 3389 -T4 -Pn $IP
––
Nmap scan report for $IP
Host is up (0.00s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-server
Beispielausgabe für einen Linux Server ohne zugewiesene Regel für SSH (Port 22/TCP):
[root@localhost ~]# nmap -p 22 -T4 -Pn $IP
Nmap scan report for $IP
Host is up.
PORT STATE SERVICE
22/tcp filtered ssh

Keine Netzwerkkonnektivität bei Linux Server nach Wiederherstellung aus Image

Wenn Sie im Cloud Panel einen Linux Server aus einem unter Infrastruktur > Images gesicherten Image wiederhergestellt haben, dieser aber nicht von außen erreichbar ist, kann die Ursache in einem (nun veralteten) Regelsatz für die Benennung der Netzwerkinterfaces liegen. Ob das bei Ihnen der Fall ist, können Sie wie folgt prüfen:

• Verbinden Sie sich per KVM-Konsole mit Ihrem Server.
• Prüfen Sie, ob die Datei /etc/udev/rules.d/70-persistent-net.rules existiert:
  [root@localhost ~]# ls -l /etc/udev/rules.d/70-persistent-net.rules
-rw-r--r-- 1 root root 422 Jan 4 11:20 /etc/udev/rules.d/70-persistent-net.rules
• Wenn ja: Löschen sie die Datei und führen Sie einen Serverneustart durch:
  [root@localhost ~]# rm -f /etc/udev/rules.d/70-persistent-net.rules
[root@localhost ~]# reboot