Beiträge von NieSommer

Ich denke das ist eine Glaubensfrage.

Viele Konzerne haben überhaupt kein Problem ihre Daten/Code z.B. bei Azure DevOps oder Github zu lassen.

Das ist aber in der Regel Dinge, die nicht streng vertraulich sind. Quellcode ist oft sensibel, aber eben selten vertraulich.

In dem Moment wo ich vertraulichkeit benötige, muss ich auf allen Dingen den Daumen haben. Das bremst Unternehmen erheblich, kann aber durchaus angebracht sein. Oft wird ein hybrider Anansatz gefahren, wo es für das "Tafelsilber" eine interne Lösung gibt, und für die normale Entwicklung eine Cloud-Lösung. Manchmal muss man sich auch fair die Frage stellen, ob das höhere Ausfallrisiko einer eigene Selbst-Hosting-Lösung nicht den größeren finanziellen Schaden bedeuten kann.

Manchmal ist der Grund für die Cloud auch einfach, dass man die eigenen Fachkräfte lieber am Produkt arbeiten lässt. Schließlich verdient ein normales Unternehmen kein Geld mit dem Betrieb von internen Diensten. Und Personal ist halt Mangelware. Übrigens hat man das gleiche Thema, wenn man hier einen Server mietet. Es ist halt der Server von jemand anderem...

Einem Prozessor als Gastsystem mitzuteilen, dass man einen erhöhten oder geringen Bedarf hat ist momentan nur rudimentär möglich.

In der Regel macht der Hypervisor, was er für richtig hält. Und die Gäste haben damit zu leben.

Es gibt aktuell erste Schritte den Gästen Möglichkeiten zu geben, den aktuellen echten Bedarf an den Hypervisor zu kommunizieren.

Da ist man aber, soweit ich weiß, noch bei vorausgehenden Arbeiten (Intel ist hier der Treiber des Themas in der Community).

Es wird noch lange dauern, bis Gastsysteme sinnvoll die dynamische Taktung beeinflussen können.

Das führt zur absurden Situation, dass der Stromverbrauch eines nativen OS auf moderner Hardware erheblich niedriger sein kann, als virtualisiert z.B. via Proxmox.

Für einen Game-Server würde ich eine native Installation auf Konsumentenhardware nehmen. Man will hier kein ECC oder eine Virtualisierung, welche beide die Latenzen (aus guten Gründen) verschlechtern. Gameserver haben idR. andere Anforderungen als eine WebFarm oder Containercluster, und entsprechend wählt man auch das Hosting. In der Regel will man für solche Workloads nicht viele Kerne mit niedrigem Takt, sondern wenige Kerne, aber mit hoher Taktung und Durchsatz. Du solltest aber in der Game Community eigentlich Erfahrungswerte finden, wie viele Slots bei welcher Hardware sinnvoll sind. Es kann aber echt gut sein, dass sich das je nach Spiel mittlerweile stärker unterscheidet als es früher der Fall war.

Kommt auf dein Ziel an.

Statische Ressourcen:

Statische Dateien entweder über ein echtes CDN verteilen, oder einen Cloud Storage entsprechend auf der Welt verteilen und dort statische Ressourcen ablegen.

Willst du Requests cachen kommt es ein bisschen auf deine Architektur an. Man schaltet REST APIs gerne ein API Management vor und lässt dieses den Cache (oft mit Redis abgebildet) verwalten.

Wilde These: Hast du viele Aufrufe auf "wenig" Content, so lohnen sich eher CDN Dienste. Je nach Dienst zahlst du dort primär für die abgelegte Datenmenge anstatt Traffic, und du brauchst je nach CDN vergleichsweise wenig Einarbeitungszeit.

Zitat von H6G

Die Frage ist, ob dieses Schutzniveau angemessen ist.

Externe Firewalls setzt man bei sensiblen Daten oder bei Windows ein - weil Windows auf L2 schon recht fragwürdig ist.

Wenn du keine Staatsgeheimnisse verarbeitest, reicht auch eine integrierte Firewall.

