Beiträge von Toto12

Ich habe den Thread nur grob überflogen und es kann sein, dass ich nicht alles verstanden habe. Ggf. hilft dies ja dennoch:

Ich habe zu Hause einen Raspi mit PiHole und OpenVPN am laufen. Zudem eine MariaDB in meinem Netcup Server in einer Docker-Umgebung.

Eine Linux Applikation auf meinen Desktop und Notebook greift direkt auf die MariaDB zu.

Ich habe es wie folgt implementiert.

- In der Applikation auf SSL/TLS den Zugriff programmiert (Git Fork)

- Auf dem Server mit iptables nur die Heinnetzadresse für dem MariaDB Port zugewiesen

- Will ich von meinen Notebook außerhalb meines Heinnetzadresse (Hotel, etc.) zugreifen, aktiviere ich das VPN

- Greife dann auf den Raspi zu und von dort geht es dann verschlüsselt zu der MariaDB

https://www.kuketz-blog.de/pi-hole-schwarzes-loch-fuer-werbung-raspberry-pi-teil1

PiVPN: Raspberry Pi mit OpenVPN – Raspberry Pi Teil3

Mit PiVPN lässt sich ein VPN auf Basis von OpenVPN einfach auf einem Raspberry Pi realisieren.

www.kuketz-blog.de

https://www.cyberciti.biz/faq/how-to-setup-mariadb-ssl-and-secure-connections-from-clients/

Toto12

Ich habe es nun wie folgt umgesetzt:

Ich habe über iptables nur die Heimnetz IP für den Port 3306 zum Zugang für die MariaDB freigegeben:

iptables --table filter --insert DOCKER-USER --protocol tcp --destination-port 3306 --jump DROP
iptables --table filter --insert DOCKER-USER --protocol tcp --source <heimnetz-ip> --destination-port 3306 --jump ACCEPT

Dann habe ich mir TLS/SSL Zertifikate für Server und Client erzeugt, gemäß dieser für mich sehr guten Anleitung erzeugt:

https://www.cyberciti.biz/faq/how-to-setup-mariadb-ssl-and-secure-connections-from-clients/

Für die Desktop Applikation QMapShack habe ich dann in meinem Git Fork noch das "DB Open" auf SSL/TLS umprogrammiert.

So gehe ich nun von außerhalb über VPN ins Heimnetz und von dort dann über SSL/TLS zur Datenbank in den Docker Container.

Damit denke ich, bin ich nun mal fürs erste auf der sicheren Seite.

Nochmals vielen Dank an Mainboarder und TBT - Ihr habt mich auf den richtigen Pfad gesetzt.

Erst schon mal vielen Dank für die Anregungen.

Ja genau. ich kann es ja einfach anders herum machen. DB Zuhause hosten und dann über VPN drauf zugreifen. Hätte ich ja auch drauf kommen können

Ja IP Wechsel ist eigentlich ein Thema. Da der Wechsel aber nur alle paar Monate vorkommt und ich ein kleines Script laufen habe, dass mir dies per E-Mail mitteilt und ich auch keine kritischen Themen als Privat-Anwender laufen habe, stelle ich die dann manuell um (VPN, etc.). Auf DynDNS habe ich bisher auch verzichtet.

Mein VPN läuft auf einem kleinen Raspi mit PiHole und PiVPN. Der Raspi wird etwas zu schwach sein für eine MariaDB. Da bräuchte ich dann noch einen kleinen Server. Dies müsste ich mal recherchieren, was hier an Hardware in Frage käme.

Die Zerotier-Lösung schaue ich mir auf jeden Fall mal an. Danke für den Tipp.

Ich habe etwas auf ubuntuusers gespienzt und die man Pages studiert. Ich werde daher temporär mal versuchen die iptables anzupassen. Dies wäre für morgen mein erster Versuch, da die Einstellungen ja flüchtig sind ...

iptables --table filter --append DOCKER_USER --protocol tcp --source my_home_net_ip --destination-port 3306 --jump ACCEPT
iptables --table filter --append DOCKER_USER --protocol tcp --destination-port 3306 --jump DROP

Hallo zusammen,

ich habe eine private Umgebung (Mailu E-Mail, Nextcloud, Webpage, MariaDB, myPhpAdmin, ...) über docker-compose Schritt für Schritt hinter einen Nginx Reverse Proxy aufgebaut.

