Strato-VServer: zunehmend Erreichbarkeitsprobleme

greystone

greystone

Active Member
Ich habe ca. vor einem Jahr meinen privaten Vserver auf Strato umgestellt. War damals sowohl preislich, als auch von der Performance absolut spitze.

Da ich den Server jedoch sehr intensiv nutze, fallen mir auch Kleinigkeiten recht schnell auf.

Aktuell habe ich zunehmend fehlgeschlagene Verbindungen. Sowohl im Webmailer, den ich dort betreibe, als auch bei einer privaten Homepage und zusätzlich gerade auch bei SSH-Verbindungen.

Das Symptom ist immer das gleiche. Eine Verbindung geht mal nicht und bei einem erneuten Versuch geht es dann wieder. Das bedeutet der Webmailer hat bei einer hohen Prozentzahl einfach fehlgeschlagenen Requests, dass ich immer den Browser-Tab wieder neu laden muss. Ebenso bei der Webseite.

Mir scheint, die Servicequalität von Strato war am Anfang zum Anlocken der Kunden bewusst etwas höher gesetzt und jetzt werden die Stellschrauben zum Einsparen angezogen. Also so wie ich's eigentlich von Strato erwarte....
 
Code: 
mtr ....

rzserver (x.x.x.x) -> meineseite.de (87.106.x.x)                                                2025-05-07T19:52:54+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                Packets               Pings
 Host                                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. reverse.myrz.de                                                            0.0%  2400    0.1   0.1   0.1   0.7   0.0
 2. ge-101-0-35.cr1a.mk.de                                                     0.0%  2400    0.3   0.4   0.2  37.9   3.1
 3. 100g-ae2.e3a.mk.de                                                         0.0%  2400    0.8   0.7   0.6  37.1   3.3
 4. decix.bb-b.fr7.fra.de.net.ionos.com                                        0.0%  2400    3.5   1.4   1.2  29.8   1.6
 5. lo-0-0.bb-b.ltz.ber.de.net.ionos.com                                       1.1%  2400   10.8  10.6  10.5  14.8   0.3
 6. lo-0-0.bb-a.rs.ber.de.net.ionos.com                                        0.0%  2400   10.7  10.5  10.4  33.0   2.2
 7. lo-0-0.rc-a.rs.ber.de.net.ionos.com                                        0.0%  2400   10.3  10.2  10.2  15.6   0.1
 8. 212.227.120.165                                                            0.0%  2400   10.4  10.3  10.2  46.3   3.2
 9. (waiting for reply)
10. (waiting for reply)
11. meinesite.de                                                               0.0%  2399   10.4  10.4  10.3  34.7   1.3

Die Ergebenisse bleiben im Verlauf im gleichen Verhältnis.
----

Ich war vielleicht ein bischen schnell da Strato den schwarzen Peter zu zu schieben.
 
Last edited:
Klingt nach DDoS-Protection / SYN-Authentication. Schneide mal den Traffic mit und schau ob du ein TCP RST zurückgeworfen bekommst :)
 
Ist seit ein paar Tagen auch wieder mal ein anderer BruteForce-Quatsch am Apache. Ganz viel davon:

Code: 
[client 38.57.3.182:39700] AH02032: Hostname meinewebseite.de provided 
    via SNI and hostname bogl.no provided via HTTP have no compatible SSL setup

Von sehr vielen IPs. Ich vermute ja nicht dass bogl.no aus Versehen einen DNS-Record mit meiner IP konfiguriert hat. Das habe ich jetzt erst mal weggeblockt.

Klingt nach DDoS-Protection / SYN-Authentication. Schneide mal den Traffic mit und schau ob du ein TCP RST zurückgeworfen bekommst :
Click to expand...

Werde ich mal machen, wenn's weiterhin auftritt.
 
Last edited:
Sieht ziehmlich übel aus:

Code: 
while :;do wget -nv  -O /dev/null  http://megabert.de/.well-known/acme-challenge/bla;sleep 1;done
2025-05-21 12:01:08 URL:http://megabert.de/.well-known/acme-challenge/bla [6/6] -> "/dev/null" [1]
fehlgeschlagen: Verbindungsaufbau abgelehnt.
2025-05-21 12:01:16 URL:http://megabert.de/.well-known/acme-challenge/bla [6/6] -> "/dev/null" [1]
2025-05-21 12:01:17 URL:http://megabert.de/.well-known/acme-challenge/bla [6/6] -> "/dev/null" [1]
fehlgeschlagen: Verbindungsaufbau abgelehnt.
2025-05-21 12:01:19 URL:http://megabert.de/.well-known/acme-challenge/bla [6/6] -> "/dev/null" [1]
fehlgeschlagen: Verbindungsaufbau abgelehnt.
...

Ca. 1/3 aller Requests schlagen fehl. Normale Webseitenrequests funktionieren zum großen Teil. Bei Neuaufruf der Webseite kommt manchmal eine fehlerhafte Anzeige. Bei wiederholten Aufrufen ist alles ok. SSH wie gehabt. Beim ersten oder den ersten paar Versuchen Fehler. Dann geht es wieder.

Per tcpdump sehe ich dann, dass da jeweils ein ICMP unreachable zurückkommt:

Für HTTP:

Code: 
12:03:43.458358 eno1  Out IP 192.168.1.149.47616 > 87.106.33.206.80: Flags [.], ack 290, win 501, options [nop,nop,TS val 617493601 ecr 1448343887], length 0
12:03:44.453916 eno1  Out IP 192.168.1.149.47630 > 87.106.33.206.80: Flags [S], seq 3181730635, win 64240, options [mss 1460,sackOK,TS val 617494596 ecr 0,nop,wscale 7], length 0
12:03:44.472776 eno1  In  IP 87.106.33.206 > 192.168.1.149: ICMP 87.106.33.206 tcp port 80 unreachable, length 68

Für SSH:

Code: 
12:10:00.448332 eno1  Out IP 192.168.1.149.34496 > 87.106.33.206.12345: Flags [P.], seq 500271954:500272006, ack 3798310638, win 4110, options [nop,nop,TS val 617870591 ecr 1448660900], length 52
12:10:00.467069 eno1  In  IP 87.106.33.206.12345 > 192.168.1.149.34496: Flags [P.], seq 1:29, ack 52, win 501, options [nop,nop,TS val 1448720896 ecr 617870591], length 28
12:10:00.467093 eno1  Out IP 192.168.1.149.34496 > 87.106.33.206.12345: Flags [.], ack 29, win 4110, options [nop,nop,TS val 617870609 ecr 1448720896], length 0
12:10:01.588595 eno1  Out IP 192.168.1.149.55434 > 87.106.33.206.12345: Flags [S], seq 1721086836, win 64240, options [mss 1460,sackOK,TS val 617871731 ecr 0,nop,wscale 7], length 0
12:10:01.609357 eno1  In  IP 87.106.33.206 > 192.168.1.149: ICMP 87.106.33.206 tcp port 12345 unreachable, length 68
12:10:04.924469 eno1  Out IP 192.168.1.149.55450 > 87.106.33.206.12345: Flags [S], seq 2002463942, win 64240, options [mss 1460,sackOK,TS val 617875067 ecr 0,nop,wscale 7], length 0
12:10:04.944369 eno1  In  IP 87.106.33.206.12345 > 192.168.1.149.55450: Flags [S.], seq 2634080701, ack 2002463943, win 65160, options [mss 1420,sackOK,TS val 1448725373 ecr 617875067,nop,wscale
7], length 0

Nachtrag:

Letsencrypt funktioniert auch nicht mehr.

Ich bekomme eine Meldung:

Code: 
certbot renew --cert-name megabert.de
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/megabert.de.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for megabert.de

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: megabert.de
  Type:   connection
  Detail: During secondary validation: 87.106.33.206: Fetching http://megabert.de/.well-known/acme-challenge/cVmFdJcyNg02524bChtQXG258qQ6V_9_h29uG6yo4dk
: Connection refused