Sowohl OPNSense, als auch PfSense nutzen das pf Feature des OpenBSD Kernels - sind also Software Firewalls.

Gleiches gilt für nftables unter Linux.

Was?

OpenBSD Pf: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openbsd+pf

Linux nftables: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nftables

Linux iptables: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=iptables (nicht alle Suchergebnisse betreffen das Kernelmodul)

Das stimmt nicht - selbst wenn es stimmt, ist es gleich für andere POSIX Systeme, wie OpenBSD.

Wenn jemand nicht priviligiert unterwegs ist, bekomme ich den relativ leicht runter.

Priviligiert bekomme ich den auch runter, hier ist allerdings eine Neuinstallation empfehlenswert, jedoch keine harte Bedingung

Alles anzeigen

Du hast recht, ich meinte Personal Firewalls. Es geht also um die Unterscheidung ob die Firewall auf dem zu schützenden System läuft oder auf eigener "Hardware".

Die Diskussion bzgl. Schlangenöl war ganz besonders ausgeprägt zu den Hochzeiten von ZoneAlarm und Norton. Mehr als die Windows Firewall fordert selbst das BSI nicht mehr auf Heimanwenderseite, sondern spricht Empfehlungen zur Härtung oder ähnlichem aus.

Externe Firewalls sind nach BSI Ansicht nach ein muss. Es gibt immer mal wieder Dinge, wie zum Beispiel den Ping of Death. Die will man vor dem Server anfangen und nicht auf dem Server. Es gab auch schon Würmer, die es speziell auf verwundbare Personal Firewalls abgesehen hatten. Am bekanntesten ist hier wohl Witty https://de.wikipedia.org/wiki/Witty_(Computerwurm)

Das BSI macht zudem klare Vorgaben zur Trennung von Internet, Server- und Clientnetzwerken. Und das ist wirklich noch der obligatorische Teil des Grundschutzes für normale Unternehmen.

Bezüglich der optionalen Neuinstallation hab ich starke Zweifel. Das System wurde geändert, und selbst Forensiker haben Probleme die Änderungen zu erkennen und zu verstehen. Daher ist der Weg über die Neuinstallation (und natürlich neue Passwörter, Token, Schlüssel und Zertifikate) der einzig sinnvolle. Neben den Veränderungen weiß man ja auch nicht sicher, welche Daten extrahiert wurden. Also mir wäre das Risiko deutlich zu groß.

Zitat von H6G

Proxmox bietet nicht nur das Wiki und ein Forum. Du hast auch eine Dokumentation und man-Pages.

Eine gute Übersicht findest du hier: https://pve.proxmox.com/pve-docs/

Das ganze ist bei Linux / Unix Projekten / Sammlungen von Tools nicht unüblich - vorallem bei Betriebssystem-Distributionen ist es genau so.

Genau so wie Proxmox eine Sammlung von Tools ist, ist VMware genau so eine Sammlung von Tools.

ESXi ist der eigentliche Hypervisor, vSphere vCenter das bessere Verwaltungstool, vSAN für Speicher und NSX-T für das SDN.

Das Zeug ist Open Source: https://git.proxmox.com/ - das kann jeder weiter entwickeln, wenn es Proxmox in 10 Jahren nicht mehr geben sollte.

Komischerweise stellt da keiner die Frage: gibt es Linux und Qemu in 10 Jahren noch? Beides sind Bestandteile von PVE und von Netcup Servern.

Softwareentwickler? DevOps?

Infrastrukturbetrieb ist nicht ohne Grund eine eigene Disziplin und ein eigenständiger Ausbildungsberuf.

Einem Entwickler Operations anzuvertrauen, der von Operations keine Ahnung hat, ist ein Pulverfass.

Proxmox ist kein Hypervisor.

Warum müssen eigentlich Systembetreiber eine Lösung ergooglen können?

Ich bin mir durchaus der Unterschiede zwischen der Enterprise Welt und dem Unix-Kosmos bewusst - das ist teilweise ein Kampf der Kulturen.

Die Realität bei VMware sieht doch aber folgendermaßen aus: du zahlst entweder für teuren Support, den du nicht nutzt, oder du zahlst ein Systemhaus dafür, dass du eine vollständige Lösung bereitgestellt bekommst.