Abgesichert habe ich dies aktuell mit Fail2ban, No-Root-Login, Public-Key und anderer ssh-Port.

Ich verwende noch eine für mich ganz nützliche Desktop Applikation QMapShack. In der MariaDB speichere ich meine GPS Fahrrad Tracks. In QMapShack gebe ich dazu die Credentials für den Zugriff auf die MariaDB Datenbank ein.

Hierzu habe ich im docker-compose für den MariaDB Service den Port 3306 aufgemacht:

...
services:
mariadb:
container_name: mariadb
image: mariadb:10.5
restart: "no"
ports:
- my_netcpup_server_ip:3306:3306
...

Das funktioniert auch soweit. Jedoch fühle ich mich nicht besonders wohl, da ich hier den Port aufmache.

Von daher will ich den Zugriff auf `Port 3306` auf eine einzige IP (Heimnetz) reduzieren und von außerhalb gehe ich dann über ein VPN drauf. Ich gehe davon aus, dass ich dies dann über Iptables machen kann/muss.

Bis dato habe ich noch noch nichts mit Iptables gemacht, habe mir aber schon ein paar Dinge angeschaut und dabei einen "heiden Respekt vor Iptables " bekommen, da auch noch Docker im Spiel ist.

Ich sehe für mich, dass ich hier nur einiges auf Anhieb richtig machen werde aber vieles falsch und nach einem "Try und Error-Thema" schaut es auch nicht aus.

Ich will mich hier dann auch nicht selber aus dem System ausschließen und dann über Rettungssystem alles wieder aktivieren.

Von daher vielen Dank für eine Starthilfe von den Experten hier in der Community.

Toto12

Zitat von frank_m

... Also höchstwahrscheinlich was auf Applikationsebene. Darauf hat Netcup keinen Einfluss. ...

Um dies auszuschließen habe ich gestern das Linux Image "RescueSystem" direkt von USB von einem Notebook gestartet und nur das Notebook an die ConnectBox (Modem/Router) per Kabel angeschlossen, alle anderen Kabel entfernt und WLAN ausgeschaltet. Also, alles soweit isoliert, damit ich meine private Installation/Applikationen soweit ausschließen kann. Dann gegen Rettungssystem mit iperf3 getestet ==> selbe Problematik. Dies dann nochmals alles dokumentiert und an netcup Support gesendet.

Dann habe ich mit Vodafone Support gesprochen. Dies war soweit interessant, dass der Supporter nicht wirklich helfen konnte, da er noch nicht einmal selbst in seine Systeme und Computer rein kam, große Störung im Bereich NRW. Ich fragte, ob er mir mal eine andere IP zuweisen könne. Nein, könne er nicht, er kann mir nur raten den Vodafone Speedtest zu machen. Aber ggf. mal die ConnectBox über Nacht ausschalten. Ggf. wird dann eine andere IPv4 zugewiesen.

Bisher hatte ich die ConnectBox nur für max. eine Stunde vom Strom. Ja und so war es dann auch. Gestern Abend die ConnectBox ausgeschaltet und heute Morgen wieder eingeschaltet, eine neue IPv4 war da und damit auch wieder der schnelle Download vom PROD-Server.

Also irgendwie haben sich die beiden IPs ncht vertragen. Weitere Details kann ich nicht erklären.

Das Problem ist für mich damit gelöst.

Ggf. hilft dies ja auch für anderen Vodafone-netcup Betroffenen hier im Forum. Ich drücke die Daumen.

Danke an Alle für Eure rege Teilnahme

Ich habe bisher Nextcloud nur unter Docker installiert. Die MariaDB läuft auch in einem Container und beim Datenbank-Host ist dann der Name des laufenden MariaDB Containers einzugeben.

Wenn die MariaDB auf dem Server installiert ist, auf dem auch die Nextcloud installiert wird, dann ist beim Datenbank-Host localhost einzugeben.

Ggf. hilft dies hier: https://www.veuhoff.net/nextcl…-22-04-komplettanleitung/

Es gibt aber auch viele weitere Anleitungen im Internet.

Zitat von frank_m

Hast du mal die Traces der funktionierenden und nicht funktionierenden Verbindungen verglichen? Was ist mit IPv6?

Mit IPv6 habe ich bisher noch nichts gemacht. Alle Installationen sind mit IPv4 erfolgt. Mit IPv6 habe ich ehrlicherweise auch noch keine Erfahrung.

