Indem man einen USB Stick in den entsprechenden Port steckt.
Oder willst du Unraid auf einem VPS installieren? Das halte ich für suboptimal. Da gibt es besser geeignete Lösungen, je nach Anwendungsfall. Unraid ist klar auf lokale Heimserver ausgelegt.
Ich bin jetzt kein absoluter interfaces Experte, aber deine eigenen Einträge sind vom Syntax her was ganz anderes, als die aus der cloud-init. Da die aus der cloud-init funktionieren und deine nicht, würde ich jetzt mal empfehlen, deine Einträge entsprechend anzupassen. Dazu gehören auch Einrückungen etc, und die Angabe der Subnetzmasken.
Die liegen auf dem Server, je nach Betriebssystem woanders.
Leider nicht ganz. Klär mich bitte mal auf
Du importierst die 50-cloud-init.cfg vor deinen eigenen Einträgen (was deine obsolet macht) und sie verwendet ein anderes Interface, was wahrscheinlich bedeutet, dass en3 bei dir nicht funktionieren wird.
Ich weiß nicht, inwiefern cloud-init da reingrätscht und Änderungen an den Dateien in /etc/network wieder überschreibt.
Dir ist klar, was schief geht, oder?
Liegen in /etc/network/interfaces.d/ Dateien?
Hast du die Datei mal mit einem falschen Editor bearbeitet? Sowas passiert gern bei Windows Zeilenumbrüchen.
Es wäre hilfreich, wenn du die Fehlermeldungen der systemd Services postest. Aber bitte in Code Tags, nicht als Screenshot.
Der Eintrag für IPv6 ist falsch. Du musst PTR Records für konkrete Adressen setzen, nicht für Subnetze. So hast du <prefix>:0:0:0:0 gesetzt, und die Adresse gibt es voraussichtlich nicht.
//Edit: zu spät ...
Es können doch mehrere Domains den gleichen Mailserver verwenden. Wo ist das Problem? Wichtig ist, dass der PTR zu den mx und spf Einträgen passt.
D.h., du kannst den Server quasi "selber reparieren", durch Einspielen eines Backups? Er bootet nicht, weil das FS korrupt ist? Es ist nicht die VM, die Fratze ist, sodass der Support eingreifen müsste?
Crasht vielleicht OPNSense? Hast du ne Chance, über Rescue System vielleicht noch Teile des FS auszulesen und zu analysieren?
Engagiere jemanden, der sich damit auskennt. Die Fragestellung lässt darauf schließen, dass du es keinesfalls selber machen solltest. Allein das Absichern des Servers gegen Hacker Attacken dürfte dich überfordern, da rede ich noch nicht mal von Installation, Konfiguration, Wartung und Pflege der Produktiv-Software.
Offenbar gibt es im neusten HWE Kernel Update für Ubuntu 22.04.03 LTS ein Problem mit ZFS. Der neueste per HWE ausgelieferte Kernel ist Version 6.5.0.14, der im Zusammenspiel mit der zfs Version in der 22.04 LTS oder mit den Snap Paketen für lxd wohl Probleme hat. Folge kann sein, dass z.B. lxd Container nicht mehr starten (Fehlermeldung: "Required tool 'zpool' is missing"). Daran hab ich es auch bemerkt. Boote ich den vorherigen HWE Kernel (6.2.0-39), dann starten die Container normal.
Man scheint sich der Problematik bei ubuntu bewusst zu sein:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657
Ein Update auf zfs 2.1.14 scheint die Lösung für Ubuntu LTS zu sein, ist aber offenbar noch nicht verfügbar.
Der neue Kernel wurde trotzdem ausgerollt. Die Frage ist: Gibt es alternative Lösungen für das Problem, außer auf den HWE Kernel zu verzichten? Ist jemand von euch damit auch konfrontiert worden?
wg-quick@ Systemd-Service-Unit
Ich hab meine gesamten init Scripte inzwischen auf systemd aufgebaut, auch meine eigenen. Deshalb das.
Das stimmt nun gar nicht. Bei jeder Anmeldung die auch ein Passwort verwendet, wird das Passwort an Netcup gesendet.
Es wird nicht gesendet, sondern im Browser ausgewertet, also bei dir lokal. Übertragen und gespeichert wird nur ein Hash.
Und wieso haben dann andere grosse Cloud-Provider noch immer das Angebot, ein sicheres Passwort statt 2FA zu verwenden?
Weil sie bislang nicht reagieren mussten. Übrigens werden einige große Provider in Kürze 2FA verpflichtend machen, z.B. Microsoft bei den 365 Diensten. Es ist ne Frage der Zeit.
Und beim Einloggen muss man in einem Fixen Intervall das Passwort aendern.
Was ja inzwischen als absolut kontraproduktiv identifiziert wurde. Bei Provider, die mit derartig antiquierten Methoden arbeiten, möchte ich ja kein Kunde sein.
Sonst gibt es keine Rechtfertigung
Das sehe ich anders. netcup kann die Stärke deines Passwortes ja nicht beurteilen. Und wenn es zu Missbrauch kam, dann müssen sie reagieren, schon aufgrund der regulatorischen Vorgaben.
Ich werde meinen Account kuendigen
Sehr gut. Eine Sicherheitslücke weniger.
Peinlich ist diese Maßnahme nur für die, die sich jetzt davon überrascht fühlen, denn die hatten keine 2FA aktiv. Ich habs nichtmal mitbekommen, erst als hier die Diskussion losging.
Funktioniert auch das nicht, versuch es mit dem Rettungssystem.
Mit Ubuntu anstatt pfSense hat er ja kein Problem mit IPv6 auf dem Netcup Server. Siehe seinen anderen Thread.
Ich frag mich halt immer noch, wofür überhaupt pfSense? Und vor allem: Wofür auf dem Proxmox?
Das Ziel ist ja offenbar, per VPN die öffentliche IP zum Heimnetz zu tunneln und Serverdienste darüber anzubieten. Kann man so machen. Wenn es mit Ubuntu funktioniert, wofür was anderes nutzen? Aber wofür mehrere VPN Verbindungen? Wofür das VLAN intern im Proxmox? Ein VPN Tunnel reicht, um die Ports der öffentlichen IP in den Proxmox zu tunneln und dort auf die Container zu verteilen. Wenn es unterschiedliche Ports für die Container sind, wie angedeutet (80, 88, 888), dann ist man hier schon fertig. Möchte man mehrere Dienste auf denselben HTTP/S Ports anbieten, dann baut man einen Proxy auf den Proxmox, oder meinetwegen alternativ auf den Netcup Server. Kommt aufs gleiche raus. Aber wieder kein Grund für mehrere VPN Tunnel oder VLANs.
Offenbar gibt es ja Probleme, die Dienste von außen erreichbar zu machen, und zwar gerade bei dem Container, der hinter der pfSense sitzt. Meines Erachtens liegt es einfach daran, dass das Setup für den Anwendungsfall viel zu komplex gewählt wurde. Das geht einfacher, und damit auch weniger fehleranfällig.
Ist mir klar, ich will nur mehr Kontorolle darüber welches Netz was darf und was nicht.
Wir reden über einen (!) Container auf einem Proxmox. Da hast du andere Möglichkeiten, den Zugriff zu kontrollieren, dafür braucht es wahrlich kein VLAN. Willst du rumspielen oder ein produktives Setup?
Damit ich jeden einzeln per Port oder Subdomain ansprechen kann.
Das geht auch über einen gemeinsamen Tunnel, da jeder Container immer noch eine eigene IP hat. Hilft dir aber so oder so nicht weiter, weil die öffnentliche IP am Ende über die verfügbaren Ports entscheidet.
Mir ist nicht bekannt wie man mit Dyndns und eigener Domain nicht im Spamordner landet oder blockiert wird.
Wie gesagt, DNS hat nichts damit zu tun. Dyndns ist auch nur ein ganz normales DNS mit kurzer TTL. Über SPAM oder nicht entscheidet die IP des Mailservers. Da rettet einen auch ein ordentliches DNS nicht.
Wegen der Festen IP für den Mailserver hinter VPN (habe getestet,funktioniert)
Es ist problematisch, wenn die Anforderungen häppchenweise verraten werden.
VLAN um Heimnetze zu trennen
Das VLAN ist intern auf dem Proxmox, nicht in deinem Heimnetz.
ich will mit meiner Domain drauf zugreifen
Das geht auch ohne VLAN.
Dyndns wird bei Mailserver nicht funktionieren.
Doch, das geht problemlos. Die verwendeten IPs fürs DNS sind eher das Problem.
Jeder Server hat eigene WG Verbindung
Warum das?
Ziel ist alles von der festen IP des Netcupservers zur pfSense "durch-NAT-en", dann Filtern und Weiterleiten.
Aber warum bauen dann die Container die VPN Tunnel auf? Und warum ein extra Router dafür?
ich folge deinem Rat (wenn ich nicht weiter komme) und notiere mir Routings usw. vom Ubuntu und versuche es nochmal mit pfSense direkt auf Netcup Server.
Auch auf dem netcup Server hat pfSense nicht das geringste verloren.
Keep it simple. Ein VPN Tunnel von netcup zum Proxmox. Ein Proxy auf dem Proxmox. Kein pfSense, kein VLAN.
Die Erklärungen sind doch sehr verwirrend. Wo ist denn das Proxmox Setup? Bei dir zu Hause?
Web3 hängt im Tagged VLAN an der pfSense und hat öffentliche IP der FritzBox
Wenn es doch eine öffentliche Fritzbox-IP gibt, warum dann der ganze Aufstand? Und warum das tagged VLAN? Web3 ist doch genau so ein Container, wie die anderen?
pfSense hat auch eine Wireguard Verbindung, Gegenseite lässt sich auch anpingen.
Ist das die gleiche WG Verbindung wie für Web1 und Web2? Wofür ist die?
in meinem Setup handelt es sich um ein Doppel-NAT,
Wieso Doppel-NAT? Erst mal ist da ja nur die Fritzbox. Was du danach machst, ist ja deine Sache und entsprechend relativ leicht einzurichten.
ich habe schon so vieles probiert und bekomme es einfach nicht hin Web3 erreichbar zu machen (ip:888)
Das Setup ist natürlich auch reichlich verschroben. Wofür überhaupt die pfSense? Wofür VLANs?
Grund warum pfSense nicht direkt auf dem Netcup-Server installiert ist, pfSense bekommt keine IPv6 Adresse.
Die bekommt sie doch jetzt auch nicht, oder? Aber das könnte man sowohl auf dem Netcup Server als auch hier ändern.
Ich verstehe nicht: Wenn die Fritzbox eine öffentliche IP hat, warum dann überhaupt der Netcup Server? Und wenn alle 3 Container einfach als Webservice erreicht werden sollen, warum dann eine pfSense mit VLAN, und nicht einfach ein banaler Proxy?
