Beiträge von frank_m

Nö.

root@servXYZ:~# iperf3 -c speedtest.wtnet.de -p 5200 -4
Connecting to host speedtest.wtnet.de, port 5200
[  5] local 46.38.X.Y port 53024 connected to 213.209.106.95 port 5200
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   582 MBytes  4.88 Gbits/sec  3441   6.47 MBytes
[  5]   1.00-2.00   sec   246 MBytes  2.07 Gbits/sec  3732   2.35 MBytes
[  5]   2.00-3.00   sec   235 MBytes  1.97 Gbits/sec    0   2.46 MBytes
[  5]   3.00-4.00   sec   245 MBytes  2.06 Gbits/sec    0   2.54 MBytes
[  5]   4.00-5.00   sec   249 MBytes  2.09 Gbits/sec    0   2.61 MBytes
[  5]   5.00-6.00   sec   260 MBytes  2.18 Gbits/sec    0   2.65 MBytes
[  5]   6.00-7.00   sec   261 MBytes  2.19 Gbits/sec    0   2.68 MBytes
[  5]   7.00-8.00   sec   265 MBytes  2.22 Gbits/sec    0   2.72 MBytes
[  5]   8.00-9.00   sec   270 MBytes  2.26 Gbits/sec    0   2.79 MBytes
[  5]   9.00-10.00  sec   279 MBytes  2.34 Gbits/sec    0   2.87 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.82 GBytes  2.43 Gbits/sec  7173             sender
[  5]   0.00-10.04  sec  2.81 GBytes  2.40 Gbits/sec                  receiver

Und unsere Server sind im gleichen Subnetz, von daher gehe ich davon aus, dass sie über den gleichen Router gehen.

Das ist Symptome bekämpfen, und nicht Ursachen. Das Kernproblem bleibt.

Zitat von Commerzpunk

Zur Zeit habe ich auf meinem Unraid, auf dem die Dienste alle als Docker Container laufen, kein IPV6 aktiviert, das müsste ich wahrscheinlich als Erstes tun, damit der Servers selbst ne IPv6 bekommt?

Das oder den Nameserver selber machen fürs LAN.

Zitat von Commerzpunk

Die Docker Container laufen alle im Bridge-Modus, das heißt sie haben alle keine eigene IP(4) Adresse in meinem Netz, sondern nur eine Übersetzung von innen nach außen, also in der Regel sowas wie Port 80 im Container nach außen auf 8081 auf die IP(4) des physischen Unraid-Servers.

Aus deiner Beschreibung hätte ich geschlossen, dass es gerade nicht der Bridge Modus ist. Über eine Bridge haben alle Container Zugang zum Heimnetz. Über die IP des Hosts erfolgt der Zugriff, wenn NAT im Spiel ist (auch wenn lokal für die Container auch eine Bridge zum Einsatz kommen kann, aber ohne Integration des Host-Netzwerkes).

Zitat von Commerzpunk

Muss ich daran was ändern?

Nein. Ggf. musst du es auch für IPv6 machen.

Zitat von Commerzpunk

Dort kommt bisher die externe Anfrage auf die 443 per Portweiterleitung von der Fitzbox an und dort wird dann, je nachdem über welche Subdomain die Anfrage kam, leitet der Reverse Proxy dann die Anfrage an die interne auf die Server Ip mit dem richtigen Port weiter. Wie wird das mit IPv6 eingerichtet?

Genau so.

Zitat von Commerzpunk

Für mich scheint die Lösung zu sein, dafür zu sorgen, dass der Reverse Proxy Container eine eigene IPv6 Adresse in meinem Netz bekommt, ohne Bridge, und diese IPv6 könnte ich dann ja fest in das DynDNS Update eintragen, die wird sich ja nicht mehr ändern. Ab da wird die Unterverteilung ja normal weiterlaufen, könnte ich auch auf IPv4 lassen, oder?

Könnte sein. Keine Ahnung, ob ein Proxy von IPv4 nach IPv6 übersetzen kann. Kann aber sein.

Zitat von fibis

Ich möchte aber gerne diese IP auch für ausgehenden Traffic nutzen, sodass diese IP z.B. bei der Nutzung eines VPN genutzt wird.

Soll die IP dann alleinig ausgehend benutzt werden? Dann siehe den Thread oben. Willst du gezielt einzelne Dienste über die eine oder andere IP leiten, dann musst du mit policy-based Routing arbeiten.

Software Updates würden nicht so konstant verlaufen. Ich denke, du musst das Filesystem im Auge behalten und monitoren. Fang auf oberster Ebene an ("/") und schau dir mit du die Ordnergröße an.

du / --max-depth=1

z.B. stündlich. Und wenn du siehst, dass die Auslastung eines Verzeichnisses steigt, z.B. /var/, dann schaust du dir in der Folge das an

du /var --max-depth=1

Bis du dem Übeltäter identifiziert hast.