Alles anzeigen

Proxmox versteht sich selbst als Produkt/Plattform und nicht als Toolsammlung. Das wäre auch sonst nicht wirklich wertschätzend Proxmox gegenüber, da es dann doch etwas mehr ist, als nur die Summe seiner "Tools".

Und die Abstaktion soll ja eben ermöglichen, dass der Hersteller die darunter liegenden Tools ggf. austauschen kann, ohne dass die Plattform bricht.

Wenn ich bei jedem Feature erst mal ermitteln muss welches "Tool" im Hintergrund genutzt wurde, dann ist das ungut. Und genau wird ja auch bemängelt.

OpenSource:

Nehmen wir einfach mal an es gibt einen zwingenden Anlass und du machst einen Fork.

Hast du genug Entwickler, um die Plattform auf dem aktuellsten Stand zu halten? Haben die überhaupt das passende KnowHow?

Macht es überhaupt Sinn extrem knappe Entwicklerressourcen dafür einzusetzten, anstatt für das Produkt, mit dem die Firma Geld verdient?

Du kannst nicht einfach die hauseigenen Entwickler drauf werfen und hoffen dass ein Wunder geschieht. Bei MySQL und PfSense war ja der Knackpunkt, dass viele der bisherigen Entwickler den Fork jeweils mitgegangen sind. Ohne die Proxmox eigenen Entwickler, und deren Wissen, kann man das Projekt kaum fortführen.

10 Jahre:

Natürlich schaut man sich vor seinem Investment an, wie "sicher" es ist. Migrationen sind halt teuer, dauern lange und haben ein hohes Risiko.

Wenn ich also meine Infrakstuktur mit etwas aufbaue, bei dem ich garnicht weiß ob es eine gesicherte Zukunft hat oder nicht, dann ist das eine schlechte Wette. Stell dir mal vor ein Unternehmen mit über 1Mrd € Umsatz wäre vom Erfolg einer 30 Mann Klitsche abhängig. Fühlt sich das richtig an oder nicht? Wenn ich jetzt aber ein KMU bin, der innerhalb von 2 Wochen auf ein anderes System umziehen könnte - klar, dann kann ich mit dem Risiko leben.

Linux, Netcup usw.:

Ich unterstelle Netcup einfach mal ihre Tool- und Produktwelt nicht mit einer rosaroten Opensource-Brille zusammengetackert, sondern bewusst einzelne Technologien und Werkzeuge ausgewählt zu haben. Einfach wild "Toolsammlungen" im Unternehmen einzuführen, nur weil sie OpenSource sind, ist ein markantes Sicherheitsrisiko. Auch wenn das etablierte Tools oder Pakete sind, so steigert jedes einzelne die Chance von einem Supplychain Angriff erwischt zu werden.

Linux hat viele große Firmen als Sponsoren und Unterstützer gewonnen. Wieviele hat Proxmox?

In den Fortbestand von Proxmox zu vertrauen, weil man schließlich ja auch bei Linux oder Quemo darauf vertraut, ist für mich keine nachvollziehbare Haltung.

Tesla:

Ein Wipe darf in keiner Welt passieren.

Bezüglich Ops bin ich bei dir. Ich kenne leider kaum DevOps Teams, die wirklich einen Ops im Team haben.

Da hilft oft nur lernen durch Schmerz.

Kostenpflichtiger Support:

Der ist ja wie eine Versicherung zu verstehen. Du bist froh, wenn du ihn nicht brauchst. Brauchst du ihn, bist du froh dass du ihn hast. Hast du ihn nicht, dann ist der Schaden in der Regel deutlich größer. Oft ist der Support deutlich billiger, als wenn der Betrieb ein paar Tage sillsteht. Es kann also durchaus Sinn machen, damit einfach das unernehmerische Risiko zu senken oder die Kosten des Ausfallrisikos auf mehrere Jahre zu verteilen. Da muss man echt im Detail drauf schauen, was da Sinn macht und was nicht. Macht es keinen Sinn - ja klar, dann spart man sich das Geld.

