Beiträge von frank_m

Die DNAT Regeln ab 59 sind quasi Portforwardings.

Jedenfalls sieht man in den NAT Regeln in der DOCKER chain auch schön die Regeln, die an deinen UFW Regeln vorbei den Zugriff auf die Docker Container erlauben.

Zitat von netsch1967

Die Geräte haben hier alle IPv6.

Ja, aber bei dir zu Hause haben sie IPv6 Adressen vom Internetzugang, auf dem VPS vom /64. Du tranferierst die Adressen nicht durch den Tunnel.

Zitat von netsch1967

Einige LTE Netze haben da kein Routing IPv4 --> IPv6 gemacht

Das geht technisch auch nicht. IPv4 und IPv6 können nicht direkt miteinander reden.

Zitat von netsch1967

Aber woher sollen die Switche von Netcup wissen, zu welchem Interface(eth0) sie die IPv6 Anfragen schicken sollen, wenn diese nicht dem Interface zugeordnet sind.

Dafür gibt es eben den ndppd. Das allein reicht aber nicht. Siehe die Threads, die ich oben verlinkt habe, es gibt weitere über die Suche.

Zitat von netsch1967

Wenn ich mich auf die Console vom Container verbinde und über curl die Seite "wieistmeineip.de" aufrufe, bekomme ich die IPv6 angezeigt, die ich dem Container zugewiesen habe. Was nutzt da jetzt wer nicht wie?

Dann noch mal die Bitte nach konkreten Konfigurationsbeispielen. Was genau hast du da gemacht? Vielleicht ist das eine Lösung auch für andere Problemstellungen.

Zitat von netsch1967

Der VPN ist über eine IPv6 erreichbar. Im Tunnel wird ein 10er Netz genutzt. Alles hinter dem VPN, also das was ich erreichen möchte, liegt wieder im /64er vom Host.

Ja, das meinte ich. Du nutzt das /64 nicht im Tunnel. Dein Setup ist trivial, das muss funktionieren. Spannend wird es ja, wenn auch die andere Seite des Tunnels Adressen aus dem mitgelieferten /64 nutzen soll, z.B. um Geräte ohne IPv6 Anbindung über VPN mit IPv6 Adressen zu versorgen. Das geht aber nicht, wie beschrieben.

Zitat von netsch1967

Netcup gibt selber die Empfehlung, wenn man weitere IPv6 Adressen aus dem /64er nutzen möchte, diese dem ETH0 zuzuweisen (/etc/network/interfaces).

Ja, das schrieb ich ja auch oben. Aber davon nutzt du sie ja nicht im Container, vor allem nicht abgehend, selbst wenn du Weiterleitungen per iptables oder sowas einrichtest. Bist du dir darüber im Klaren? Das ist weit weg von der Nutzung weiterer Adressen für deine Container, vor allem auch, wenn du Dienste über IPs trennen willst. Das geht so nicht ohne weiteres. Das Setup in der Firewall wird so sehr komplex.

So verteilst du einfach nur zusätzliche Adressen auf eth0, nicht mehr und nicht weniger.

Zitat von netsch1967

Soll wohl funktionieren, aber sehr umfangreich in der Confi, in Docker als auch im Host.

Nein, funktioniert nicht, aus den beschriebenen Gründen.

Zitat von netsch1967

Meine VPNs haben alle das /64er Präfix vom VPS Host.

Wo genau verwendest du das? Wieder die Bitte nach Beispielen, zeige mal eine beteiligte Wireguard Config Datei. Meine VPNs nutzen für den Verbindungsaufbau auch das mitgelieferte /64 Netz, aber nicht innerhalb des Tunnels.

QEMU Tools sind prinzipiell sehr leistungsfähig, wenn es darum geht, virtuelle Festplattenimages zwischen verschiedenen Formaten zu konvertieren. Gibt es auch für Windows.

Zitat von netsch1967

Vielleicht einfach "nur" die zusätzliche IPv6 vom ETH0 mit dem entsprechenden Container verknüpfen und nicht ein "ganzes" Subnet routen,

sondern "nur" eine einzelne IPv6. Habe es gerade mit 4 Apache2 Containern und 4 IPv6 Adressen ausprobiert. Funktioniert einwandfrei.