Den IPv6 DNS Eintrag korrigieren. Bedenke: bei IPv6 funktionieren Portweiterleitungen nicht, wie bei IPv4. Während du bei IPv4 auf den Router zugreifst, und der leitet das Paket an den Server weiter, musst du bei IPv6 direkt auf die Server IP zugreifen. Heißt: Der AAAA Eintrag von sub.domain.com muss auf die Server-IPv6-Adresse zeigen, nicht auf den Router. Zeigt sie auf den Router, bekommst du natürlich auch die Webseite des Routers angezeigt.

Also muss entweder der Server selber die dyndns Aktualisierung vornehmen, oder du aktualisierst vom Router aus nur das Prefix und lässt die Interface-ID statisch (und nimmst die des Servers, nicht die des Routers).

Übrigens: Dass es von außen funktioniert, ist Glückssache. Du hast offenbar eine IPv4 Verbindung von außen benutzt, da klappt die Portweiterleitung. Greifst du per IPv6 von außen zu, geht es auch da schief.

Ich dachte, die Anfragen laufen inzwischen wieder ins Leere?

https://www.heise.de/news/Fritz-box-Domain-aus-dem-Verkehr-gezogen-9647776.html

Ich hatte ja anfänglich den Verdacht, dass über die Seite die Sicherheitslücke aus September 23 ausgenutzt wird.

https://www.heise.de/hintergrund/Fritzbox-Sicherheitsleck-analysiert-Risiken-und-Gegenmassnahmen-9323225.html

Wenn man die Sorglosigkeit vieler Nutzer sieht, hätte sich das vermutlich echt gelohnt ("Wir machen ein Downgrade auf die alte Version, weil irgendwas ist anders als vorher").

Zitat von Commerzpunk

Rufe ich das nun im Heimnetz auf, lande ich auf der Anmeldeseite der Fritzbox und nicht auf der Nextcloud.

Das nennt sich NAT Loopback, wenn du aus deinem Heimnetz deine eigene öffentliche IP aufrufst. Jeder Router verhält sich da anders, einige blocken es ganz, andere lassen nur den Zugriff auf lokale Router-Dienste zu. Prinzipiell kann das eine Sicherheitslücke sein, deshalb wird der Zugriff eingeschränkt. Du könntest versuchen, den internen HTTPS Server der Box auf einen anderen Port zu verlegen. Aber ich glaube, das geht nur für den externen Zugriff, nicht intern. Einen Versuch ist es wert.

Die einzige sichere Möglichkeit ist ein eigener, interner DNS Server, der die Abfrage auffängt und auf die interne IP umleitet. Oder alles auf IPv6 umstellen, das würde auch helfen.

Du musst die DNS Einträge für deine Domain einrichten und auf deinen Server zeigen lassen:

https://helpcenter.netcup.com/de/wiki/domain/dns-einstellungen

Nebenfrage: Wie hast du deinen Server gegen Hacker-Attacken abgesichert? Immer dran denken: Bei Netcup gibt es keine Firewall auf Systemebene, dafür bist du ganz allein verantwortlich, und standardmäßig ist so ein Windows oder Linux offen wie ein Scheunentor.

Ah, ok. Das erklärt es natürlich. Damit sind die Werte plausibel.

Ich finde einige Einträge trotzdem merkwürdig. 92 GB für STUN? Ein STUN Request bei VoIP Aufbau benötigt wenige 100 Byte. Wie viele Telefonate muss man führen, um auf 92 GB STUN zu kommen? 106 GB mit Lets Encrypt? Selbst wenn bei jeder Zertifikatsprüfung die Chain abgeklopft wird, aber 106 GB? Das müssen ja Milliarden Requests sein.

Zitat von Valkyrie

Einfach Wahnsinn, was da ständig für Video Streaming und so drauf geht

Wie misst du das? Ich frage, weil z.B. die Fritzbox ja zuweilen auch Bugs in der Firmware hatte, vor allem im Zusammenspiel mit der Paketbeschleunigung, die schon mal Faktor 3 aus den tatsächlichen Datenmengen machten.

Zitat von ThomasChr

Man kann natürlich auch vorsichtig versuchen den Fragesteller in die richtige Richtung zu schubsen und zu mehr lernen animieren…

Das hab ich ja ziemlich lange probiert am Anfang. Passiert ist wenig.

Zitat von Irrwisch

Die Frage ist auch berechtigt und über ufw und andere Programme die an iptables und nftables herumfummeln sind hier schon viele andere gestolpert (bin heimlicher Leser meistens).

Genau das ist der Punkt. Es ist für erfahrene Leute schon schwierig, einzuschätzen, was die Firewall nun durchlässt, und was nicht, wenn zahlreiche Container und Tools mit verschiedenen Frontends in den Regeln herumwühlen. Und wenn man dann nicht mal weiß, wie IP Routing funktioniert, um beurteilen zu können, wie die Pakete überhaupt durchs System fließen, dann ist es meines Erachtens unmöglich, den Server adäquat abzusichern.

Zitat von h725rk

Leider sehe ich aktuell keinen Mehrwertmehr dafür, da der Traffic von Docker durch die speziellen IPTables nach draußen unterbunden werden können.

Auch das kann man ja ändern.