Aktueller Speedtest vom Desktop über https://librespeed.org (Hetzner4 Server), Kabel an ISP Modem/Router (Unitymedia/Vodafone, 250/12 MBit/s).

Hier erreiche ich die vereinbarten Werte: https://librespeed.org/results/?id=05n6ojc

MTR Tests zu PROD-Server|TEST-Server|Google

user@desktop:~$ mtr -c 20 -r PROD-Server
Start: 2023-01-29T10:51:38+0100
HOST: desktop                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- _gateway                  95.0%    20    2.5   2.5   2.5   2.5   0.0
2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0
3.|-- ip-081-210-136-xxx         0.0%    20   17.1  18.4   8.1  66.4  12.9
4.|-- 145.253.xxx.xxx            0.0%    20   15.0  17.0  13.9  25.3   3.2
5.|-- 145.254.1.111              0.0%    20   14.6  15.9  13.3  21.9   1.9
6.|-- ae1-0.bbr01.anx84.nue.de.  0.0%    20   19.5  21.1  16.2  42.9   6.2
7.|-- 94.16.25.77                0.0%    20   43.3  21.5  17.1  43.3   6.2
8.|-- 46.38.252.41               0.0%    20   34.0  24.8  17.4  52.7   8.8
9.|-- PROD-Server                0.0%    20   24.1  18.1  15.3  24.1   2.3
user@desktop:~$ mtr -c 20 -r TEST-Server
Start: 2023-01-29T10:52:18+0100
HOST: desktop                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- _gateway                  95.0%    20    1.5   1.5   1.5   1.5   0.0
2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0
3.|-- ip-081-210-136-xxx         0.0%    20   10.5  11.5   7.7  29.3   4.3
4.|-- 145.253.xxx.xxx            0.0%    20   16.3  16.2  14.1  19.4   1.3
5.|-- 145.254.1.111              0.0%    20   16.1  17.0  13.9  35.0   4.4
6.|-- ae1-0.bbr01.anx84.nue.de.  0.0%    20   20.0  23.2  16.6  47.4   8.3
7.|-- 94.16.25.77                0.0%    20   17.8  22.5  16.7  53.6   9.1
8.|-- 46.38.252.42               0.0%    20   17.5  21.0  17.2  39.1   5.3
9.|-- TEST-Server                0.0%    20   18.6  18.7  15.4  27.1   3.2
user@desktop:~$ mtr -c 20 -r google.com
Start: 2023-01-29T10:52:59+0100
HOST: desktop                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- _gateway                  95.0%    20    2.4   2.4   2.4   2.4   0.0
2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0
3.|-- ip-081-210-136-xxx         0.0%    20   18.6  12.0   8.2  19.6   2.9
4.|-- 145.253.xxx.xxx            0.0%    20   34.6  18.9  13.8  36.6   6.5
5.|-- 145.254.1.111              0.0%    20   15.4  19.0  13.2  40.6   7.0
6.|-- 108.170.236.175            0.0%    20   22.3  18.8  14.1  60.0  10.1
7.|-- 142.251.241.75             0.0%    20   24.2  18.3  13.2  26.9   4.4
8.|-- fra16s08-in-f14.1e100.net  0.0%    20   13.6  15.8  11.7  33.2   5.1

Ich habe gestern ein Ticket im netcup Support eröffnet. Hier warte ich nun mal die Reaktion ab.

Zitat von H6G

...

Was aber unter Ubuntu eigenartig ist: die ersten Dienste sollten mit einer PID unter 1000 starten.

fail2ban kommt erst als Prozess #3000 hoch, davor fehlen 2000 Prozesse, und danach nochmal 2000 Prozesse.

Halte ich für ungewöhnlich - irgendwelche Dienste scheinen da abzuschmieren.

Danke fürs drüber schauen.

Merkwürdig ist aber, dass die Downloads zu anderen Servern (also nicht zum HOME-Environment) ok ist. Zudem ist der Download zum HOME-Environment aus dem Rettungssystem auch langsam und da ist ja ein DEBIAN aktiv.

Und die Downloads von anderen Servern (also nicht vom PROD-Server) zum HOME-Environment sind auch ok.

Nur die Download Route vom PROD-Server zum HOME-Environment scheint eine "Macke" zu haben.

Ich habe mir in den letzten Tagen endlos den Kopf zerbrochen, ob ich irgendwo genau diese Strecke (also die beiden IPs) in Verbindung gebracht habe. Aber mir fällt nichts ein.

