FAQ #3396
Artikel editieren
Artikel weiterleiten

Ik heb problemen met het firewall-beleid. Wat is een mogelijke oorzaak?

Inhoudsopgave Inhoudsopgave

 

 

 

Een ICMP-regel aanmaken als Windows niet ‘pingt’ ondanks ICMP-deling

Het kan zijn dat een Windows-server niet pingt, ook al is ICMP via het cloud panel in de firewall expliciet toegestaan.
In dit geval is de oorzaak waarschijnlijk de Windows-firewall, aangezien die ook is voorgeconfigureerd met de hoofdregel ‘Forbid all’ voor de Windows-images. Daarom heb je hier ook een bijbehorende ICMP-regel nodig.
Oplossingen:

 

  • Je schakelt de Windows-firewall volledig uit als de firewall van het cloud panel voor jou voldoende is.
  • Je schakelt de bestaande regel voor ICMP in:
    Windows Firewall > Geavanceerde instellingen > Inkomende regels > Bestanden en printers delen (Echo Request - ICMPv4 Inkomend).

Opmerkingen over de externe firewall

In de STRATO ServerCloud infrastructuur staan alle servers achter een externe hardware-firewall. Je kunt dit via je cloud panel configureren met behulp van regels.
Wanneer je een nieuwe server aanmaakt, wordt er automatisch een voorgedefiniëerde (niet-configureerbare) systeemregelset (Linux / Windows) aan toegewezen.

Standaardvrijgaven van de systeemregels

22 (SSH)80 (HTTP)3389 (RDP)8443 (Plesk)
Linuxxxx
Windowsxxx

 

ICMP-pakketten (ping/traceroute) worden ook standaard gedropt. Als je wilt dat je server bereikbaar is via ping, moet je een nieuwe regelset aanmaken en daar ICMP toestaan.
De firewall is altijd actief en geconfigureerd met het standaardbeleid ‘deny all’. Je kunt deze instelling niet wijzigen. De te gebruiken ports moeten daarom expliciet worden vrijgegeven.
Zijn er geen regels aan de firewall toegewezen? Dan is de server niet bereikbaar!

 

Eigen regelsets aanmaken

Als je eigen vrijgaven (vrijgegeven poorten) nodig hebt die afwijken van de voorgeconfigureerde regels, kun je die toewijzen. Hiertoe moet je een eigen regelset aanmaken en vervolgens in plaats van de systeemset toewijzen.

Je kunt meerdere regelsets aanmaken, maar per IP-adres kan slechts één regelset actief zijn.

Serverservice/-poort is niet toegankelijk

Is bijvoorbeeld de webserver op poort 80 (HTTP) niet meer toegankelijk of onbereikbaar? Dan zijn dit de mogelijke oorzaken:

a) De service is gecrasht.
b) De service is verkeerd geconfigureerd.
c) Het systeem of de externe firewall is niet/onjuist geconfigureerd.

Voor het oplossen van problemen kun je de hierna genoemde vragen als leidraad gebruiken.

 

Is de service via de poort bereikbaar?

Voordat je dieper ingaat op de foutenanalyse, moet je controleren of de service daadwerkelijk draait en zo ja, via welke poorten deze bereikbaar is. Het kan namelijk al voldoende zijn om de service gewoon even te (her)starten. Als dat niet helpt, herstart je de server.
Met het commando netstat kun je controleren of een service via een bepaalde poort bereikbaar is..

Als de server niet toegankelijk is via SSH (Linux) of Remote Desktop Connection (Windows), moet je via de KVM-console inloggen op de server.

Voorbeelden van gebruik voor netstat:

  • Voorbeeld 1: met deze opdracht controleer je of de Remote Desktop Service via  poort 3389 op Windows-systemen bereikbaar is:
    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 dit voorbeeld staat $IP (in regel 3) voor het openbare IP-adres van de server.
  • Voorbeeld 2: om te controleren of sshd op Linux-systemen via poort 22 bereikbaar is, gebruik je deze opdracht:
    [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
    Als de opdracht netstat niet wordt gevonden, probeer je gewoon de ss-opdracht. De rest (parameter, grep) blijft hetzelfde.
    Het kan ook nodig zijn om de service of het bijbehorende softwarepakket opnieuw te installeren.

Is er een firewall op de server actief?

Als er een firewall actief is op de server zelf (bijvoorbeeld de Windows-firewall) moet je ervoor zorgen dat de betreffende poort ook daar geopend is voor inkomende verbindingen.

Is het juiste firewall-beleid toegewezen in het cloud panel?

Het is mogelijk dat de server niet het gewenste firewall-beleid heeft toegewezen in de externe hardware-firewall. Dit configureer je via het cloud panel. Je kunt dit controleren door onder Infrastructuur > Servers op de server te klikken en het functieoverzicht te bekijken.
Om de gedefinieerde regels voor een beleid te bekijken, klik je op Netwerk > Firewall-beleid in het menu en vervolgens op het juiste beleid.

De toegankelijkheid controleren

Om de bereikbaarheid van een poort van buitenaf te testen, is de nmap-tool geschikt.
Hieronder een voorbeeld voor een Windows-server waarop remote-desktopverbindingen (poort 3389 /TCP) zijn toegestaan:
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
En dit is een voorbeeld van een opdracht op een Linux-server zonder een toegewezen regel voor SSH (poort 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

ervang $IP door het IP-adres van de server.

Geen netwerkverbinding op Linux-server na herstel van het image

Heb je een Linux-server in het cloud panel hersteld vanaf een image dat je via Infrastructuur > Images had opgeslagen? En is deze server nu van buitenaf niet meer toegankelijk? Dan ligt de oorzaak vaak in een (nu verouderde) regel die de netwerkinterfaces benoemt. Je kunt dit eenvoudig controleren:

  • Log in op je server via de KVM-Konsole
  • Controleer of het bestandi /etc/udev/rules.d/70-persistent-net.rules bestaat:
    [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
  • Zo ja: verwijder het bestand en herstart de server:
    [root@localhost ~]# rm -f /etc/udev/rules.d/70-persistent-net.rules
    [root@localhost ~]# reboot
#geen-netwerkverbinding-na-herstel-image
×