Beiträge von AutoYaST

    Moin,

    hier die Konfiguration die Stand 2022 mit Netcup VPS und OpenBSD 7.1 funktioniert - vio0 ist in diesem Fall das "Haupt-Interface":

    Änderung von Interface Optionen (sooi o.ä.) ist nicht mehr nötig. Aber slaacd scheint erforderlich zu sein (rcctl enable slaacd && rcctl start slaacd).

    Das %vio0 in der Standardroute für IPv6 scheint theoretisch nicht nötig zu sein, wenn nur ein einziges Interface vorhanden ist, schadet aber nicht (ich hatte es erst ohne %vio0, und mich dann beim Starten eines zusätzlichen Interfaces gewundert, warum IPv6 Konnektivität nicht mehr funktioniert - klar wenn die Standardroute eine Interfaceroute ist, muss das System wissen zu welchem Interface).

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Zu Hause verwende ich einen passiv gekühlten Mini PC von Qotom, direkt aus China bestellt. Die gibt's in Ausführungen bis 8 Ethernetports und stecken auch in diversen OEM Produkten, die hierzulande angeboten werden. Die Hardware ist ordentlich und jedenfalls meine Ausführung hat Intel NICs.

    Kann ich deinem Profilbild entnehmen, dass das Teil mit OpenBSD kompatibel ist? :)

    ... und selbst wenn ich z. B. ein Repo zu `apt` hinzufüge und da irgendwas installiere (was dann am besten direkt noch drölf Dependencies mit dazu zieht) weiß ich auch nicht genau, was am Ende alles läuft.

    Ja da bin ich etwas verwöhnt - in-House Open Build Service, alle installierten RPM Pakete werden intern gebaut und signiert.

    muss da auch noch den Creator vertrauen,

    Das Problem ist, dass sich viele Menschen wahllos Container aus dem Internet ziehen und betreiben (ala "docker pull nginx:latest && docker run ......."), ohne zu verifizieren, dass der Binärcode in dem Container tatsächlich auf dem Quellcode der Softwareherausgeber basiert. Dazu zählt sowohl das Programm, welches man im Container betreiben möchte, als auch das Container-Betriebssystem selbst. Man hat also, insbesondere wenn der Container von einem Drittanbieter stammt, eine Mehrzahl von Individuen in der Verteilkette einer Software involviert, welchen man theoretisch allen vertrauen muss, wenn man nicht seine eigenen Container baut und diese ausschließlich über eine interne Docker Repository bereitstellt.

    Andererseits muss man ebenfalls bedenken, dass "regulär" installierte Software oftmals ebenso wenig vor der Installation geprüft wird - es tummeln sich viele Installationsanleitungen die mit sowas wie "curl http://installier-mich.com/ | sudo bash -" beginnen.

    Wenn man Dateien, welche üblicherweise vom System aktualisiert/regeneriert werden, manuell ändert, sollte man aber sicherheitshalber verhindern, dass Änderungen durch einen Automatismus „ohne weiteres“ wieder

    Besser noch, das System verstehen lernen, und entweder das System richtig nutzen, oder den Automatismus richtig deaktivieren.

    Habe da auch einen Server mit Lego welcher sich alleine um die Zertifikatsanforderungen kümmert. Auf die meisten Systeme kann der dann via SSH mit einem eingeschränkten Nutzer die neuen Zertifikate direkt kopieren und installieren (z.B Dienste neu laden). Auf ein paar Server, welche mir kritischer sind, legt der eingeschränkte Nutzer die Zertifikate aber lediglich in eine versiegelte chroot, und ein Cronjob außerhalb der chroot schaut gelegentlich ob es etwas neues im "Zertifkatspostfach" zum installieren gibt.

    Also plain HTTP geht mit .dev nicht - da brauchst du ein gültiges Zertifikat und musst HTTPS nutzen. Für alle anderen Dienste (ICMP/ping, DNS, SSH, etc.) ist das aber irrelevant.

    Die Adresse mit :: am Ende ist natürlich gültig - bei Netcup gehört einem das gesamte /64 Netz, da wird nicht die erste Adresse für einen Router o.ä. "weggenommen".

    Allerdings muss man die :: Adresse korrekterweise ebenso wie zusätzliche (::1, ::2, etc) im SCP eintragen und im Gastbetriebssystem einrichten.

    Leider kenne ich mich mit Ubuntu und der hier gelieferten Cloud Init Konfiguration nicht aus.

    Die Route sieht dort richtig eingetragen aus, allerdings sollte zusätzlich geprüft werden, ob

    • Dein Client- und/oder Heimnetzwerk überhaupt mit IPv6 mit dem Internet verbunden ist (ping -6 netcup.de ?) und falls ja:
      • `dig <domain> AAAA` den v6 Record zurückgibt
      • `ping -6 <domain/IP adresse>` eine Antwort liefert
    • Deine VM via IPv6 in's Internet kommt (ping -6 netcup.de ?) und falls nein:
      • Router Advertisement im Gastsystem funktioniert (sonst "kennt" der Netcup Router deine IP Adresse nicht)
      • Die IP Konfiguration von Cloud Init auch tatsächlich aktiv ist (`ip a` und `ip -6 r`)

    Wenn diese Basiskonnektivität funktioniert kann man sich den weiteren Diensten (HTTP[S] u.ä.) widmen.