Mal blöd und laienhaft gefragt: Ist da irgendwo, irgendwas "gecachet", also die beiden IPs irgendwo verknüpft?

Ich bin noch relativ neu hier bei netcup. Lohnt es sich hierüber ein Ticket im netcup Support zu eröffnen?

Zitat von H6G

Eigentlich nicht Aufgabe vom Router auf ICMP Echo Pakete ständig zu reagieren.

Der Ping vom 2.2 ms zum Router ist aber schon etwas hoch.

WLAN? Oder Draht mit Switchen dazwischen?

Schonmal die Switche und den Router für 30s vom Strom genommen und neugestartet?

Mein Fedora 36 Desktop ist per Ethernet-Kabel direkt an dem Modem/Router Vodafone/UnityMedia ConnectBox verbunden. Tablet, iPhone und Notebook per WLAN. Immer das gleiche Bild.

Download vom PROD-Server schlecht, Download vom TEST-Server ok. Beide Uploads ok. Downloads von anderen Server auch ok.

Vodafone/UnityMedia ConnectBox habe ich heute mehrfach aus- und wieder eingeschaltet, aber immer nur 5-10 Sekunden gewartet. Kann ich ja nochmals probieren. Heute über Tag waren immer starke Schwankungen im Upload bei Vodafone/UnityMedia, getestet mit mehreren Speedtests.

mtr -b 192.168.0.1 (über Ethernet-Kabel verbunden)

                               Packets               Pings
Host                         Loss%   Snt   Last   Avg  Best  Wrst StDev
1. _gateway (192.168.0.1)     0.0%    32    2.0   1.8   1.5   2.3   0.2

mtr -b PROD-Server (über Ethernet-Kabel verbunden)
                                      Packets               Pings
 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway (192.168.0.1)          96.7%    31    1.8   1.8   1.8   1.8   0.0
 2. (waiting for reply)
 3. ip-xxx                           0.0%    31   11.5  15.7   9.0  36.1   6.2
 4. 145.xxx                          0.0%    30   17.3  20.5  15.2  47.5   6.7
 5. 145.xxx                          0.0%    30   20.0  19.3  13.7  31.3   4.2
 6. ae1-xxx                          0.0%    30   19.5  24.6  17.4  47.0   7.6
 7. 94.xxx                           0.0%    30   20.2  23.7  17.5  79.7  11.5
 8. 46.xxx                           0.0%    30   20.8  27.0  17.6  79.2  14.1
 9. PROD-Server                      0.0%    30   16.1  21.6  15.5  36.1   5.7


mtr -b TEST-Server (über Ethernet-Kabel verbunden)
                                      Packets               Pings
 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway (192.168.0.1)          96.4%    29    1.7   1.7   1.7   1.7   0.0
 2. (waiting for reply)
 3. ip-xxx                           0.0%    28    9.7  14.3   9.3  37.9   6.8
 4. 145.xxx                          0.0%    28   14.3  17.7  14.3  33.8   4.8
 5. 145.xxx                          0.0%    28   17.1  17.8  12.6  36.1   4.6
 6. ae1-0.xxx                        0.0%    28   18.8  22.9  16.8  58.0   9.3
 7. 94.xxx                           0.0%    28   17.3  21.5  16.8  43.3   6.5
 8. 46.xxx                           0.0%    28   18.0  22.2  15.5  90.2  13.6
 9. TEST-Server                      0.0%    28   16.1  21.2  15.2  75.2  11.5

UPDATE:
mtr -b google.com (über Ethernet-Kabel verbunden)
                                                                      Packets               Pings
 Host                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway (192.168.0.1)                                          96.8%    32    1.6   1.6   1.6   1.6   0.0
 2. (waiting for reply)
 3. ip-081-210-136-168.um21.pools.vodafone-ip.de (81.210.136.168)    0.0%    31    9.8  13.0   8.0  29.0   5.0
 4. 145.253.52.32 (145.253.52.32)                                    0.0%    31   15.5  15.6  12.0  23.9   2.2
 5. 145.254.1.111 (145.254.1.111)                                    0.0%    31   13.6  16.5  12.8  40.6   5.2
 6. 108.170.236.193 (108.170.236.193)                                0.0%    31   18.2  17.7  15.0  25.4   2.7
 7. 142.250.225.77 (142.250.225.77)                                  0.0%    31   15.9  14.9  12.4  22.9   2.3
 8. fra16s52-in-f14.1e100.net (142.250.185.206)                      0.0%    31   12.7  14.4  11.2  22.1   3.3

