Wenn mir jemand die Installation verschlüsselt hat, dann will ich die alten Backups und nicht die aktuellen.
Beiträge von frank_m
-
-
Ich dachte ich brauche IPv4 (und eben auch IPv&) forwarding um die Pakete über der WireGuard-Schnittstelle weiterzuleiten?
Ich dachte, du hattest bereits einen Wireguard Server, der für IPv4 funktioniert und nun auch für IPv6 laufen soll. Wenn du den in der gewohnten Weise weiterbenutzen willst, musst du im Grunde nur IPv6 als Server-Adresse aktivieren. Im Tunnel kann alles bleiben, wie es ist, und auch Forwarding Rules brauchst du keine neuen.
-
Speziell auf WireGuard gesehen muss ich eine IPv6 dann nur „normal“ auf dem Server einrichten und das forwarding für IPv6 aktiveren – das wars?
Um nur den Server zu aktiveren, braucht es kein Forwarding. Oder läuft der Server nicht nativ, sondern in einem Container oder einer VM? Dann kann es sein, dass man Forwarding braucht.
Innerhalb des Tunnels kann man ja wieder mit IPv4 arbeiten. Darauf hat die externe Verbindung keinen Einfluss, und dafür braucht man auch kein Forwarding.
-
Kommt drauf an, ob du auch eine IPv4 Adresse hast, und zwar vor allem auch auf der Gegenseite.
Wireguard arbeitet ja (eigentlich) verbindungslos über UDP, sprich, beide Seiten müssen einen UDP Server zur Verfügung stellen. Gut, es gibt sowas wie Keep-Alive, um NAT Tabellen am Leben zu halten, aber prinzipiell gilt das oben gesagte. Vorteilhaft ist es auf jeden Fall, wenn beide Seiten erreichbar sind. An vielen Heimnetz-Anschlüssen mit Kabelinternet oder Glasfaser bekommt man keine öffentliche IPv4 mehr, sondern DS-Lite oder CGNAT Anschlüsse, und dort hat man nur eine öffentliche IPv6 Adresse. Wenn dort dein Wireguard-Client sitzt, dann wäre ein IPv6 Zugang ein echter Vorteil, denn beide Partner könnten sich gegenseitig erreichen, ohne dass man extra Klimmzüge machen muss.
Generell steigen die IPv6 only Angebote, Congstar bietet z.B. Mobilfunktarife an, die keine IPv4 Adresse mehr haben. Da wäre dann ein IPv6 Server sogar zwingend erforderlich.
Ich würde heute nicht mehr drauf verzichten. Mittelfristig wird es Pflicht, und es ist kein Hexenwerk.
-
Pull hat in meinen Augen den Vorteil, dass im worst case bei einer Kompromittierung des Servers, nicht auch noch die Backups in Mitleidenschaft gezogen werden können
Genau das ist der Grund. Pull und nichts anderes.
-
ich weiß gerade nicht was du mit der Original IP meinst
Der Server hat im Auslieferungszustand eine IPv6 Adresse, die sich aus deinem Prefix und der EUI-64 Interface ID des Servers zusammensetzt. Die ist z.B. auch das Routing Ziel für zusätzliche IPv6 Netze und damit die "Standard-Adresse" in der netcup Welt für diesen Server. Die solltest du auf jeden Fall testen.
Aber ich kann ihm natürlich Docker noch eine IP zuweisen, hört sich am besten an.
Denk an die Verbindungsunterbrechungen aufgrund von NDP, wenn du dem Docker Container eine Adresse aus deinem mitgelieferten /64 zuweist.
Sie wollten nur wissen ob ich das Rettungssystem starten kann und dann noch ob ich eine IPv6 dort konfigurieren kann. Dort hat es funktioniert. Danach war das Thema für sie erledigt.
Ich glaube auch nicht, dass das ein Problem der Infrastruktur ist. Wenn die Adresse und die Routen richtig eingerichtet sind (also passt das Prefix?), dann kommt natürlich als erstes die Firewall ins Spiel, denn die ist im Rescue Image nicht aktiv.
-
Was passiert mit der Original-IP vom Server? Also mit der Standard-Konfiguration nach der Installation des Images? Was ist mit der Firewall?
Willst du NAT für IPv6 machen? Würde ich nicht empfehlen. Verpasse dem Docker Container besser eine öffentliche IPv6, vorzugsweise aus einem zusätzlichen /64 um der Problematik des geswitchten ersten /64 aus dem Lieferumfang aus dem Weg zu gehen.
Falls doch NAT: hast du die entsprechenden Firewall Regeln eingeführt?
-
Das Login bei servername.de/froxlor - war vorher mit SSL
Das SSL geht aber leider nicht mehr.
Jetzt läuft es über IPBeispiel 1.2.3.4/froxlor
Das geht auch, aber halt ohne SSL.
Dann heißt das aber, dass die gesamte Domain nicht per Zertifikat abgesichert ist. Nur das /froxlor hintendran stört das Zertifikat nicht. Da ist also ein Bock in deiner Gesamtinstallation, und Froxlor ist nur das Symptom, aber nicht die Ursache. Anders ausgedrückt: es wäre vermutlich ein leichtes, Froxlor wieder über den Hostnamen mit SSL zu betreiben, wenn du es richtig machst.
-
Hat jedenfalls beides funktioniert. Gibts da nen richtiger ? xD
Nein, ich glaube nicht.
-
Und funktioniert es nun?
-
jedoch erstelle ich auf dem Server Zertifikat für mydomain.de (Servername + Alias) so habe ich danach https für http://www.mydomain.de aber nicht für mydomain.de
Dann ist was falsch eingestellt, denn das funktioniert bei mir problemlos - sofern mydomain.de und http://www.mydomain.de auf dem gleichen Server laufen. Sonst musst du sie auch getrennt abrufen.
SSL/TLS-Zertifikat konnte für mydomain.de nicht ausgestellt werden. Details: SSL/TLS-Zertifikat von Let's Encrypt konnte nicht für mydomain.de abgerufen werden.
Das kann ja auch über Webhosting nicht klappen, wenn A und AAAA Records auf andere Server zeigen. Die Challenge muss auf dem Server ausgeführt werden, auf den die DNS Einträge zeigen. Oder du machst es per DNS, was vermutlich dazu führt, dass du die Updates manuell machen musst.
-
"0" hilft auf jeden Fall. Wichtig ist, dass sie kleiner ist als die von der IP, die abgehend benutzt werden soll.
-
Kann man das irgendwie z.B. per Route umgehen , ohne das die Adresse "2a03:4000:33:21:6856:59ff:fef2:653b" hinzugefügt und erreichbar wird?
Nein. Über die preferred_lft kannst du verhindern, dass diese IP abgehend verwendet wird. Aber eingehenden Traffic darfst du nicht verhindern, da sie das Routing Ziel ist.
-
Grundsätzlich ist es sehr gut, dass du ein Problembewusstsein dafür entwickelt hast. Das ist schon die halbe Miete auf dem Weg zum sicheren Server.
100% Sicherheit gibt es nicht. Es ist immer eine Frage, welches Risiko man zu akzeptieren bereit ist. Wichtig ist, dass man unerwünschte Dienste abschottet und die erwünschten so weit wie möglich absichert. Erster Schritt ist also eine Firewall, die alles verbietet, außer das, was erlaubt sein soll. Und für die erlaubten Dienste kann man sich dann ansehen, wie man die weiter absichert, durch Application Level Firewalls, Plugins oder Konfigurationen. Das muss man sich dann im Einzelfall ansehen, pauschal ist es schwierig.
Den Tipp von aRaphael finde ich sehr gut. Zu Hause in einer VM ist es ungefährlich, zu testen, und da kann man auch wieder dran, wenn man die Firewall zu restriktiv gemacht hat und sich ausgesperrt hat (nicht, dass mir das je passiert wäre ...
). -
Du hast jetzt
Codesource /etc/network/interfaces.d/*komplett auskommentiert, dabei geht es dir ja im Grunde nur um die cloud-init. Ggf. wollen da irgendwann andere Anwendungen ihre Konfigurationen ablegen, und dann funktioniert es nicht.
-
Bin wohl zu doof habe die interfaces.d auskommentiert und alles in die interfaces gepackt. zum testen habe ich noch ein paar IP's hinzugefügt
Da sind auch immer noch Gateway Angaben drin, die da meines Erachtens nicht hingehören, denn die erzeugen Konflikte. Dazu empfiehlt die Doku, nicht mehrere iface Einträge zu erzeugen, sondern up oder post-up statements.
Dabei fällt mir auf: Deine zusätzliche IPv4 hat auch ein eigenes Gateway. Ist das richtig? Bei mir hat die das nicht. Außerdem hat meine zusätzliche IPv4 die Netzmaske /32.
-
Wenn die /etc/network/interfaces die Einträge aus der /etc/network/interfaces.d/50-cloud-init.cfg überschreiben würden, dürften die IP's
2a03:4000:2a:###:1431:28ff:fe04:367f und 193.30.123.### nicht vorhanden sein.
Deshalb schrieb ich ja auch:
Dir ist klar, dass die Änderungen in der interfaces nicht mehr greifen, wenn sie sich in Teilen mit der cloud-init überschneiden?
Genau das passiert hier.
Bin mir aber nicht sicher ob die nicht beim Start automatisch wieder angelegt wird.
Deshalb macht es Sinn, sich mit der cloud-init Doku zu befassen. Dann weißt du, wo du die Sachen ändern kannst.
Alles anzeigenJetzt stehe ich auf dem Schlauch.
/etc/network/interfaces.d/50-cloud-init.cfg
address 2a03:4000:2a:3dc:1431:28ff:fe04:####/64
und in der /etc/network/interfaces
address 2a03:4000:20:###::1
sind doch zwei Adressen
Die 50-cloud-init hast du nachträglich in deinen Beitrag reineditiert. Als ich die Antwort geschrieben habe, war die IP noch nicht zu sehen.
-
Wenn die 50-cloud-ini die Einstellungen überschreibt wäre die Anleitung nicht richtig.
Nein. Zum einen kann die Anleitung ja nicht wissen, ob überhaupt cloud-init installiert ist, zum anderen gilt IMMER das, was in der interfaces steht, man muss es nur lesen.
source /etc/network/interfaces.d/*
Und es steht VOR deinen Einträgen.
... bis ich herausgefunden habe wo das Problem liegt
Dürfte jetzt klar sein, oder? Übrigens finde ich immer noch nur eine IPv6. Wie schon erwähnt, das reicht nicht.
-
Die IP's sind ALLE nicht die realen Adressen und sollen nur zeigen das die IPv6 beim reboot nicht gesetzt wird.
Dann mach wenigstens deutlich, welche davon öffentliche, und welche private sind. Das Unkenntlichmachen der letzten beiden Zifferngruppen reicht ja völlig.
Da unter interfaces.d ist nur die default 50-cloud-init.cfg da werden die netcup ips wohl automatisch gesetzt.
Und das macht dich nicht stutzig? Dir ist klar, dass die Änderungen in der interfaces nicht mehr greifen, wenn sie sich in Teilen mit der cloud-init überschneiden?
Also:
- zeig deine Konfig mal nachvollziehbar anoymisiert
- Beachte die Konfiguration von ifupdown komplett und nicht nur einen Teil.
-
Es ist enorm schwierig zu beurteilen, was nur aufgrund deiner Anonymisierung so ist, und was echte Adressen sind. Insgesamt sieht mir das mehr als chaotisch aus.
- Warum sind da private und öffentliche IPs auf dem Interface, auch bei IPv4? Das kann nicht gut sein.
- Die 1.1.1.1 und 2.2.2.2 sind keine realen Adressen, hoffe ich?
- Wo ist denn die ursprünglich zugewiesene IPv6? Die brauchst du ja zwingend als Routing Ziel
- Ich würde für die Fail-over IP nicht nochmal das Gateway angeben. Die Route gibt es schon.
