Beiträge von frank_m
-
-
Seit 17 Uhr geht wieder irgendwas schief:
Ping von zu Hause zum Server ist bei mir wieder über 30 ms. Ein Trace geht über Amsterdam und von da direkt nach Nürnberg - ohne Hop in Frankfurt. Den Hop in Frankfurt hatte ich sonst immer, egal, ob ich über Düsseldorf oder Amsterdam geroutet wurde.
-
Untersagt sind insbesondere folgende Handlungen:
massenhafter Versand von Emails
Wo liegt die Defintion von massenhaft?
Das Problem ist, dass nicht der Versand kritisch ist, sondern der Empfang. Das lässt sich allerdings noch schwerer in irgendwelche AGBs packen.
-
Nehme mal an nur 1 Postfach pro M365 Benutzer.
Ja. Dazu hast du natürlich die Möglichkeit, mit freigegebenen Postfächern zu arbeiten, aber auch dafür benötigst du einen der Family Accounts, um den Zugriff zu realisieren. Freigegebene Postfächer sind keine unabhängigen Postfächer.
-
An LXD Container with limited ressources could be a way:
https://www.maketecheasier.com/limit-lxd-containers-resources/
-
Es gibt Alternativen, z.B. ifconfig, die aber vor allem mit mehreren Adressen auf dem Interface so ihre Schwierigkeiten haben.
Wenn es wirklich so ist, wie du beschreibst (also dass sich nur die link-lokale Adresse ändert), dann gibt es ein größeres Problem in deiner Installation. Denn, wie gesagt, hat die fe80 Adresse nichts mit dem zusätzlich gerouteten IPv6 Netz zu tun. Außerdem widerspricht es drastisch der Dokumentation deines Systems, die deutlich sagt, dass sich diese Einstellung auf die öffentliche IPv6 auswirkt.
Ich könnte mir eine Erklärung mit der fe80 Adresse und dem mitgelieferten IPv6 Netz an den Haaren herbeiziehen, aber das wäre arg konstruiert. Das Default Gateway bei netcup ist ja fe80::1 und liegt im link-lokalen Netz, da könnte man sich jetzt was kontruieren. Aber dann würde es auch den Ping auf die IPv6 des mitgelieferten Netzes negativ beeinflussen, und der ist ja stabil, wie du sagst. Von daher scheidet das aus.
Lange Rede, kurzer Sinn: Dein System verhält sich nicht nachvollziehbar und anders, als andere Systeme auf netcup Servern und als es die Dokumentation erwarten lassen würde. Sowas würde mich nervös machen, da man die eigentliche Ursache für das Problem nicht kennt. Sowas holt einen erfahrungsgemäß wieder ein, und zwar immer dann, wenn man es nicht gebrauchen kann.
-
Nun schaue ich mir ens3 an.
Wie hast du dir das angesehen?
-
Ja, hochladen geht. Bedenke, dass es keine nested virtualization gibt. Du kannst also nur Container verwenden.
-
Ich verstehe nicht was du meinst. Was ist ein "Default Image" von netcup?
Ich meine die Installationsimages von netcup. Wenn du da eigene Wege gehst, musst du natürlich selber dafür sorgen, dass alle Voraussetzungen für einen stabilen Betrieb gegeben sind. Daran ist es offensichtlich gescheitert.
Natürlich muss mein Interface eine public IPv6 Adresse haben. So ist mein Server ja auch eingerichtet.
Nein, er muss nicht eine, sondern eine ganz spezielle public IPv6 haben. Das ist der entscheidende Punkt. Es muss exakt die aus dem SCP sein, die als Routing Endpoint für das zusätzliche IPv6 angegeben ist. Die ist auch nicht änderbar, die ist seitens netcup fest vorgegeben, und es ist die mit deinem IPv6 Prefix und der EUI64 Host ID deines Servers.
Bei der Diskussion um stable-privacy und eui64 ging es lediglich um die link-local Adresse (also die fe80:...).
Nein, geht es nicht. Es geht um die öffentliche IP. Die link-lokale ist in diesem Zusammenhang völlig egal. Damit die link-lokale Adresse nicht mit EUI64 gebildet wird, müssen Kernel oder sysctl Parameter geändert werden. Mir wäre keine Distribution bekannt, wo das standardmäßig gesetzt wird. Ist aber in diesem Fall auch völlig egal.
Diese Adresse wird ja eh nicht geroutet sondern ist nur für die "neigbors" sichtbar.
Eben. Es macht doch gar keinen Sinn, für eine link-lokale Adresse irgendwelche Privacy Extensions zu aktivieren, da Pakete mit dieser Adresse das lokale Netz ja nie verlassen - und im lokalen Netz ist die MAC ja eh bekannt.
Die Router von netcup sollen den Traffic zu meiner statitschen IPv6 Adresse routen (also der 2003:4000:...). So ist es ja auch im Netzwerkbereich vom servicecontrolpanel eingerichtet.
Eben. Diese Einstellungen im networkmanager (oder wo auch immer) beziehen sich auf jeden Fall auch auf die öffentliche IP, die dem Interface zugewiesen wird. Schau dir einfach die öffentliche IP auf deinem Interface an, wenn du die Einstellung veränderst. Und dann vergleiche sie mit dem Routing-Ziel für das zusätzliche IPv6 Netz im SCP, das du selber hier erwähnst. Klingelts jetzt?
Mein Problem wurde nun dadurch gelöst, dass die link-local Adresse statt stable-privacy nun eui64 ist. Das hat ja nichts mit der statischen public IP zu tun.
Erkennst du nun den Widerspruch dieser Aussage, wenn du es mit deinen obigen Aussagen vergleichst? Du schreibst selber, dass das Routing Ziel die öffentliche Adresse ist, und dann soll eine Änderung der link-lokalen Adresse eine Änderung bringen?
Da ich meine statische IPv6 Adresse nach SLAAC aufgebaut (also gemäß der MAC Adresse) frage ich mich auch: was genau hat das Problem nun gelöst?
Der Satz ist ja auch schon ein Widerspruch in sich. SLAAC ist ein Mechanismus für dynamische Adressen, nicht für statische. Den einzigen Einfluss, den du auf deine statische Adresse haben kannst, ist die Host-ID. Die kannst du selber festlegen, aber die ist fest vorgegeben für das Routing Ziel, nämlich eine Host-ID nach EUI64.
Wenn du mich fragst, ist Folgendes passiert: Du hast wahrscheinlich irgendwo eine statische IPv6 gesetzt, aber gleichzeitig im networkmanager oder sonstwo die Einstellung "stable-privacy" aktiv gehabt. Damit hattest du eine dymaische öffentliche IP auf dem Interface, die nicht zum Routing Ziel des IPv6 Netzes passte.
Nun hast du die stable-privacy Einstellung geändert, deine dynamische Adresse ist nun zufällig identisch mit der statischen Adresse, und das Routing Ziel bleibt stabil. Die link-lokale Adresse hat damit gar nichts zu tun, und ich wage auch zu bezweifeln, dass sie sich überhaupt geändert hat.
Ich an deiner Stelle würde die gesamte dynamischen Adresstools deaktivieren. Server leben davon, dass sie statische Adressen haben, damit sich das Ziel von Nameserver-Einträgen und Routing Regeln nicht plötzlich ändert. Da haben solche Tools einfach nichts verloren.
-
Aber was macht netcup da?
Also wenn man die Default Images von netcup installiert, dann ist die IPv6 auf dem internen Interface genau so gesetzt, wie es erforderlich ist. Wenn das bei dir nicht der Fall war, würde ich eher fragen: Was machst du denn da?
Und jetzt das hier: stable-privacy ist die Default Einstellung für IPv6.
Sorry, nein. Die Default Einstellung auf einem Server ist eine statische IPv6. Da haben stable-privacy oder sonstwelche dynamischen Adresstools absolut gar nichts verloren! Lies dir noch mal meinen Satz von oben durch: "Diese Adresse muss statisch fest auf dem primären Interface eingestellt sein - ohne Schnickschnack, ohne irgendwelche RA Spielereien oder sonstwas."
Dass mir nicht klar ist, warum stable-privacy hier "unstable" ist brauche ich wohl nicht extra zu erwähnen.
Die Frage ist jetzt hoffentlich nicht dein Ernst, oder? Du hast nicht den Hauch einer Ahnung, warum du diese spezifische Adresse brauchst? Wo soll deiner Meinung nach das zusätzliche IPv6 Netz denn hingeroutet werden? Sollen die Router von netcup hellsehen?
-
Wie sieht der genaue DNS Eintrag aus, wenn ich von meiner Subdomain auf die IPv6 meines Internetanschlusses verweise? Könnte ich hier auch auf einen bestimmten Port verweisen?
Auf einen bestimmten Port zu verweisen, ist per DNS üblicherweise nicht möglich. Es gibt srv Einträge, aber die müssen von der adressierten Anwendung explizit unterstützt werden.
Bei der "IPv6 des Internetanschlusses" musst du vorsichtig sein, denn dein Anschluss hat viele IPv6 Adressen. Deiner Beschreibung zufolge willst du hier die IPv6 deines NAS verwenden (das ist NICHT die der Fritzbox und auch NICHT diejenige, die die Fritzbox per dyndns meldet!).
-
Die fe80:: Adresse hat im hinteren Teil nicht die 64 Bit meiner Host IP. Letztere habe ich gemäß SLAAC nach der MAC Adresse aufgebaut. Die Loal-Link Adresse ist dagegen nicht nach SLAAC aufgebaut. Das ist allerdings auf meinem PC genauso. Die wird wohl automatisch vergeben.
Entscheidend ist folgendes: das Ziel für das geroutete Netz ist fest vorgegeben. Diese Adresse muss statisch fest auf dem primären Interface eingestellt sein - ohne Schnickschnack, ohne irgendwelche RA Spielereien oder sonstwas. Wenn da irgendwas an der Adresse rumfummelt, dann würde das zuverlässig deine Probleme erklären.
Hast du die Verbindung auch mal anders als per Ping getestet?
-
net.ipv6.conf.all.accept_ra = 2
Warum steht das auf 2? Also RAs akzeptieren trotz IP forwarding? Und das für alle Interfaces?
-
Von wo pingst du denn? Kannst du mal mit Hilfe eines Traceroutes herausfinden, wo die Pakete verloren gehen?
Da das Subnetz ja direkt auf die standardmäßige IPv6 deines Servers geroutet wird, vermute ich stark ein Problem auf deinem Server. Beinhaltet die Firewall Regeln für Pings? Vielleicht mit limit oder burst Optionen?
Wenn ich aber auf dem Server einen Dauerping auf die IPv6 des Google DNS setze und laufen lasse dann läuft mein ping weiter.
Pingst du vom Host oder von einer VM? Sprich: ist die Absenderadresse deine standardmäßige IPv6 oder eine IP aus dem gerouteten Subnetz?
Ansonsten ist es Zeit, mittels tcpdump Paketmittschnitte zu erzeugen und zu analysieren, wo die Pakete ankommen.
-
Ich glaube, die CPU Sicherheitslücken Spectre und Co haben damals eine Rolle gespielt. Windows 11 sortiert all diejenigen CPUs aus, die davon maßgeblich betroffen waren und aufwendige Workarounds brauchten. Damit wollte MS in Win11 wohl nichts mehr zu tun haben.
-
Vielleicht ein EFI/Bios Problem? Welche Variante war auf der originalen HW aktiv, welche jetzt in der VM?
-
Die Domain lässt sich hierüber über IPv6 anpingen: http://www.ipv6now.com.au/pingme.php
Und was passiert dann im tcpdump?
Die IP-Adresse, die man oben sieht, lässt sich nicht anpingen, und das ist offenbar die einzige auf deinem Server. Welche Adresse verbirgt sich hinter der Domain?
Weil es ja nur ein Framework für iptables ist.
Bist du sicher, dass du iptables nutzt? Es könnte ja auch nftables sein.
Ich bekomme den Eindruck, dass die IPv6 Pakete den Server gar nicht verlassen. Das musst du auf einem anderen IPv6 tauglichen Host verifizieren.
-
fe80::1 ist die Adresse des Default-Gateways. Definitiv keine eigene Adresse.
Richtig, aber offenbar hast du meine Intention nicht verstanden.
Wenn du fe80::1 anpingst, dann wird die Absender-Adresse in diesem Ping Paket die link-lokale Adresse des entsprechenden Interfaces sein. Das ist ebenso die Adresse, an die die Ping-Antworten von fe80::1 zurückgesendet werden.
Wenn du aber ein Paket an einen öffentlichen Webserver sendest, dann wird die Absenderadresse die primäre öffentliche Adresse des entsprechenden Interfaces sein. Das Defaultgateway kann ja trotzdem fe80::1 sein, es geht ja nur darum, zu wissen, an welche MAC Adresse das Paket im ersten Hop geleitet wird. Die Antworten des Webservers werden an diese öffentliche Adresse zurückgesendet (wenn sie den Server erreicht haben, was wir nicht wissen) und landen damit in völlig anderen Firewall Regeln, als vorher die Ping Pakete.
Fazit: Ein Ping auf eine link-lokale Gateway Adresse eignet sich nicht, um die generelle IPv6 Funktionalität eines Servers oder die Firewall zu testen. Auf keinen Fall ist der Schluss zulässig "Der Ping auf fe80::1 geht, also blockt die Firewall keine eingehenden IPv6 Pakete".
Ausserdem haette das "tcpdump" die Antwortpakete vom Webserver gezeigt. Tcpdump greift die Pakete vor der Firewall ab.
Auch richtig. Aber da sieht man halt auch, dass nur 30 von 41 Paketen gecaptured wurden. Außerdem wissen wir nicht, was von den ausgehenden Paketen den Server erreicht hat.
Mich würde immer noch interessieren, ob da wirklich tausende ufw Regeln als Blacklist verwendet werden. So oder so halte ich das für eine schlechte Idee. Wie gesagt, ob es ursächlich ist, müsste man herausfinden, aber bei der Ineffizienz, die das erzeugt, halte ich es für denkbar, dass es nachhaltig Einfluss auf die gesamte Kommunikation des Servers nimmt.
Darüber hinaus muss man Tests mit IPv6 Gegenstellen machen, auf denen man vergleichbare Messungen machen kann, um zu analysieren, was konkret da ankommt. Nicht zuletzt muss man dann auch Pakete von außen an den Server senden, um auch da zu sehen, was ankommt.
-
Da das Ping auf fe80::1 funktioniert, wuerde ich die Firewall ausschliessen.
Ähh, Nein. Das Ziel der Ping-Antworten von fe80::1 ist voraussichtlich die eigene link-lokale Adresse. Der Inhalt von Firewall-Regeln ist üblicherweise die eigene Public Adresse. Das eine kann wunderbar funktionieren, während das andere komplett geblockt wird.
Gerade die Schwankungen im Ping Result auf fe80::1 zeigen mir, dass da was faul ist. Ich vermute, diese tausenden Zeilen spielen da eine Rolle. Ob die auch ursächlich für das Gesamtproblem sind, kann ich noch nicht sagen.
Ist 50-cloud-init.cfg die einzige Datei in /etc/network/interfaces.d/?
-
Ob die Schnittstelle eth0 oder ens33 heißt, ist ja nur eine Frage der Kernel Parameter, die man beim Booten mit auf den Weg gibt. Wichtig ist, dass der Rest der Konfiguration dazu passt.
Oben die ufw Ausgabe verwirrt mich. Du hast nicht wirklich tausende IP-Adressen als direkte Regel im ufw Framework, oder?
Das ist nicht empfehlenswert, weil sehr ineffizient. Wenn man solche Blacklisten pflegen will, dann lieber auf ipset setzen.Braucht man bei ufw nichts in Richtung RELATED/ESTABLISHED?