Kein Verständnis habe ich für die Reaktion. Das ist dann wohl ein Fall von "kann die Wahrheit nicht vertragen". Aber wenn der Server dann gehackt wird und die IP auf einer Blacklist landet, leiden vor allem die anderen Netcup Kunden darunter, und das Geschrei ist groß. Das Forum ist voll davon, wir ihr alle wisst, und dann fragen sich wieder alle, warum die Leute ihre Server nicht absichern. Aber wenn dann ein konkreter Fall offenbar wird, sagt wieder niemand was. Hm.

Ich halte auch nichts davon, in Foren Schritt-für-Schritt Anleitungen zu geben. Zum einen ist der Lerneffekt gleich Null, zum anderen hilft das dann auch nur für diesen einen konkreten Fall. Ich schreibe immer, was zu tun ist, aber nicht wie. Damit hat der Fragesteller die Chance, sich die Grundlagen zu erarbeiten, und bei Anpassungen nicht wieder nachhaken zu müssen. Und andere Leser mit ähnlichen Problemen profitieren auch davon: Lesen, verstehen, adaptieren, umsetzen. Man kann es nicht oft genug wiederholen.

Zitat von h725rk

Ich lasse mich nicht als Lügner bezeichnen, nur weil ich von einer Software (Wireguard) mal keine Ahnung habe und Hilfe benötige.

Wenn du nur von Wireguard keine Ahnung hättest, dann wäre es ja nicht so schlimm. Aber es ist ja offensichtlich, dass du von IP, Routing und Firewalls keine Ahnung hast. Wie willst du dein System schützen, wenn du nicht weißt, welchen Weg die Datenpakete in dein System nehmen? Wie soll das gehen?

Du musst hier nicht antworten. Beantworte dir einfach nur ehrlich diese Frage abends vorm Spiegel, und dann beurteile selber, ob es eine gute Idee ist, einen vServer öffentlich am Netz zu betreiben, oder ob du nicht besser noch einige Monate mit einer VM zu Hause übst.

Zitat von h725rk

- Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

- Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?

Du administrierst einen vServer, der öffentlich aus dem Netz erreichbar ist. Wenn du das nicht weißt, dann ist das hier:

Zitat von h725rk

Zum Thema SSH.

Das ist abgesichert.

garantiert gelogen. Es nützt nichts, SSH abzusichern, wenn du dann hintenrum wieder haufenweise Lücken einbaust.

Zitat von h725rk

- Das mit dem NAT verstehe ich nicht, sind das die PostUp und PostDown Regeln und diese sollte ich löschen?

Ob du da alles löschen darfst, weiß ich nicht. Die NAT Regeln auf jeden Fall, aber dafür brauchst du vielleicht andere, die jetzt noch nicht drin sind. Anleitung lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.

Zitat von h725rk

- Was meinst du mit Default Routes im Client. Sind das die AllowedIPs?

Momentan steht die Default Route in deinen Allowed IPs. Das sollte für deinen Anwendungsfall aber nicht so sein. Grundlagen IP Routing.

Du solltest deine Configs vor dem Abspeichern immer auf Konsistenz prüfen. Zum Beispiel sieht man hier auf den ersten Blick, dass die "Address" in der Server Konfig ein Subnetz ist und keine Adresse. Das darf natürlich nicht sein und wird in der Folge auch nicht funktionieren. In der SSH Konfig hast du es hingegen richtig gemacht, womit auch direkt deutlich wird, dass die beiden nicht zusammen passen.

Und dann sind da immer noch NAT Regeln in der Server Konfig und die Default Route im Client. Beides ist Unsinn für deinen Anwendungsfall.

Wenn du SSH auf der öffentlichen Adresse lauschen lässt, solltest du einige Sicherheitsmaßnahmen ergreifen: Anderer Port (nicht 22), keine Anmeldung via Passwort, nur per Zertifikat, und fail2ban sollte sauber laufen. Dann musst du natürlich den Port in der Firewall freigeben.

Ja, aber nur der Server. Der VPN Client soll ja nicht über den Tunnel ins Internet gehen. Was du auf dem Server erreichen kannst, kannst du ja sehr einfach über die Allowed IPs und Firewallregeln beeinflussen.

Du solltest nur die Funktionen aktivieren und nur den Datenverkehr durchs VPN leiten, den du wirklich brauchst. Also wenn es nur um den Zugriff auf Docker geht, dann weg mit den NAT Regeln und der Defaultroute, dafür das Docker Netz in die Allowed IPs aufnehmen.

Zitat von h725rk

Gute Fragen, kann ich dir wirklich nicht beantworten. Ich habe für wireguard eine Anleitung verwendet.

Deshalb sage ich immer, nie eine Anleitung blind abtippen. Lesen, verstehen, auf die eigene Situation adaptieren, umsetzen.

Zitat von h725rk

Ich denke, ich muss wohl das ganze Konzept nochmal überarbeiten.

Das Konzept ist ok, die Umsetzung ist schlecht. In erster Linie solltest du den VPN Tunnel umbauen.