Beiträge von terence

Ich finde die Firewall auch gut und freue mich, dass meine "alten" Server sie jetzt auch haben!

Zitat von NaN

IPv6 ist so gut, dass man es sogar als einziges Protokoll verwenden kann, wenn man es mit NAT64 auf IPv4 übersetzt... Was haltet ihr von der neuen kaiserlichen Garderobe? Fantastisch, oder?

Mein Internetanschluß verwendet einen DS-Lite-Tunnel und hat daher nur eine öffentliche IPv6-Adresse. IPv4-Traffic muss also so oder so irgendwie übersetzt werden. Da bevorzuge ich NAT64 gegenüber AFTR+CGNAT.

Zitat von gem

Was verwendest Du?

Hatte ich noch vergessen: Alternativ zum eigenen NAT64-Gateway kann man natürlich auch eins von den öffentlichen verwenden, sofern man dem Anbieter vertraut. Dazu muss man einfach nur die entsprechenden DNS-Server eintragen, die für IPv4-only Domains dann IPv6-Adressen generieren, welche zum NAT64-Gateway führen.

Das sieht beispielsweise so aus:

# Ohne DNS64:
 ➤ host github.com
github.com has address 140.82.121.3

# Mit DNS64 von nat64.net
 ➤ host github.com 2a01:4f9:c010:3f02::1
github.com has address 140.82.121.4
github.com has IPv6 address 2a01:4f8:c2c:123f:64:5:8c52:7904
github.com has IPv6 address 2a00:1098:2b::1:8c52:7904
github.com has IPv6 address 2a01:4f9:c010:3f02:64:0:8c52:7904

Dies ist die Web-Seite: https://nat64.net

Dort gibt es auch eine Übersicht anderer Provider: https://nat64.net/public-providers

Zitat von gem

Was verwendest Du?

Das ist eine Standardinstallation von OpenBSD ohne weitere Drittsoftware. Läuft auf einem Piko G11s.
Meine Client-Rechner verbinden sich via Wireguard mit dem Server. NAT64 macht der Paketfilter pf und für DNS64 ist unbound zuständig.

Zitat von gem

... nur mal so als Datenpunkt... ich hatte eigentlich vor (testweise) für einige Zeit den Spieß umzudrehen und IPv6 only aus Client-Sicht zu betrachten.

Ich habe recht schnell (subjektiv) den Eindruck gewonnen, dass das Internet ohne CGNAT ziemlich zusammegeschrumpft ist...

Mir war nicht bewusst, wie viele - auch prominente - Dienste im Internet IPv4 only sind... vom Wetterbericht, über Banken, Versicherungen bis hin zu Steam & Co...

Ja, das ist ein spannendes Experiment.
Meine Rechner Zuhause laufen seit einem oder zwei Jahren IPv6-only. Das geht aber nur, weil ich bei netcup ein NAT64-Gateway aufgesetzt habe, damit ich IPv4-only-Seiten erreichen kann. YouTube hat zum Glück IPv6, so dass die Videos keinen Umweg nehmen müssen. Dito die Mediatheken von ZDF und ARD. Irgendwelche Applikationen, die fest verdrahtete IPv4-Adressen verwenden, sind mir noch nicht untergekommen, soll es aber geben. Das ist dann doof und sollte von den Entwicklern gefixt werden.

Zitat von sudoNoSleep

was gaebe es noch was nicht mehr gehen koennte?

Hier gibt's eine Liste dazu... https://whynoipv6.com/

Zitat von Fen

Ich werde den Serverbetreiber mal anschreiben und ihn darauf hinweisen. Zwar macht mir der Traffic in der Praxis nichts aus, anderen aber vielleicht schon, da er vermutlich auf das Trafficvolumen angerechnet wird.

Sollte sowas nicht eigentlich standardmäßig von netcup rausgefiltert werden? Ich finde es ja auch komisch, dass mein IPv6-only-Server IPv4-Traffic bekommt. Würde ich nun auch nicht unbedingt erwarten.

73 GB finde ich heftig. Laut KI ist das Audio:

Zitat

239.255.77.77:4100 carries audio stream traffic from Scream, an open-source Opus audio receiver and server used for low-latency audio over IP networks.

Scream sends Opus-encoded audio via UDP multicast to this group address (in the 239.0.0.0/8 organization-local multicast range) and default port 4010 (your 4100 may be custom). Receivers join the group to play live audio, like in remote desktop, gaming, or VoIP setups over LAN.

Ja, Brodcast und Multicast kommt auch beim Interface an, wenn es keine IP-Adresse zugewiesen hat.

Ok, dann gibt es also keine Doku mit Ausnahme der Schemata. Schade.