Das Setup verstehe ich noch nicht. Was genau meinst du mit "zusätzliche IPv6 vom ETH0 mit dem entsprechenden Container verknüpfen"? Kannst du mal ein Beispiel liefern, wie das aussieht?

Zitat von netsch1967

Muss ich deutlich widersprechen.

Nutze schon länger mehrere VPS exclusive über VPN Verbindungen.

Davon rede ich nicht. Ich meinte, wenn du Adressen aus dem mitgelieferten /64 innerhalb eines VPN Tunnels für Remote Geräte nutzt. Das funktioniert nämlich nicht zuverlässig.

ZST ist eine Kompressionstechnologie. Das ist der ganze Unterschied. Je nachdem, was du mit dem Image machen willst, musst du es ggf. entpacken.

https://de.wikipedia.org/wiki/Zstandard

Indem du mit "-t" die entsprechenden Tabellen angibst, z.B. "raw", "nat", "mangle", "security".

Generell empfehle ich, dich intensiv mit iptables bzw. nftables zu befassen. ufw ist nur ein Frontend, die eigentliche Filterung findet woanders statt.

Ich wage zu bezweifeln, dass die Lösung stabil läuft. Ich kann mir kaum vorstellen, dass eine einfache Lösung für dieses sehr spezifische Problem einfach in irgendwelchen anderen Foren steht, ohne hier bekannt geworden zu sein. Es haben sich ja schon sehr viele sehr intensiv mit dem Problem befasst. Die Docker Netzwerkeinstellungen können es nicht sein, da LXC etc. ja genauso betroffen ist. Selbst wenn man nicht über Virtualisierung spricht, sondern die Adressen nur für irgendwelche VPN Netze nutzen will, tritt das Problem auf.

Das ist immer noch nur ein Bruchteil der erforderlichen Regeln. Die NAT, Pre- und Post-Routing Regeln fehlen noch.

Zitat von netsch1967

Klingt sehr unlogisch!

Das ist aber doch logisch. Du bekommst ein /64 Netz. An deinem eth0 Interface kannst du davon so viele Adressen nutzen, wie du willst, kein Problem. Erst wenn du anfängst, Routing-Konstellationen daraus zu bauen, bekommst du ein Problem.

Zitat von netsch1967

Wo ist da die Logig, wenn ich das Suffix selber festlegen kann - Ob das nun beim ersten /64er erfolgt oder beim zweiten.

Der Unterschied liegt in der Art, wie dir das Netz zur Verfügung gestellt wird. Das mitgelieferte Netz wird geswitcht, das zusätzliche Netz wird auf deinen VPS geroutet - dafür braucht es keine Layer 2 Verbindung.

Zitat von netsch1967

Am DSL oder Glasfaseranschluß gibt es auch "nur" ein /64er Netz und es funktioniert.

Nein, das stimmt nicht. Dein Router zu Hause bekommt eine Adresse aus einem /64 Netz und zusätzlich ein Prefix aus einem anderen Netz - meistens sogar größer als /64 (/60 oder /56 ist üblich). Wenn es nur ein /64 gibt, wie z.B. im Mobilfunk, brauchst du Sonderlösungen wie RFC7278 zum Beispiel, da ein Router 2 Subnetze braucht, um routen zu können. Das ist ja auch der Grund, warum du dein /64 auf dem VPS weiter unterteilst in /96 oder /112.

Zitat von netsch1967

Es gibt im SCP die Möglichkeit zum /64er Netz weitere IPv6 Adressen bekannt zu geben.

Hilft es dort anzusetzen?

Da geht es ja nur um RDNS.

Zitat von netsch1967

Weiß dann das Netcup System welche IPv6 Adressen zu welchen MACs gehören?

Ja, via NDP. Aber das gilt für Adressen, nicht für Subnetze.

Hast du das NDP Problem bedacht? "ndppd" ist der perfekte Suchbegriff fürs Forum. Dazu finden sich einige Threads, die man sich am besten komplett ansehen sollte.

In Kürze: Die MAC Forwarding Tabellen in den Switches bei Netcup veralten und wissen nicht mehr, auf welcher MAC sie eine spezifische IPv6 Adresse erreichen, weil das primäre IPv6 Netz geswitcht und nicht geroutet zur Verfügung gestellt wird. Das Problem verstärkt sich, weil du die Adressen nicht auf eth0, sondern auf anderen Interfaces benutzt. Aber auch mit einem NDP Proxy lässt sich das Problem nicht zu 100% lösen, es wird immer zwischendurch mal zu Paketverlusten kommen. Selbst mit zusätzlichen Hilfsmitteln, wie z.B. regelmäßigen Pings von verschiedenen Quell-Adressen etc. Eine wirklich saubere Lösung erreichst du nur mit einem zusätzlichen IPv6 Subnetz, welches auf deinen Server geroutet wird.