Ich sehe entsprechende Requests im Apache access.log. Allerdings führt Letsencrypt wohl mehrere Requests durch und es schlägt wohl mindestens immer einer fehl, weswegen Letsencrypt gar nicht mehr verlängert.

Hier nochmal ein nmap:

Code: 
while :; do nmap -p80 megabert.de |grep 80/tcp;sleep 1;done

80/tcp filtered http
80/tcp filtered http
80/tcp filtered http
80/tcp filtered http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp filtered http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp open  http
80/tcp filtered http
80/tcp open  http
80/tcp open  http
80/tcp filtered http
80/tcp filtered http
80/tcp open  http
80/tcp filtered http
80/tcp open  http
80/tcp filtered http
80/tcp open  http
80/tcp filtered http
80/tcp filtered http
80/tcp filtered http
80/tcp open  http
80/tcp filtered http

Das ist jetzt aus meinem RZ. Von meinem Arbeitsplatz sieht es noch viel schlimmer aus.
 
Last edited:
Wiederhole den tcpdump auf Serverseite, aber beschränkt auf die IP, mit der du das (parallel) reproduzierst:

Code: 
tcpdump -nn host <IP>

Ich möchte vorsichtig vermuten, dass die ICMP-Pakete von deinem Server kommen und nicht von Strato.

… fail2ban? :D
 
Das ist jetzt mit hochgefahrenem Strato-Rettungssystem (Rescue muss dort netzwerkmässig manuell konfiguriert werden):

Code: 
while :;do nmap -p22 87.106.33.206|grep 22/tcp;sleep 1;done
22/tcp open  ssh
22/tcp open  ssh
22/tcp open  ssh
22/tcp open  ssh
22/tcp open  ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh
22/tcp filtered ssh

Und vermutlich der Port der VNC-Konsole:

Code: 
 while :;do nmap -p3389 87.106.33.206|grep 3389/tcp;sleep 1;done

3389/tcp open  ms-wbt-server
3389/tcp open  ms-wbt-server
3389/tcp open  ms-wbt-server
3389/tcp open  ms-wbt-server
3389/tcp open  ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server
3389/tcp filtered ms-wbt-server

… fail2ban? :D
Click to expand...

Wenn es fail2ban wäre, dann würde das nicht sekündlich wechseln.
 
Ok. Ist tatsächlich - wie von Dir vermutet - meine eigene Schuld:

Code: 
iptables -L INPUT -v -n
...
  160  8628 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 limit: avg 1/sec burst 3
  213 12340 REJECT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 reject-with icmp-port-unreachable
...

Da ist wohl von irgendwelchen iptables Experimenten / Scripten noch etwas übrig geblieben.

Der Strato Support hat einen guten Tip geliefert: Wenn das im Rescue nicht da ist, dann ist es die Serverkonfiguration ...

Da bei mir im Netz noch in kurzen intervallen ein Alive-Check Verbindungen zum Server aufbaut, greift das Limit noch viel schneller.

Danke für's mit anschauen des Problems!

-----

Eigentlich würde ich jetzt den Thread-Titel ändern in...

[gelöst] Strato-VServer: zunehmend Erreichbarkeitsprobleme (->Serverkonfigurationsfehler)​

Geht hier leider nicht wegen fehlenden Rechten.

-----

Nachtrag: Das Rettungssystem von Strato ist sehr bescheiden. Ist nur ein gparted, was keine Netzwerkkonfiguration hat. Muss man dann selbst konfigurieren, in dem man es sich aus dem Produktiv-System zieht:

# IPV4 zuweisen
ip addr add your.ip.v4.address dev eth0

# interface aktivieren
ip link set up dev eth0

# Point-to-Point Route auf das Default-GW
ip addr add your.ip.v4.addresse peer your.ip.v4.gateway dev eth0

# default route setzen
ip route add default via your.ip.v4.gateway

Ansonsten hat die Shell da auch keine Jobcontrol. D. h. Befehl können nicht abgebrochen werden. (ping nur mit -c / -w!)
 
Last edited:
You must log in or register to reply here.
Back
Top