Zitat von Homwer

UFW wäre z.B. erträglich zugänglich und einfach einzurichten.

Die UFW solltest du immer haben.

Trotz externer Firewall möchtest du ja deine Server so sicher wie möglich betreiben. Und via UFW kann man ja wurderbar regeln welche Ports auf welchem Interface offen sein dürfen.

Leider kann die UFW nicht sonderlich viel verglichen mit einer NextGen oder WAP Firewall.

Oft ist man gedanklich in der Richtung UFW < NextGen < WAP Firewall unterwegs, was aber der Sache nicht gerecht wird.

NextGen wie PFSense oder OPNSense können Feeds abonieren, um automatisch DNS Einträge oder IPs zu blockieren.

Das dort enthaltene IDS bzw. IPS ist nur noch als mittelgut anzusehen, da diese Firewalls nicht in den verschjlüsselten Traffic reinschauen können.

Die werden gerne als Primärfirewalls eingesetzt.

Einer WAP Firewall hinterlegst du deine Zertifikate, und die prüft den eingehenden Traffic zum Beispiel auf Injections.

Damit kannst du (hoffentlich) verhindern, dass schwachstellen deiner Anwendung ausgenutzt werden können. WAF überwacht also auf Layer 7 wenn man so möchte. Und natürlich ist das rechenintensiv, daher sollte man nur die wirklich relevante Teilmenge des Traffics analysieren.

Und natürlich gibts Firewalls die sowohl NextGen wie auch WAP Features haben.

Zitat

Was spricht gegen eine Firewall direkt auf dem System?

1. Sicherheit. Eine FW läuft meistens in einer speziell gehärteten Umgebung. Die muss alles aushalten, was ihr das Internet an den Kopf wirft. Du bekommst PfSense und OpnSense nur als Image (oder als SourceCode natürlich)

2. Zumindest PfSense und OPNSense sind BSD basiert.

3. Direkt auf dem System wäre ja dann eine "Software Firewall". Die wurden häufig mit Schlangenöl verglichen und haben nicht selten selber kritische Lücken gehabt. Es gibt aber mittlerweiile seriöse FW Systeme, die einen lokal installierten Agent benötigen. Damit kann man dann die FW Regeln zum Beispiel am Benutzer anstatt am System oder der IP festmachen.

Ansonsten fallen mir ein: Gezielte Skalierung, einfache Installation anhand von ISO Image anstatt als Dienst, erweiterte Features z.B. bei PfSense+ gibts Bootumgebungen mittels ZFS, Trennung der Lasten und damit einfachere Prognosen zur Kapazität, und ganz wichtig: Hat eines der Produkte eine Sicherheitslücke, dann ist nur der eine Dienst gefährdet. Ansonsten gilt: Ist ein Angreifer auf einem Linux Server, egal mit welchen Rechten, dann muss der Server komplett neu installiert werden. Daher lieber einen kleinen extra Server für die FW nehmen, anstatt einen größeren zu Bestellen, auf den man alles drauf packt.

Der letzte Punkt wäre normalerweise VPN gewesen. Jetzt ist ein Szenario von Wireguard eben auch die Server zu Server kommunikation im RZ abzusichern. Daher ist das eher eine Geschmacksfrage als eine Sinnfrage. Würde ich ein Schutzkonzept erstellen, dann würde ich meine "Admin Verbindung" auf die FW machen und dann von dort aus auf ein zweites WireGuard Netz mit meinen Servern routen, dass in einem internen VLAN läuft.

Hat man zwei getrennte WG Netzwerke, dann greifen die FW Regeln der Firewall. Sprich man kann mittels der FW Ports einschränken usw.

Hätte man ein großes WG Netzwerk mit Servern + Admin Clients, dann würde nur WG intern geroutet werden.

Zitat

Alles da, was man braucht.

Im Vergleich zu anderen Produkten ist sie ziemlich schwach.

Das ist einer der häufigsten Kritikpunkte bei Proxmox. Markantes Zitat:

"While I do mostly like Proxmox, the only thing I dislike is its atrocious documentation. The wiki itself is alright, but it's missing a lot too and the moment it does you'll likely have to hope there are solutions other places than their forum. It's one of the few forums I can wholeheartedly call awful."

Nicht selten wird kritisiert, dass man erst ein gewisses Maß an Revers-Engineering machen muss, da es eben an der Dokumentation hapert.

Dass man das machen kann ist schön - aber die Notwendigkeit ist zweifelsfrei ein Kontraargument und kein Pro.

Zitat

Ganz normales Interface-Bonding im Linux Kernel.

Hardware-Switch richtig konfiguriert?

Ebenfalls bekanntes Proxmox Thema. Ich hab mal google bemüht:

https://old.reddit.com/r/sysadmin/comments/yzm5hc/shout_out_to_proxmox_ve_devs_best_hypervisor_imo/ix1l2e7/

Davon abgesehen ist die Bobachtbarkeit des Datenverkehrs echt mittelgut.

Zitat

Split / Brain?

Nein, da stirbt ja nicht das ganze Cluster.

Bekanntes Beispiel nach 5 Sekunden Googlen:

"Tesla devs used proxmox and trusted it. One host went down and the entire cluster failed. They lost everything on it. The entire config was wiped. They were down for quite a while. I knew a guy that helped them bring it back to life. They lost a ton of work."

Klar kann man da bei der Schuldfrage über viele Dinge streiten.Trotzdem darf das einfach nicht passieren.

Bei einem split brain sieht es aber auch nicht so rosig aus. Da ist man schnell in der Welt des Frickelns, und im Enterprise zahlt man gerne einen Aufpreis für Systeme, die sich selbst heilen. Frickeln ist da unangemessen.

Das schöne ist ja, das Proxmox alle Themen kennt und teilweise auch offen zugibt, dass es sie zumindest "vereinzelt" gibt. Ein IT-Entscheider würde sich hier fragen "Reicht uns Proxmox, oder brauchen wir etwas besseres?". Und natürlich die Frage "Gibt es Proxmox in 10 Jahren überhaupt noch? Was passiert, wenn die kleine Firma aufgekauft und die primären Entwickler abgezogen werden?

Versteht mich nicht falsch, ich will das Produkt nicht schlecht reden. Die Frage, ob etwas für Produktion geeignet ist, ist vielschichtig. Es ist wichtig nicht die subjektive Wahrnehmung als objektive Wahrheit darzustellen. Wenn für H6G als Beispiel die Doku ausreichend ist, dann ist das für ihn einfach ein Kritikpunkt, der kein Gewicht hat . Wenn er allerdings gefragt wird müsste er klar differenzieren: Für ihn ist die Dokumentation ausreichend, aber andere finden sie unzureichend.

Analog dazu "Alles da, was man braucht." müsste es inhaltlich heißen: "Alles da, was H6G gebraucht hat. Andere kritisieren allerdings dass gerade bei besonderen Problemstellungen im Gegensatz zu anderen Hypervisors keine einfache Lösung für das Problem ergoogelt werden kann. Das kann gerade bei gemischten Skillstufen im Team problematisch sein."

Und sorry dass ich da jetzt echt ein bisschen lang drauf herumgeritten bin H6G.

Zitat von KB19

Dafür hat man im Proxmox-Forum einen direkten Draht zu den Entwicklern, wahlweise auf Deutsch oder Englisch. Und das sogar ohne Subscription

Bitte mehr Details, da werde ich hellhörig. Welche Bugs kenne ich noch nicht?

Die VM Backups waren es, wenn ich mich richtig erinnere. Ich hab auf die schnelle diesen Bug gefunden:

https://bugzilla.proxmox.com/show_bug.cgi?id=2874

Ich weiß aber offengestanden nicht mehr, ob dass das einzige Problem in dem Zusammenhang ist/war.

Bzgl Support:

Bei anderen Produkten hatten schon 100 Leute vor dir das Problem, und du findest Infos im Netz.