Laut Wiki soll es aktuell keine breaking changes mehr geben. Ist die Frage, ob das auch für Bugfixes gilt?

Wo findet man eigentlich die von Dir erwähnte Doku? Ich habe bisher nur die OAS gesehen und da steht bei den Operationen nicht viel an Beschreibung drin.

Ja, sehe ich auch so. Und es könnten theroetisch ja sicher auch mehrere Wartungsfenster gleichzeitig eingestellt werden, so dass ein Array am meisten Sinn macht.

Reverse DNS gibt mir für zwei Adressen beispielsweise v22xxx.goodsrv.de bzw. v22xxx.hotsrv.de zurück und bei einer anderen eine externe Domain. Sieht also nach Kundenservern aus.

Vermutlich "nur" ein Bug.
Wenn ich es richtig gesehen habe, ist in der OAS auch nicht definiert, dass null als Wert für die beiden Properties erlaubt ist. Das dürfte so dann also auch nicht zurückgegeben werden, sondern es müsste immer ein Timestamp drinstehen.

Die Quelladressen scheinen auch alle aus demselben /22-Subnetz zu kommen, was ich bisher so gesehen habe.

Zitat von worker

Sind das Adressen von NetCup Servern?

Sieht wohl so aus, daß diese wie dein Server hinter der Firewall sind, und nicht geblockt werden.

Das wäre natürlich eine plausible Erklärung. Ich hatte bisher angenommen, dass die Firewall direkt vor meiner Kiste sitzt.

Zitat von johnassel

Also bei mir blockiert die Firewall auch Traffic von Netcup-Servern. 🤔

Auch Multicast?

Ja, sieht so aus, als ob das IP-Adressen von netcup sind.

Als Protokolle kann man nur TCP, UDP, ICMP und ICMPV6 auswählen.

Ich bekomme z. B. xx.xx.xx.xx.65532 > 224.0.0.252.5355: udp, wenn ich tcpdump -nettt -i vio0 udp aufrufe.

Da bei meinem IPv6-only-Piko IPv4-Multicast-Traffic (UDP) ankommt, habe ich versucht, diesen mit der neuen netcup-Firewall zu blockieren. Bisher aber leider vergeblich.

Mit folgendem Test-Regelwerk kommt der Traffic immer noch an, obwohl doch eigentlich sämtlicher eingehender UDP-Traffic blockiert werden sollte, oder nicht?

Ich habe auch schon versucht, konkrete IPv4-Adressen anzugeben, die mir tcpdump ausgibt und auch komplette Adressbereiche, aber der Multicast-Traffic kommt immer durch.

Genauso verhält sich auch mit einem anderen Server, der eine IPv4-Adresse zugewiesen hat. UDP-Pakete, die ich direkt an diese IPv4-Adresse schicke, werden wie erwartet blockiert, aber die Multicast-Pakete laufen weiter munter rein.

Ich habe daher den Eindruck, dass man Multicast mit der Firewall nicht blockieren kann (im Wiki habe ich keinen Hinweis dazu gefunden). Oder habe ich noch irgendwo einen Fehler drin?

Zitat von andreas.

Ich habe mir mal die Preise der beiden Produkte RS 4000 G12 Pro und RS 4000 G12 Ultra des heutigen Deals genauer angeschaut.

Die KI rechnet das so:

Frage:

Wenn bei einem VPS-Provider ein Server mit 12 Kernen, 32 GB RAM und 2 TB SSD einen Preis von 31,63 Euro hat, wie teuer wäre dann einer mit 14 Kernen, 48 GB RAM und 2 TB SSD?

Antwort:

Zitat

Man kann das nur schätzen, weil der Anbieter seine Preise nicht zwingend linear nach Kernen/RAM staffelt. Eine einfache überschlägige Methode ist:

Ausgangsserver: 12 Kerne, 32 GB RAM → 31,63 €.

Proportional hochskalieren nach CPU und RAM:

Faktor CPU: 14/12 ≈ 1,1714/12 ≈ 1,17.

Faktor RAM: 48/32 = 1,548/32 = 1,5.

Nimmt man als grobe Annahme den Durchschnitt der beiden Faktoren (1,17+1,5)/2 ≈ 1,34, erhält man:

31,63€ × 1,34 ≈ 42,4€

Plausible Abschätzung: Ein Tarif mit 14 Kernen, 48 GB RAM und 2 TB SSD würde etwa rund 40–45 € pro Monat kosten, wenn der Anbieter annähernd proportional nach CPU/RAM skaliert.

Alles anzeigen

44,27€ / 31,63€ ergibt einen Faktor von ca. 1,4

Für den alten RSS-Link wurde eine Weiterleitung auf den neuen eingerichtet, aber mein Web-Browser hatte das gestern ignoriert genauso wie mein Feed-Reader.