Posts by MeisterYoda

Quote from lulatsch66

Wo bekommt man denn sonst noch virtuelle Systeme auf KVM-Basis mit dedizierten Cores? Wo Proxmox im Cluster funktioniert ... Ich kenne das sonst nur mit Hardware-basierten Maschinen.

Beim Sieger (Platz 1) des diesjährigen Host Tests in der Kategorie vServer (also virtuelle Root-Server).

Ich selbst habe schon dort hin umgezogen, da neben einer garantierten Bandbreite von 1 Gbit/s (mit Spike darüber) auch nested KVM (sprich VMX/SVM) für vernünftige full Virtualization ohne Aufpreis möglich ist, und es immer wieder extrem günstige Sonderangebote gibt.

Quote from mainziman

ich weiß nicht, aber irgendwie läuft das mit dem sprichwörtliche Betschuppen rund ums Dorf

traceroute von meinem 6in4gate in Wien weg zu einer IPv4 in Wien

Interessant, den VPS Anbieter kannte ich ja noch gar nicht

Reverse Lookup regelt

Quote from tab

Mein BF Server hat auch eine IPv4 aus diesem Subnetz. Steht aber laut Einstein mit Sicherheit nicht in Wien .

same

Quote from H6G

Ich war mal so frei. Habe eine Antwort bekommen:

Interessant hierzu wäre natürlich, ob "diese Änderung" RS G8, G9 (oder beides) und jeweils mit oder ohne VMX/SVM Flag betrifft.

Nachtrag: Übrigens ist es auch bei IPv4 falsch, alle ICMP zu blocken. Genau aus diesem Grund funktioniert zB. das Path MTU discovery nicht zuverlässig, weil es zu viele fehlerhaft konfigurierte Firewalls im Netz gibt....

Quote

# Permit useful IMCP packet types.

# Note: RFC 792 states that all hosts MUST respond to ICMP ECHO requests.

# Blocking these can make diagnosing of even simple faults much more tricky.

# Real security lies in locking down and hardening all services, not by hiding.

-A DOCKER-USER -p icmp --icmp-type 0 -m conntrack --ctstate NEW -j ACCEPT

-A DOCKER-USER -p icmp --icmp-type 3 -m conntrack --ctstate NEW -j ACCEPT

-A DOCKER-USER -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

-A DOCKER-USER -p icmp --icmp-type 11 -m conntrack --ctstate NEW -j ACCEPT

Display More

Quote from Ente-Dank

Hab gerade gelernt dass ipv6 ohne nd-* kram in der Firewall plötzlich kaputt ist, dinge über die man sie nie Gedanken macht solange man ipv4 only fährt..

Ja, man muss einen großen Bereich von ICMP zulassen. Habe mir mal die Mühe gemacht die Types, die man zulassen sollte, per RFC zu erarbeiten (gleiches gilt natürlich auch für die Forwarding chain):

Quote

# Permit needed ICMP packet types for IPv6 per RFC 4890.

-A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 3/0 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 4/1 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 4/2 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 130 -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 131 -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 132 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 137 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 143 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 151 -m limit --limit 1000/min -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 152 -m limit --limit 1000/min -j ACCEPT

-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 153 -m limit --limit 1000/min -j ACCEPT

-A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT

Display More

Quote from mainziman

Du sagtest ja was von Wohnheim und so; also ein Studentenheim; und hast Du bei IPv4 eine eigene od. bist Du da im NAT mit den anderen?

ich bin jetzt davon ausgegangen, dass bei IPv4 jeder seine eigene IPv4 hat aber bei IPv6 teilt ihr euch einen Prefix ...

mit 'Mist' bauen, etwas Phantasie; SPAM-Versand, Malware-Verbreitung - es muss nicht Absicht sein, kann auch unwissentlich geschehen;

Wir haben einen recht komplexen Anschluss, also im Prinzip beides. Grundsätzlich teilen sich alle Bewohner ausgehend einen Pool aus ca. 500 public IPv4 Adressen per CG-Nat, wir haben aber auch noch ein /30ger Netz anliegen für Serverhosting, unfiltered NAT etc. Das CG-Nat fängt nach außen gehende Portscans etc. durchaus ab. Spam Versand ist auch nicht möglich, da Port 25 geblockt ist.

Aber abgesehen davon: Der Kernaussage stimme ich halt nicht zu: Wer ein /48 Prefix blockt, kann auch ein /24ger IPv4 Prefix blocken.

Quote from mainziman

klar so ist es auch sinnvoll; und damit bringst Du mich auf das nächste nicht unproblematische;

man sperrt bei IPv6 keine einzelnen IPv6-Adressen sondern gleich ganze Prefixe;

und wenn da einer von euch Mist baut, ist der ganze Prefix gesperrt; findest das dann auch toll?

was meinst du konkret damit? Wie soll man "Mist" bauen, sodass man wo gesperrt wird? Außerdem - was ist der Unterschied zu IPv4? Da sperrst du halt nach der gleichen Logik die einzelne IP Adresse, das ist rein das gleiche.

Quote

und NAT ist kein Klimmzug, sondern hat seinen Snn;

und ehrlich würdest Du ein Unternehmen, z.B. eine Bank so konfigurieren,