Support in einem Forum zu deutschen Ladenzeiten ist für uns toll, aber halt nicht wirklich Enterprise Ready. Das meine ich absolut nicht abwertend, nur wenn jemand wissen möchte ob es Produktionsgeeignet ist, dann ist das vielleicht ein NoGo. Bei anderen Herstellern bekomme ich 24/7 Expertensupport, bei Proxmox bekomme ich für Geld maximal innerhalb von 2 Stunden eine "Erstreaktion". Eine Erstreaktion kann auch sein, dass man dem lieben Kunden aus den USA mitteilt, dass die Entwickler gerade alle im Bett liegen. Proxmox ist halt ein kleines Unternehmen und hat laut LinkedIn nur zwischen 11 und 50 Mitarbeiter.

In den Augen der meisten IT-Verantwortlichen im Enterpriseumfeld wäre Proxmox damit schlichtweg ein Risiko. Für KMU hingegen kann das Risiko durchaus akzeptabel und Proxmox eine Lösung sein.

Du kannst einen zweiten, kleineren RS mieten und darauf eine Firewall installieren.

Die zwei Server dann mit einem internen VLAN verbinden und allen Verkehr durch die Firewall routen lassen.

Das bietet dir drei Vorteile:

1. Du kannst bekannte Filterlisten nutzen, um z.B. TOR und bekannte "böse" IPs auszusperren.

2. Du kannst in der Firewall ein VPN nutzen, um die Firewall und deinen Dienstserver zum Beispiel via SSH zu erreichen.

3. Du kannst die Firewall Regeln mittels einer übersichtlichen GUI verwalten.

Am Ende des Tages solltest du aber jeden Server so einrichten, als wäre er direkt dem Internet und allem Bösen dieser Welt exponiert.

Fail2Ban ist immer Pflicht und in 2 Minuten installiert und eingerichtet für SSH.

Ich würde in deinem Fall die Firewall nicht in einer VPS installieren. Sprachdaten sollten immer möglichst geringe und gleichbleibende Latenzen haben.

Solltest du Monitoring betreiben, so könntest du z.B. Grafana und die DB deines Vertrauens ebenfalls hinter der Firewall platzieren. So kommst du mit dem dem gleichen VPN an all deine Dienste. Die Fail2Ban Mails helfen kaum wenn der SSH Port öffentlich zugänglich ist. Von meinem Gefühl her sind die Mails eher dafür gedacht, dass man aufmerksam wird, wenn ein nicht öffentlicher SSH Port angegriffen wird. Wenn man eine Statistik der Fail2Ban Jails will, dann kann man diese Info auch via Telegraf ermitteln und z.B. in eine InfluxDB schicken. Das ist auch der Grund, warum ich anfangs Grafana empfohlen hab: Ich will meine Alarme am liebsten nur von einem einzigen System bekommen und dort die zugehörigen Regeln managen.

Proxmox ist in meinen Augen noch lange nicht Enterprise ready.

Beispiele: Fehlende Dokumentation / wenige Suchtreffer bei Problemen, Failover bei Netzwerkkarten, Backups sind uU. defekt und Cluster sterben, wenn ein einziger Node kaputt geht.

Aber für ein Home-Datacenter oder ähnliches ist Proxmox absolut in Ordung.

Witzigerweise läuft der bei mir auch auf einem Intel NUC!

Mal eine ganz andere Frage: Auf einem RS bräuchte man doch das kostenpflichtige Virtualisierungs Flag auf jedem CPU Kern, um VMs in Proxmox nutzen zu können.

Oder hat sich das inzwischen geändert? Wenn ich einfach nur Container verwalten will mit einer WebGUI, dann kann ich z.B. auch Rancher verwenden. Der läuft ziemlich stabil, und man hat die typischen K8S Werkzeuge zur Hand.

MTU bei Kabel auf IPv4:

1500 – 20 Bytes (IPv4) – 8 Bytes (UDP) – 32 Bytes (WG) = 1440 Bytes

Bei IPv6 40 Bytes abziehen anstatt 20.

Aber mal der Reihe nach.

1. ICMP (Ping Echo Response) temporär auf WAN erlauben

2. MTU am WAN Interface Zuhause und in der Remote Firewall auf 1500 setzen