Zitat von Interessent

- Der Netzwerktyp aller Container (bis auf einem Wireguard Container) ist NICHT Host

Alle Regeln, die du ins zeigst, betreffen die INPUT Kette. Aber in dem Fall ist die FORWARD Chain entscheidend, vor allem auch die Pre-Routing und Post-Routing Regeln. Dort wird festgelegt, welche Pakete von außen auf deine Container gelassen werden. Also auch wenn du sie hier nicht freigegeben hast, können darüber Pakete an deine Container gelangen.

Du musst schon das gesamte Regelwerk betrachten.

Um das beurteilen zu können, müsste man sich ansehen, welche Regeln du exakt in ufw und ufw-docker anwendest. Welchen der Wege hast du denn konfiguriert? Input oder Forward?

Zitat

ch habe das jetzt mal ein paar Tage beobachtet.. ich bekomme in unregelmäßigen Abständen eine neue IPv6 , zumindest teilweise, bedeutet: 2a0d:3344:xxxx:xxxx:c47:3d2a:b512:c39d

Bis xxxx ist immer gleich, nur der hintere Teil ändert sich.

Der Router hat üblicherweise nichts damit zu tun. Der sendet nur Router Advertisements aus, und die beinhalten nur den ersten Teil der Adresse bis zum xxxx:xxxx, das Prefix.

Ändern tut sich bei dir die Host-ID, also der hintere Teil. Die bestimmt dein PC, und dafür gibt es verschiedene Wege. Meistens generieren die Endgeräte mehrere Adressen: Statische und temporäre, die unterscheiden sich nur durch die Host-ID, das Prefix vom Router ist immer gleich. Temporäre Adressen ändern sich regelmäßig und werden von den Systemen für abgehenden Traffic genutzt. Damit bleibt man im Internet ein Stück weit anonym, weil die Adresse sich regelmäßig ändert. Die statische IP bleibt statisch und ist halt dafür da, dass der Rechner immer unter einer bekannten IP erreicht werden kann, allerdings gibt es auch hier verschiedene Wege, die Host-ID zu berechnen. Neben EUI-64, das die Adresse auf Basis der MAC berechnet, gibt es auch Algorithmen für zufällige statische Adressen.

Also: wenn sich der hintere Teil der Adresse ändert, ist das Endgerät zuständig. Die Frage ist: Welche IP hast du denn überprüft? Ändert sich nur die temporäre Adresse (das ist normal), oder auch die statische?

Ich empfehle immer noch die Dokus von Peter Bieringer:

https://mirrors.bieringer.de/Linux+IPv6-HOWTO-de/

Zitat von Interessent

Plan wäre auf dem VPS einen zusätzlichen Adguard Home Container aufzumachen.

Hab ich genau so, allerdings mit Pi-Hole, und auch mit eigenem Unbound.

Zitat von Interessent

Was muss ich denn im Adguard einstellen, damit dieser nur auf die Verbindungen von Wireguard reagiert, auf sonst nix?

Der Adguard lauscht einfach erst mal in seinem Container. Welche Anfrage du an ihn weiterleitest und von wo er erreichbar ist, entscheidest du woanders, z.B. im Container-Setup, in der Firewall des Hosts und im Wireguard Setup.

Zitat von Interessent

Müssen dann Adguard und Wireguard im gleichen Docker Netzwerk laufen?

Sie müssen sich erreichen können. Ob über einen Switch oder über Routing, spielt in der Praxis wohl nur eine untergeordnete Rolle.

Have you tried another ISO, e.g. Ubuntu?

Grundsätzlich kann man in iptables Regeln Subnetze angeben, wenn der Syntax passt (siehe #2). Also auch in der before.ufw.

Solche Sperrlisten mache ich allerdings nicht direkt über die Firewall, das ist viel zu ineffizient (meine IPv4 Blockliste hat 200.000 Einträge). Unter iptables mache ich es mit ipset, unter nftables mit Filter Tabellen.