Beiträge von Paul

    ah, ok, danke für die Antworten - das bestärkt meine Vermutungen und klingt logisch.

    ich frage mich allerdings, wie die kommerziellen VPN Provider (Nord VPN, Cyberghost...) das dann machen - denen ihre Server sind ja wohl auch in Rechenzentren vor Ort ?

    Die haben die Probleme zum Teil auch. Sie versprechen zwar, dass mit ihren Diensten Geoblocking umgangen werden kann, die Realität sieht dann meist aber doch etwas anders aus. Manchmal klappt es. Oft aber auch nicht.

    Hier liegt wohl ein kleines Missverständnis vor. Du willst ja deinen Docker Container über Apache erreichbar machen. Was du aktuell konfiguriert hast, ist eine reine Weiterleitung, sprich dein Docker Container muss aktuell weiterhin auch für den Enduser direkt erreichbar sein. Was du eigentlich möchtest, ist ein sog. Reverse Proxy. Siehe auch https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html


    Statt einer Rewrite Rule brauchst du eine ProxyPass Konfiguration wie in dem Link oben beschrieben.

    Anschließend sollte dein Container zumindest über Port 80 des Apache erreichbar sein. SSL ist dann aber nochmal ein weiterer Schritt. Dafür brauchst du dann einen vHost auf Port 443. Ich würde aber erst einmal die Konfiguration mit ProxyPass durchgehen und schauen, dass das funktioniert. Anschließend kann man sich um die SSL Konfiguration kümmern.

    Ich habe einige K3s Single Node Server hier bei Netcup laufen. Funktioniert im Grunde einwandfrei. Ich würde aber empfehlen, einen Firewall Helper wie UFW oder Firewalld zu nutzen. Da macht die ganze Konfiguration sehr viel einfacher. Ich selbst nutze immer Firewalld.

    Für K3s (oder andere Kubernetes Lösungen) sind hier noch folgende Schritte notwendig:

    1. Masquerade auf dem Public NIC aktivieren.

    2. Traffic von und zu 10.42.0.0/16, 10.43.0.0/16 erlauben (falls nicht anders konfiguriert).

    Als Beispiel für Firewalld hier mal meine Zonen.

    1. Public NIC

    XML
    <?xml version="1.0" encoding="utf-8"?>
    <zone>
      <short>PUBLIC</short>
      <description>Public Internet</description>
      <interface name="eth0"/>
      <masquerade/>
      <service name="http"/>
      <service name="https"/>
    </zone>

    2. K3s

    XML
    <?xml version="1.0" encoding="utf-8"?>
    <zone target="ACCEPT">
      <short>K3S</short>
      <description>k3s zone</description>
      <source address="10.42.0.0/16"/>
      <source address="10.43.0.0/16"/>
    </zone>

    Ich habe schon viele Varianten ausprobiert, bin mittlerweile aber wieder bei 1 x 27 Zoll (4k) gelandet für meinen primären Schreibtisch. Da hängen dann 3 PCs dran (Desktop, Intel NUC, Laptop über USB C - je nachdem, mit welchem ich gerade arbeite).

    Am Multimonitor Betrieb hat mich grundsätzlich immer gestört:
    1. Ich kann mich eh nur nur auf 1 Fenster gleichzeitig konzentrieren. Meine Arbeit findet daher zu über 95% sowieso nur auf einem Monitor statt.
    2. Wenn ich aufgrund von Punkt 1 einen Primär-Monitor habe, sollte dieser zentral vor einem stehen, sonst hat man genau den Zwischenraum vor den Augen und muss permanent "zur Seite" schauen. Nimmt man aber einen primären Monitor zentral vor sich, dann stehen die anderen relativ weit weg. Gerade die Außenseiten der Sekundär-Monitore sind dann zum Teil so weit aus dem Blickfeld, dass anstrengend ist, dort was anzeigen zu lassen, was dann eher dazu führt, dass ich diese Monitore gar nicht in Verwendung hatte.

    3. Mein letzter Versuch war ein Setup, bei dem ich 1 x 27 Zoll (4k), mit 1 x 24 Zoll (WQHD) im Einsatz hatte. Durch die unterschiedlichen Auflösungen hatte ich aber so Probleme mit der Skalierung, dass ich auf keinem der beiden Monitore wirklich zufrieden zwar (auf dem einen zu groß - auf dem anderen zu klein).

    4. Trotz gleicher Modelle haben Monitore trotzdem unterschiedliche Farbdarstellungen. Das ist optisch sehr störend.

    5. Stromverbrauch.

    Ich war dann zwischenzeitlich auch mal in der Ultrawide (34 Zoll) Welt unterwegs. Außerhalb von Spielen hat mich das aber nicht wirklich überzeugt. Fenster waren dann nie zentral ausgerichtet, sondern wieder rechts und links, was dann wieder dazu geführt hat, dass ich die meiste Zeit zu einer Seite geschaut hat. Und durch das Curved Design wurden Texte, Tabellen, Linien nie wirklich gerade dargestellt.

    Der Curved Monitor ist daher jetzt Teil von meinem 2. Schreibtisch (Gaming Setup). Dieser hat auch USB C und ich kann jederzeit mit meinem Laptop da mal dran, wenn ich ihn doch mal verwenden möchte. Die sich ständig ansammelnde Staubschicht verrät mir aber, dass ihn eigentlich nicht wirklich brauche ^^ .

    Mal genauer reingelesen, fällt als Medium für eine Installation meiner Meinung nach aus:

    Die netcup server bekommen vom DHCP ja eine Adresse, und sind umgehend online, d.h nach dem Booten "offen" für jeden ...

    Hast du das mal getestet? Wenn das Root Passwort nicht gesetzt ist, heißt das eigentlich in den meisten Fällen, dass der Root Account für den Login gesperrt ist. Es würde mich jetzt ehrlich gesagt etwas wundern, wenn man sich hier per remote einloggen könnte. Zumindest, wenn die das ISO so konfiguriert hätten. Ich kenne das eigentlich nur, wenn da Passwort ein leerer String ist. Aber ein nicht gesetztes Passwort sollte hier kein Problem sein.

    mal doof gefragt, wo liegt das Problem hier: auf Seite der Bank od. auf Seite von Mozilla(Firefox)?

    in der FF Version 121 für Fedora wird eine Seite - für mich doch essentiell, Teil vom Banking - derart verunstaltet anzeigt,

    aber unter Windows in der selben Version 121 wird diese ganz normal und korrekt dargestellt;

    Mal den Cache gelöscht? Oder alternativ im privaten Modus getestet? Wenn das woanders problemlos läuft, würde ich das Problem eher lokal vermuten. Vielleicht macht auch dein Proxy komische Dinge?

    Ansonsten würden die zusätzlichen Ziffern m.E. keinen Sicherheitsgewinn im Vergleich zum Passwort mit 6 zusätzlichen Ziffern bringen. Zumndest dann, wenn man das Passwort häufig genug wechselt. Eher wäre das Gegenteil der Fall... :/ Oder wo liegt hier der Denkfehler?

    Primär geht es darum, dass der 2. Faktor ein zeitlich begrenztes Passwort ist (30 Sekunden). Ein potentieller Angreifer hat also im Grunde nur 30 Sekunden Zeit dieses zu erraten. Danach ist es ungültig und ein neues Passwort muss erraten werden. Im Gegensatz dazu ist der 1. Faktor weitestgehend statisch. Das reguläre Passwort wechselt man nicht alle paar Sekunden. Vielleicht in Ausnahme mal alle paar Monate oder Jahre, aber im Gegensatz zu dem 30 Sekunden dauernden 2. Faktor ist das praktisch statisch. Daher ist TOTP Nicht einfach nur ein längeres 1. Passwort, sondern bringt noch eine Zeitkomponente mit rein.

    Danke,

    Haben die netcup Server einen NVRAM, um den efi boot Eintrag zu speichern ? Stichwort efibootmgr ?
    Und wie man oben sieht, muss man ja noch einiges anpassen, bevor man den Server startet. Normalerweise würde ich dies mit arch-chroot machen, als Life Medium steht aber kein Arch Arm bereit... Henne Ei Problem ?

    Ich hatte wohl etwas zu spät meinen Post noch ergänzt. Ein aarch64 ISO kannst du hier finden: https://archboot.com/iso/aarch64/2023.12/ Darin sollte dann auch das gewohnte arch-chroot enthalten sein.

    Also würdest du auch eher zum VPS 200 G10s raten als den Rednose? Oder VPS500.

    Falls die CPU Leistung relevant sein sollte, dann ja! Ein einfacher Web- oder Mailserver läuft aber auf mit dem Rednose problemlos. In meinem Fall hätte er aber ein kleiner k3s Server werden sollen und dafür war mir dann die gebotene Leistung doch etwas zu schwach. Das hatte ich bereits auf dem VPS Mikro getestet.

    Direkt mal ein Update. Server wurde wie gewohnt sehr schnell bereit gestellt. Aber die gebotene Leistung ist doch sehr schwach. Sogar noch schlechter bzw. gleich wie beim günstigeren VPS Mikro. Ich hatte ja etwas gehofft, dass es einer der neueren AMD CPUs wäre, aber das scheint doch eher ein alter Intel Xeon zu sein. Mit meinem obligatorischen Sysbench CPU Test kommt ich hier auf ~732.17 Events/s (1 Thread). Mein schon etwas älterer VPS 200 G8 mit AMD kommt hier auf 1368.12 Events/s, was ich so auf bei dem Rednose erwartet hätte. Daher geht der wohl auch direkt wieder zurück. Ich wollte das nur mal als kleinen Hinweis da lassen, falls es den ein oder anderen interessieren sollte.

    Ich habe den Rednose jetzt mal bestellt und teste ihn mal. Erfreulicherweise hat er ja nur eine Mindestvertragslaufzeit von 1 Monat, daher teste ich ihn jetzt mal gegen den VPS Mikro, welcher von der Leistung her doch stark beschnitten ist und mich nicht ganz überzeugen konnte. Der Mikro läuft bei mir jetzt zwar produktiv, aber nur, weil ich dafür eh wenig Leistung benötige und eigentlich auch mit 1 oder 2 Core klar käme.

    Die ARM VPS (Gen 11) sollten spürbar schneller sein als die die VPS (Gen 10s). Zumindest sind die CPU Werte deutlich besser. IO Performance ist in etwa gleich geblieben. Dafür hat man bei den ARM Server größere Disks.

    Als Image stehen im Moment nur Debian 12 und Ubuntu 22.04 zur Verfügung. Mittels eigener ISOs lassen sich aber auch beliebg andere Distributionen installieren (erfolgreich getestet mit Fedora 39 aarch64).

    Wie KB19 schon angedeutet hat. Man darf nicht vergessen: Nach dem Wechsel ist vor dem Wechsel. Hat man den Sprung von Windows auf Linux einmal geschafft, hört es ja nicht auf. Dann fängt das Distro-Hopping an. Von Ubuntu auf Fedora, dann mal Suse. Irgendwann landet man dann sowieso bei Archlinux ^^ . Nicht zu vergessen die ganzen Desktop Umgebungen. Von KDE auf GNOME hin zu XFCE oder i3 und wieder zurück.

    Die Diskussionen in Windows mit den Änderungen an der Oberfläche gibt es ja bei Linux genauso. Der Wechsel von Gnome 2 auf 3 oder auch von KDE 4 auf 5 war nicht minder leiser.

    Das größte Problem an Windows ist vor allem der Online Account Zwang. Microsoft kann dir den jederzeit sperren, wenn sie der Meinung sind, du hast eine falsche Meinung oder etwas falsches geschrieben. Meinen lokalen Linux Account nimmt mir keiner so einfach weg.

    Kraus Geht es dir nur um den SSLLabs Test? Wenn ja, dann teste das bitte nochmal mit einem anderen Tool oder einer anderen Seite. SSLLabs hatte in letzter Zeit ein paar Probleme. Die Seite war die Tage zum Teil sogar mal komplett down. Ich würde aktuell auch nicht ausschließen, dass das Problem auf Seiten SSLLabs liegt, wenn es denn mit anderen Tools problemlos funktioniert. Teste das also mal mit einer alternativen Methode. Und versuche auch mal die Dev Version: https://dev.ssllabs.com/ssltest/ (evtl. funktioniert es ja dort).

    Also nur so aus Interesse: Warum benützt Ihr noch Microsoft-Produkte?

    Mein Gaming Desktop läuft mit Windows (zwangsläufig). Auch benötige ich diesen um gewisse Firmware Updates (z.B. für meine Logitech Produkte) installieren zu können. Dafür sind dort aber auch sonst keine (persönlichen) Daten drauf. Daher kann ich damit gut leben.

    Aber nicht alle Produkte sind direkt schlecht, nur weil sie von Microsoft kommen. Mein im Grunde wichtigstes Tool (VS Code Editor) kommt auch von Microsoft. Und das läuft auf allen meinen Linux Systemen. Funktioniert wunderbar. Oder auch eine SwiftKey Tastatur auf meinen Mobilgeräten.

    Bei dem Netcup Images (Debian 12 zumindest) ist das so Standard. Finde es aber auch sehr komisch.

    Bei mir heißen die Standard ens3 bei Allen Servern. Installiere Debian aber immer über die Iso von Netcup. Nicht die Images.

    Soll wohl schon seit Debian 9 Standard so sein. Man kann aber die Alten Namen wieder Aktivieren. In dem Fall eth0

    Ah ok, danke. Gut zu wissen. Die /etc/network/interfaces überschreibe ich direkt mittels Ansible. Daher kannte ich die mitgelieferte Config so gar nicht.

    Der Fehler bleibt nach dem reboot der gleiche.

    Auf meinen anderen Debian-Installationen sieht die interfaces ebenso aus.

    Kontrolliere dann wirklich nochmal, ob die Daten mit denen im SCP übereinstimmen. Auch wenn das eigentlich erst einmal keinen Fehler werfen sollte. Wenn man ein falsches Gateway angibt, sollte eigentlich nur das Routing nicht funktionieren. Was sagt denn ip a bzw. ip r? Siehst du dort deine neue IP? Könnte auch sein, dass das Interface zwar hochkommt und nur der Service an sich wegen irgendwas meckert, aber das Netzwerk prinzipiell funktioniert.