dass jeder Client direkt vom Internet aus erreichbar ist?

NAT ist keine Firewall.

Quote

doch einiges davon muss man dem Standard anlasten, IPv6 ist aus Sicht heute - dem fast zu Ende gehenden Jahr 2021 - immer noch unvollständig;

und teilweise sogar fehlerhaft;

IPv6 ist nicht unvollständig oder fehlerhaft - die Umsetzung durch die Provider ist unvollständig oder fehlerhaft. Fehlerhaft bei dem Serverprovider mit den zwei einsen und unvollständig hier bei Netcup (mit Blick auf den Leitsatz: der Kunde sollte sich niemals eingeschränkt fühlen und über so Krücken wie NAT nachdenken müssen). Darüber hinaus haben sämtliche DSL Provider, inklusive des großen T IPv6 fehlerhaft implementiert: so etwas wie dynamische Prefixe ist erst der Ursprung allen Übels und war nie vorgesehen.

Wir beziehen im Wohnheim vom LRZ einen statischen /48 Prefix und können damit intern wunderbar und unbegrenzt arbeiten - so wie es sein sollte. Damit entfällt dann auch Murks wie NAT reflection etc.

Quote from whoami0501

Bei den Sachsen sind IPv4 Adressen an dedizierten Servern nun optional. Die Cloud soll bald nachziehen.

Ob Netcup auch bald nachzieht?

Imho sollte Netcup, bevor Energie in sowas gesteckt wird, erstmal IPv6 vollumfänglich ausrollen, damit es auch für komplexere Szenarios jenseits einem simplen 0815 Webserver Hosting nutzbar wird.

Sprich, Subnetze vernünftiger Größe anbieten.

Die erwähnte große Konkurrenz (und auch einige andere) machen es bereits vor.

Das fehlen, ist per default ja nicht installiert

Weil ich es gerade in einem anderen Thread gelesen habe: könnte hier auch der qemu-guest-agent eine Rolle spielen? (direkt auf der Proxmox VM). Der muss ja ggf. manuell nachinstalliert werden.

Quote from KB19

z.B. ECC-RAM wäre ein guter Grund (den gibt es in dieser Preisklasse bei dedizierter Hardware noch nicht).

Also ich hab neulich erst nen Server dort gesehen mit 2*480GB Datacenter SSD, 1G Standleitung, 64 GB DDR4 ECC RAM, 4 dedi Cores (8 threads) (2016er Xeon 8500er CPU-B) und das ganze für 35€

So genau lässt sich das in der Regel nicht messen. Das hängt vor allem davon ab, in welchen exakten Zeitintervallen die Spikes gemessen (Durschnitt genommen) werden.

Quote from voja

Ich habe den Container vor 2 Tagen auf Proxmox 6 (Kernel 5.4.128-1-pve) verschoben. Die Maschine hat inzwischen eine Uptime von 101 Tagen ohne Probleme.

Die Proxmox 7 VM hat seitdem der Container weg ist dreimal spontan neu gebootet. Die VM ist jetzt ansonsten Idle.

Ausschließlich bezogen auf Root-Server Gen9, oder?

Bei mir kams jetzt auch wieder, auf nem normalen Debian 10..

Quote from H6G

Mit Proxmox 6 habe ich die gleichen Probleme... - aber ein Commitment das Problem zu anzugehen seitens Netcup wäre echt nicht schlecht.

wobei ich ergänzen muss, ich rede hier nur von reinen Containerlösungen, sprich ohne VMX/SVM flag und ohne nested kvm. Ich glaube da gabs nur unter Proxmox 7 ein Problem, oder?

Ich mein es wäre ja schonmal ein Anfang, wenn Netcup sich dazu commiten könnte, dass das Problem definitiv bis Ende Q2 2022 durch ein Kernelupgrade behoben wird. So könnte man zB. weiterhin auf Proxmox 6.4 setzen, dessen Support 08/2022 ausläuft und dann auf 7.x upgraden. Aber so mit dem Tempo wie es aktuell läuft, bleibt wohl tatsächlich nur die Wahl eines anderen Providers bzw. direkt ein Dedi beim großen H.

[netcup] Claudia M. wäre so etwas möglich?

Quote from frank_m

- Warum betreibt man überhaupt den Server am heimischen DSL Anschluss und nicht im Rechenzentrum?

Dies kann Datenschutzgründe und/oder Storagegründe im TB Bereich haben, sprich P/L.

Quote from whoami0501

Das Problem sehe ich vor allem darin, wenn ich mal den Provider wechseln sollte. Die Telekom kann ich halt wenigstens bei einem Tarifwechsel solange ins Kreuz treten, dass ich das Prefix mitnehmen kann. Aber beim Providerwechsel geht das nicht.

Deswegen würde ich für heimische Serverdienste ein VPN (zB. Wireguard) zu einem Hoster/VPS/Rootserver aufsetzen, wo man ein vernünftiges /56 bekommt und sich dieses durchrouten kann. Dieses ist dann unabhängig vom heimischen Provider. zB. bei den Freunden einer der bekanntesten Skriptsprachen (dem diesjährigen Gewinner des Hosttests in der Kategorie VServer).