3. Prüfen mittels MTU-Checker (Google kennt mehrere)

4. Entweder es passt direkt, oder du reduzierst die MTU bis es genau passt.

Die WG MTU ist 60 (IPv4) oder 80 (IPv6) bit weniger als die WAN MTU.

Solltest du ganz seltsame UDP Probleme haben, die sich nicht greifen lassen:

Hast du von DS Lite auf DS umstellen lassen? Im Zweifel mal den Support anrufen und um Abschaltung von "DS LIte" bitten.

Bei mir hat danach UDP zuverlässig funktioniert.

Hint1: Bei einem DSL Anschluss noch einmal 8 bit abziehen.

Doppelte NAT müssten weitere Abzüge erfordern. Aber sowas machen wir ja nicht...

Hint2: UDP und Wireguard über Mobilfunk ist oft reine Glückssache. Ich hab damit letztes Jahr ganz schlechte Erfahrungen gemacht. Da wird bei Last der UDP Traffic richtig fies gebremst.

Hint3: Site2Site, wo die FW selber routen muss erfordert meistens eine explizite Definition der Gateways. Wenn du nur WG intern routest via Keys, dann ist das ziemlich egal. Aber wenn du Netzwerkgrenzen überschreiten willst reicht es einfach die Gateways passend zu den WG interfaces anzulegen.

So hab ich bei mir WG richtig stabil bekommen.

Vielleicht ist das auch eine brauchbare Lösung für dich:

Ich hab zwei ältere NAS von Synology dafür genutzt. Das eine erstellt mittels installiertem Agent brauchbare, inkrementelle Backups.

Das Backup wird dann von ersten NAS auf das zweite repliziert.

Die Backup Software von Synology echt gut und läuft eben auch auf dem WIndows Server kostenlos.

I would recommend using a cluster of servers for such a large database.

But we warned, running clusters is not that easy or cheap for production use cases.

You could also start to think about big data solutions in this context.

Or... You might be better off with reducing your data.

For my metrics, I usually keep only the data for the last 14 days.

Older data gets aggregated to average values. Like hourly values instead of every x seconds.

At the end, it depends on your use case, database type and data. Most times it is wise to use a specialized database for time series data instead of simply scaling up a relational database like MariaDB or MSSQL But talking about such big databases, I guess you already made this step.

Aktuell würde ich nach Intel N6005 suchen mit mindestens 4 Intel NICs mit jeweils 2.5 Gbit.

Kostenpunkt bei 8GB RAM (mehr brauchst du bei ner Firewall definitiv nicht) sollte so bei 350 Euro liegen.

Das ist erhelblich günstiger als bei Netgate und reicht fürs Heimnetz mehr als aus.

Dummerweise wurde das Ding auf Youtube von den Influencern ziemlich gefeiert und ist vergriffen aktuell.

Ich habe einige 10Gbit Geräte und bin deswegen direkt auf ein Netgate Gerät mit passenden Anschlüssen gegangen.

Allerdings mache ich ausgerechnet kein Inter-VLAN-Routing zwischen den 10Gbit Geräten, daher hätte es eigentlich gereicht wenn ein externer Switch das VLAN intern macht und fertig. Vielleicht ist es ja bei dir ähnlich.

Mein Vorschlag:

Route über deinen VPN Server nur den Traffic zwischen den LAN Netzen und NICHT den Traffic fürs Internet.

Einfache Sache:

Gibt jedem LAN eindeutige IPs.

Trage bei AllowedIPs nur die internen IP Adressen der jeweils entfernten Netzwerke ein und deines VPN Servers.

Double checken:

VPN Server muss IP forwarding erlauben

Alle können sich zum VPN Server verbinden

Firewall des VPN Servers so einstellen, dass da Traffic zu den jeweiligen Zielen geroutet werden kann.

Die clients sollten ein KeepAlive senden, wenn keine Portfreigabe am Router vorhanden ist.

Das geht definitiv alles mit Wireguard. Ich mach damit deutlich schlimmere Sachen...