Journal habe ich mal laienhaft durchgeschaut, ca. 1.500 Zeilen. Keine roten Zeilen.

Betriebssystem mäßig habe ich da nicht großes installiert: docker, docker-compose, fail2ban, vim. Meine Installation habe ich komplett in Docker realisiert.

Diese erst auf dem TEST-Server und dann auf dem PROD-Server eingespielt.

Ab und zu mal ein apt update/upgrade.

fail2ban habe mal deaktiviert, bringt aber das gleiche Ergebnis. Download zum HOME-Environment bei 300KB/s. Seltsam ist ja, dass der Download zu anderen IP performant ist, z.B. wenn ich z. B. über den Hotspot gehe. In meiner HOME-Umgebung sind die Downloads zu anderen Server auch performant. Nur die eine Verbindung Download PROD-Server zum HOME-Environment ist langsam, egal ob im normalen oder im Rettungssystem. ps-aux.txt im Anhang.

Zitat von frank_m

Gut ist das nicht. Ist der nach einem Reboot auch noch da, bzw. kommt er wieder? Dann gibt es da ein Problem in der Konfiguration.

Ja gerade nochmals rebootet und der Zombie Prozess rsyslogd ist wieder da.

Noch etwas: Beim Login auf dem PROD-Server erscheint eine Meldung

There is 1 zombie process

Mit Google Recherche:

ps axo stat,ppid,pid,comm | grep -w defunct

sehe ich folgenden Prozess:

Z 1431 3292 rsyslogd <defunct>

Ist dies etwas worüber ich mir Sorgen machen muss?

Als OS habe ich Ubuntu 20.04.5 LTS auf dem PROD-Server. Auf dem TEST-Server Debian GNU/Linux 10 (buster)

Alles aktuell mit apt update/upgrade.

Zitat von H6G

Dort kann man nicht einstellen, welches Adressfamilie benutzt wird. Haben die Server je eine IPv4 und Ipv6 Adresse?

Das musst du bei den Servern selbst gucken. Ebenfalls welche Records sind im DNS hinterlegt.

Macht es im Client einen Unterschied, ob du mit sftp -4 oder mit sftp -6 herunterlädst?

Die Geschwindigkeiten zwischen Server und Client kannst du auch mit iperf3 testen.

Alle DNS Einträge zeigen auf die IPv4. Ebenso die rDNS im SCP | Netzwerk. Für IPv6 habe ich nichts für beide Server eingetragen.

sftp -4 -P myPort myUser@TESTdomain.de:myBigFile .

Download by 25MB/s

sftp -4 -P myPort myUser@PRODdomain.de:myBigFile .

Download by 300KB/s

sftp -6 -P myPort myUser@TESTdomain.de:myBigFile .

sftp -6 -P myPort myUser@PRODdomain.de:myBigFile .

zeigt

ssh: Could not resolve hostname XXXXdomain.de: Name or service not known

Wechsele ich von ISP/Ethernet auf iPhone Hotspot/WLAN habe ich bei beiden einen Download von 2MB/s.

Download im aktivierten Rettungssystem ebenfalls beim PROD-Server bei 300KB/s zum Fedora Client.

Zitat von Jimi

... Eventuell helfen ja die Netzwerk-Wartungsarbeiten die Netcup heute Nacht durchführen will. Netzwerk-Wartungsarbeiten-am-26-01-2023

Leider war bei den Wartungsarbeiten für mich nichts dabei, gleiches Verhalten . Upload ist ok für alle Server. Nur Download from PROD-Server zum HOME-Environment sehr langsam, ~300KB/s.

Ich messe nun mal den Download vom PROD-Server im Rettungssystem.

Zitat von tab

...Was ist _gateway? Eine Besonderheit deiner Umgebung? ...

Da bin ich zu wenig Experte, um dies genau zu sagen. Keine Ahnung woher dies kommt und was dies ist. Ich habe dies heute auch zum ersten Mal gesehen. Es kommt aber auch bei mtr auf den TEST-Server und der lädt ja performant zu meinem HOME-Environment.