Wenn du nicht wirklich auf die Konsole willst kannst du dir auch eine kleine VM mieten und einfach PfSense oder OpnSense installieren.

Die kannst du als VPN Server verwenden und die Firewall Regeln sind einfacher einzustellen. Die Firewall kannst du dann nutzen um deine teurere VM zusätzlich zu schützen.

Zitat von michaeleifel

Schön zu hören Ich lasse mich überraschen

Da sehe ich aktuell keinen Vorteil zu Unbound als DNS Resolver auf allen Kisten der im Zweifel auch noch gecachte bereits abgelaufene Antworten liefern kann. Irgendwo her muss die Firewall Kiste dann ja auch wieder die Einträge bekommen und eigentlich 2 davon wegen SPOF. Klar kann ich CF, G00gle und Co. in meine resolv.conf eintragen, aber eigentlich will ich dass mein Cluster bei Verlust der externen Konnektivität nicht direkt Amok rennt ( Erfahrungen aus dem Berufsleben )-

Unbound auf der PfSense hat mehrere Vorteile:

1. Du hast eine GUI und bessere Beschreibungstexte.

2. Du kommst nicht in eine Schräglage durch abweichende DNS Antworten. Das kann dir zum Beispiel passieren, wenn ein CDN oder Cloudanbieter für 2 IPs unterschiedliche GEO daten hat und nicht auf die gleiche Region matcht. Das ist mir tatsächlich schon mehrfach passiert und das will man einfach nicht haben.

3. Am Caching und asynchronen Nachladen ändert sich ja nichts. Deinem Cluster ist es ja egal wo er den DNS Eintrag herbekommt. Zumal viele Cluster selbst interne DNS Server betreiben.

4. Resolver pro Server verursachen unnötigen Traffic und Last. Das macht man nicht und die Dienstanbieter bitten auch deutlich darum, das nicht zu tun. Dann lieber einen Public DNS Eintragen und Forwarden.

Du kannst dir z.B. eine PfSense Firewall auf einen zweiten kleinen Server installieren und beide mit einem VLAN verbinden.

So kannst du einrichten, dass Traffic an deinen Mailserver erst durch die Firewall hindurch muss.

Benefit:

Du kannst z.B. mittels Suricata traffic analysieren und blockieren.

Du kannst mit PfBlocker z.B. als böse gelistete IPs blockieren.

Du kannst bequem VPNs aufsetzen, um einen nicht öffentlichen SSH Zugang auf deinen Mailserver zu haben.

Das ist aber eine Lösung, die deutlich mehr Einarbeitung erfordert.

Du kannst natürlich auch eine IPS Lösung nativ installieren. Suricata kann man auf den meisten Systemen betreiben, also zusätzlich zur rudimentären Firewall wie ufw.

Wenn man mehrere Server bei Netcup hat lohnt es sich vielleicht einen weiteren als Firewall (z.B. Pfsense, OpnSense) und Service Provider einzusetzen.

Ich nutze die Firewall einen DNS Resolver zu betreiben und um einen zentralen Zeitserver zu haben.

Das hat den Charme, dass ich manche DNS Einträge gezielt von Dritten auflösen lassen kann, um zum Beispiel auch "Private DNS" von Cloudanbietern bequem nutzen zu können. Die Einträge kurz zu flushen ist natürlich auch kein Problem...

Wenn man keine Firewall benötigt, dann ist das natürlich ein wenig über das Ziel hinaus...

Du meinst ein Hybrides Setup im Kleinformat?

Schau dir mal Azure AD Connect an.

Windows Server hat die relevanten Features schon nach der Installation aktiv.

Dein Administrativer Benutzer sollte nicht admin heißen. Erstelle einen neuen admin Account, benenne ihn schwer erratbar OmisKatze oder sonst was.

Deaktiviere den ursprünglichen administrativen account.

Generiere dir ein sicheres Passwort mit Keypass.

Das war die Pflichtübung.

EIne 1+ mit Sternchen gibts wenn du den RDP nur via VPN zugänglich machst.

Von da an heißt es munter Updates installieren und Backups machen. Letzteres mindestens einmal pro Tag.