Ich habe seit Jahr und Tage eine Pi.Hole auf einen Raspi laufen. Dahin stelle ich dann in meinen Clients die Ethernet/Internet Verbindung für IP4 DNS manuell ein. Ich hatte den Raspi aber auch schon komplett ausgeschaltet und die DNS Einträge wieder auf Automatisch gestellt, also DNS Bezug über Unitymedia/Vodafone. Den PROD-Server hatte ich vor ca. einem halben Jahr aufgesetzt und damals habe ich mich über den flotten Download gefreut. Es hat also mal funktioniert. Für die DNS über den Raspi habe ich auch etwas in der Unitymedia ConnectBox eingestellt. Was genau muss ich mal in meinen Unterlagen suchen. Ggf. deaktiviere ich dies dann auch mal. Seltsam ist es aber, dass der Download vom älteren netcup TEST-Server performant läuft.

Ein weiterer Unterschied ist, dass ich auf dem PROD-Server ein fail2ban laufen habe, auf dem TEST-Server aber nicht. Die Services schalte ich beim TEST-Server nur ein, wenn ich sie brauche. Den fail2ban hatte ich auf dem PROD-Server auch schon deaktiviert. Gleiches Ergebnis, langsamer Download, Upload ok.

IP

PROD-Server und TEST-Server sind beide auf IPv4 im SCP | Netzwerk eingestellt.

Festplatten-Treiber

PROD-Server steht im SCP | Medien | Festplatte | Treiber auf VIRTIO und TEST-Server auf SCSI, also unterschiedlich. Warum dies so ist weiß ich nicht. Ich habe da nichts absichtlich geändert.

Danke fürs kümmern.

Hallo zusammen,

seit Tagen treibt mich ein Thema um, dass ich nicht in den Griff bekomme.

Ich habe zwei Server bei netcup. PROD: VPS 1000 G10 12M, TEST: VPS 1000 G9 12M. Beide sind ähnlich aufgesetzt, eine docker-compose Umgebung für den Betrieb von ein paar wenig genutzten privaten Dienste, wie Mailu E-Mail Server, Nextcloud, eine kleine Weppage, MariaDB, phpMyAdmin. Alles läuft stabil und ich habe mich seit Wochen nicht mehr groß drum gekümmert.

PROD-Server für den realen Betrieb. TEST-Server fürs testen und ausprobieren und Übernahme dann auf PROD-Server.

Die Tage ist mir aber aufgefallen, dass der Download vom PROD-Server zu meinem Home-Environment (ISP Unitymedia/Vodafone, 250Mbit/s Download, 12 Mbit/s Upload) sehr langsam ist, ca 300KB/s.

Dies aber nur vom PROD-Server! Alle anderen Download-Speeds (vom TEST-Server, Linux Image von Ubuntuusers.de, etc.) sind ok und ich kann bis max. ca. 25MB/s runterladen.

Dies kann ich auf verschiedenen Clients (Fedora Desktop, iPhone, Tablet, Notebook) in meiner HOME-Umgebung reproduzieren. Wechsele ich zu einem WLAN Hotspot über iPhone (Telekom.de 5G) ist auch der Download vom PROD-Server sofort ok, ca. 5MB/s. Download vom Büro-Laptop über Nextcloud vom PROD-Server ist auch maximal.

Download-Speed prüfe ich gegen den PROD-Server mit scp, FileZilla und Daten aus der Nextcloud, bei allen ist der Download-Speed ca. 300KB/s für den PROD-Server, aber nur im HOME-Environment und nur beim PROD-Server!

Ich habe auch schon alles abgeschaltet und es auf mein Desktop-Rechner mit Fedora zu isolieren. PROD-Server und ISP Router habe ich auch rebootet.

Ich habe mal mit yabs auf dem PROD-Server geprüft:

curl -sL yabs.sh | bash -s -- -fg
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2022-12-29                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #


Do 26. Jan 16:58:36 CET 2023


Basic System Information:
---------------------------------
Uptime     : 1 days, 22 hours, 5 minutes
Processor  : QEMU Virtual CPU version 2.5+
CPU cores  : 6 @ 1996.248 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM        : 7.8 GiB
Swap       : 0.0 KiB
Disk       : 157.3 GiB
Distro     : Ubuntu 20.04.5 LTS
Kernel     : 5.4.0-137-generic


iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping
-----           | -----                     | ----            | ----            | ----
Clouvider       | London, UK (10G)          | 900 Mbits/sec   | 911 Mbits/sec   | 22.0 ms
Scaleway        | Paris, FR (10G)           | 947 Mbits/sec   | busy            | 23.5 ms
NovoServe       | North Holland, NL (40G)   | 984 Mbits/sec   | 951 Mbits/sec   | 10.5 ms
Uztelecom       | Tashkent, UZ (10G)        | 427 Mbits/sec   | 297 Mbits/sec   | 180 ms
Clouvider       | NYC, NY, US (10G)         | 354 Mbits/sec   | 246 Mbits/sec   | 99.7 ms
Clouvider       | Dallas, TX, US (10G)      | 233 Mbits/sec   | 134 Mbits/sec   | 127 ms
Clouvider       | Los Angeles, CA, US (10G) | 214 Mbits/sec   | 169 Mbits/sec   | 148 ms


iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping
-----           | -----                     | ----            | ----            | ----
Clouvider       | London, UK (10G)          | 879 Mbits/sec   | 860 Mbits/sec   | 22.0 ms
Scaleway        | Paris, FR (10G)           | busy            | 785 Mbits/sec   | 35.2 ms
NovoServe       | North Holland, NL (40G)   | 963 Mbits/sec   | 937 Mbits/sec   | 10.5 ms
Uztelecom       | Tashkent, UZ (10G)        | 451 Mbits/sec   | 3.16 Mbits/sec  | 180 ms
Clouvider       | NYC, NY, US (10G)         | busy            | 411 Mbits/sec   | 99.7 ms
Clouvider       | Dallas, TX, US (10G)      | 347 Mbits/sec   | 377 Mbits/sec   | 127 ms
Clouvider       | Los Angeles, CA, US (10G) | 301 Mbits/sec   | busy            | 148 ms


YABS completed in 6 min 20 sec

Aus meiner laienhaften Sicht, sieht dies ok aus, so dass ich erstmal auf einen weiteren Test im Rettungssystem verzichtet habe.

Mit mtr habe ich dann weiter auf meinen Fedora Client gegenüber dem PROD-Server geprüft.

sudo ./mtr PROD-Server
Packets               Pings
Host                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1. _gateway              95.5%    23    2.2   2.2   2.2   2.2   0.0
2. (waiting for reply)
3. ip-081-210-xx         0.0%    23   11.2  14.6   9.7  40.5   8.6
4. 145.xxx               0.0%    22   14.9  17.7  14.0  31.9   4.0
5. 145.xxx               0.0%    22   22.7  20.4  14.0  48.3   8.5
6. ae1-0.xxx             0.0%    22   18.3  21.2  16.7  34.0   5.4
7. 94.xxx                0.0%    22   17.9  24.3  17.1  88.8  15.4
8. 46.xxx                0.0%    22   17.6  22.5  17.0  63.1  10.1
9. PROD-Server           0.0%    22   17.8  20.1  15.3  40.7   5.5

Hier bin ich zu sehr Laie um dies zu interpretieren. Mich wundern aber die Verluste bei _gateway. Und (waiting for reply) hat keine Ausgabe.

Scheinbar verstehen sie die beiden IPs nicht, vom PROD-Server zum ISP und nur für den Download!

Für jede Hilfe bin ich dankbar.

Toto12

I had the same problem yesterday night. The shown passwd was not accepted. A good guy from hackint - webirc gave me the tip to change the password in VNC by passwd root. This was the trick! After systemctl restart ssh in VNC, login via ssh with the new password was then possible from Fedora client.

So - nach dem die DNS Propagierung über 3 Tage gedauert hatte (mit 2 Eingriffe des Support in die Nameserver) ging dann Anpassung mit den Docker Containern recht flott über die Bühne. Und wollen wir mal schauen, wie es nun im operativen Betrieb weitergeht ...

Danke an alle Unterstützer.

Ich habe nun den Auth-Code vom aktuellen Provider erhalten. Soweit so gut ...

Ich habe bisher verstanden:

• Ich bestelle/wechsele die Domäne hier bei netcup
• Ich gebe dabei den Auth Code und die DNS Einträge für den neuen Server hier bei netcup ein
• Die DNS Einträge werden dann automatisch angepasst
• Die SSL Zertifikate vom aktuellen Server (alter Provider) bleiben bestehen und laufen dann irgendwann aus

Soll ich vorher die Einträge von meiner Test-Domäne (auch von netcup), die auf den neuen netcup Server zeigen, löschen? Weil diese Einträge trage ich ja bei der Bestellung/Wechsel ein.