und das mitgelieferte /64 Präfix liegt am Interface eth0 an?
Natürlich, was willst du denn sonst damit machen?
Wiki - Könnte man auch beim großen Hahn finden, oder?
Wer ist der große Hahn?
und das mitgelieferte /64 Präfix liegt am Interface eth0 an?
Natürlich, was willst du denn sonst damit machen?
Wiki - Könnte man auch beim großen Hahn finden, oder?
Wer ist der große Hahn?
von ETH0 auf Docker zu legen
Du legst vom zusätzlichen Subnetz nichts auf eth0.
Dann ist es doch richtig -
..und das mitgelieferte /64 Präfix liegt am Interface eth0 an?
Und, wie ist denn nun die "richtige" Konfiguration.
Poste doch mal deine Interfaces, Iptables, Docker Config, etc.
Übrigens "der große Hahn" -> Hahn -> sprichwörtlich goggel -> abgeleitet zu google.
Kommst nicht vom Land - Goggel = Hahn auf dem Mist!
Dann ist es doch richtig -
Was ist richtig?
Und, wie ist denn nun die "richtige" Konfiguration.
Naja, die kannst letztlich nur du kennen. Befasse dich mit Grundlagen von IP Routing, dann ist es nicht schwer. Das Grundprinzip ist klar: bis eth0 ist es das mitgelieferte /64, weitere Interfaces auf dem Server nutzen das zusätzliche Netz. iptables Regeln brauchst du eh, jetzt mit dem mitgelieferten Netz genauso, wie zukünftig mit dem zweiten Netz. Bis auf die IPs ändert sich nichts.
Kommst nicht vom Land - Goggel = Hahn auf dem Mist!
Ich komm vom Land. Bei uns heißt er Gockel.
Was ist richtig?
Naja, die kannst letztlich nur du kennen. Befasse dich mit Grundlagen von IP Routing, dann ist es nicht schwer. Das Grundprinzip ist klar: bis eth0 ist es das mitgelieferte /64, weitere Interfaces auf dem Server nutzen das zusätzliche Netz. iptables Regeln brauchst du eh, jetzt mit dem mitgelieferten Netz genauso, wie zukünftig mit dem zweiten Netz. Bis auf die IPs ändert sich nichts.
Ich komm vom Land. Bei uns heißt er Gockel.
Die Frage war, wie sehen deine Konfigurationsbeispiele aus?
Naja, ob dir das weiterhilft? Ich nutze Ubuntu mit netplan, LXD und Wireguard. Das zweite Subnetz kommt auf dem VLAN (eth1), für die Container und fürs VPN zum Einsatz. Das mitgelieferte Prefix ist 2a03:4000:x:y, das 2. Prefix ist 2a03:4000:a:b.
50-cloud-init.yaml:
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 46.38.a.b/24
- 91.x.y.3/32
- 2a03:4000:x:y::1/64
- 2a03:4000:x:x::2/64:
lifetime: 0
- 2a03:4000:x:y:a:b:x:y/64:
lifetime: 0
routes:
- to: default
via: 46.38.255.1
- to: default
via: fe80::1
match:
macaddress: d6:34:b4:a:b:c
eth1:
addresses:
- 192.168.50.1/24
- 2a03:4000:a:b:3::1/80
match:
macaddress: d6:34:b4:a:b:c
Display More
lxc network:
Name: lxdbr0
MAC address: 00:16:3e:a:b:c
MTU: 1500
State: up
Type: broadcast
IP addresses:
inet 10.24.24.1/24 (global)
inet6 2a03:4000:a:b::1/80 (global)
inet6 fe80::a:b:c:d/64 (link)
wg0.conf:
[Interface]
Address = 192.168.200.1/32,2a03:4000:a:b:1::1/128
ListenPort = y
PrivateKey = [...]
[Peer]
#Home1
PublicKey = [...]
AllowedIPs = 192.168.200.2/32,192.168.175.0/24
Endpoint = [...]
[Peer]
#Home2
PublicKey = [...]
AllowedIPs = 192.168.200.3/32,192.168.177.0/24
Endpoint = [...]
[Peer]
#Handy1
PublicKey = [...]
AllowedIPs = 192.168.200.4/32,2a03:4000:a:b:1::4/128
[Peer]
#Tablet
PublicKey = [...]
AllowedIPs = 192.168.200.5/32,2a03:4000:a:a:1::5/128
[Peer]
#Notebook
PublicKey = [...]
AllowedIPs = 192.168.200.6/32,2a03:4000:a:b:1::6/128
[Peer]
#Desktop
PublicKey = [...]
AllowedIPs = 192.168.200.7/32,2a03:4000:a:b:1::7/128
[Peer]
#Handy2
PublicKey = [...]
AllowedIPs = 192.168.200.8/32,2a03:4000:a:b:1::8/128
Display More
Einige Firewallregeln:
ip6tables -A INPUT -i eth0 -d 2a03:4000:x:y::1 -p tcp -m multiport --dports 80,443,2194,2403,5006,24038:24042 -j ACCEPT
ip6tables -A INPUT -i eth0 -d 2a03:4000:x:y::1 -p udp -m multiport --dport 500,5006,24037 -j ACCEPT
ip6tables -A INPUT -i eth0 -d 2a03:4000:x:y::2 -p tcp --dport 443 -j ACCEPT
ip6tables -A FORWARD -i eth0 -p tcp -d 2a03:4000:a:b::1 -m multiport --dport 53,8080 -j ACCEPT
ip6tables -A FORWARD -i eth0 -p udp -d 2a03:4000:a:b::2 --dport 53 -j ACCEPT
ip6tables -A FORWARD -i eth0 -p tcp -d 2a03:4000:a:b::3 --dport 53 -j ACCEPT
ip6tables -A FORWARD -i eth0 -p udp -d 2a03:4000:a:b::4 --dport 53 -j ACCEPT
ip6tables -A FORWARD -i eth0 -p tcp -d 2a03:4000:a:b::5 -m multiport --dports 80,443,8080 -j ACCEPT
ip6tables -A FORWARD -i eth0 -p tcp -d 2a03:4000:a:b::6 -m multiport --dports 80,853 -j ACCEPT
Display More
Naja, ob dir das weiterhilft? Ich nutze Ubuntu mit netplan, LXD und Wireguard.
Warum denkst du, dass das nicht weiter hilft?
Es gibt sehr viele User, die genau diese Zeilen brauchen um ihr System zu verstehen.
Das sind "praktische" Beispiele. Ja, da wird auch mal der eine oder andere VPS mit Docker gehackt, da ein "Halbwissen" der Firewall angesetzt.
Aber da lernt jeder draus und macht das sicher nicht noch einmal.
Jemandem zu schreiben, wo er wie und was finden kann.... Eine direkte Lösung und wenn man es schon 1000x geschrieben hat. Ein Dozent oder Lehrer wiederholt seinen Stoff auch immer wieder, weil es immer wieder User gibt, die mit dem Stoff erst anfangen.
Stell dir vor, dein Lehrer hätte zu dir gesagt, dass du dich an das Vorjahr wenden möchtest, die haben das schon mal gemacht -
Deine IP6TABLES sind nicht weit von meinen entfernt. UFW ist aber ein einfacheres Werkzeug für die Console.
LXD - Da gibt es noch keine Berührungspunkte. Nutze Docker über die Console.
Liegt vielleicht daran, dass es GUIs für Docker noch nicht gab als ich mit Docker anfing.
Daher bin ich mir auch ganz sicher, dass mein VPS mit VPN "dicht" ist.
Da geht weder was rein noch raus. Wenn der VPN klemmt geht es nur noch über die Netcup root Console.
Jemandem zu schreiben, wo er wie und was finden kann.... Eine direkte Lösung und wenn man es schon 1000x geschrieben hat.
Naja blindes Abtippen fördert nicht gerade das Lernen und sich mit dem Stoff zu beschäftigen und ihn zu verstehen, fördert auch die notwendigen Skills sich z.B. durch Google selbst zu helfen.
Ein Dozent oder Lehrer wiederholt seinen Stoff auch immer wieder, weil es immer wieder User gibt, die mit dem Stoff erst anfangen.
Wir sind hier weder Dozent noch Lehrer und die meisten hier werden weder einen didaktischen noch pädagogischen Hintergrund haben.
Wir sind hier in unsere Freizeit um Usern zu helfen - und das tuen wir im Gegensatz zu Lehrern unentgeltlich.
Ja, da wird auch mal der eine oder andere VPS mit Docker gehackt, da ein "Halbwissen" der Firewall angesetzt.
Aber da lernt jeder draus und macht das sicher nicht noch einmal.
Oft wird aber auch die Schuld beim Provider gesucht und der "Lerneffekt" fällt komplett aus. (Wieso sperrt Netcup meine Server?)
So ein gehackter Server ist auch nicht gut für die IP Netze, wenn du bspw. E-Mail Server betreibst - darum ist es im Sinne aller Forenhelfer, dass ein gehackter Server eigentlich nicht passiert. Bei abgetippten Beispielen ist die Wahrscheinlichkeit aber sehr hoch, du bekommst die Lösung ja auf dem Silbertablett, wieso also noch selbst mit dem Thema beschäftigen.
Das merkt man hier im Forum leider sehr häufig in den Ferienzeiten, oder wenn man mal die Forensuche nach Windows bemüht. Einige werden halt leider vom niedrigen Preis angelockt, ohne zu verstehen, dass das nicht wie ein Computer zu Hause ist und man sich selbst um die Firewall etc. bemühen muss.
LXD - Da gibt es noch keine Berührungspunkte. Nutze Docker über die Console.
Liegt vielleicht daran, dass es GUIs für Docker noch nicht gab als ich mit Docker anfing.
LXD ist keine GUI für Docker (verwechselst du das gerade mit LXDE?) LXD ist eine Konsolenanwendung zur Verwaltung von LXC Containern.
Es gibt sehr viele User, die genau diese Zeilen brauchen um ihr System zu verstehen.
Da stimme ich H6G zu. Die Konfiguration eines anderen Systems hilft nicht weiter. Die typischen Howtos aus dem Internet funktionieren auch immer nur für den einen spezifischen Fall. Sobald man was anpassen muss, hat man ohne Grundlagenkenntnisse verloren. Deshalb schrieb ich oben, beschäftige dich mit IP Routing. Dann kommt die Frage nicht auf, wie das zusätzliche Subnetz von eth0 ins System kommt. Und für die Beantwortung dieser Frage helfen dir meine Konfig Auszüge nicht im Geringsten.
UFW ist aber ein einfacheres Werkzeug für die Console.
Das sehe ich komplett anders. Meines Erachtens ist UFW eine Katastrophe, und vor allem im Zusammenspiel mit Docker für Anfänger absolut ungeeignet. Dann hat man schon 2 Tools, die unkontrolliert in den iptables Chains rumfurwerken, was am Ende dazu führt, dass sämtliche Container komplett ungeschützt im Internet hängen. Pakete wie "ufw-docker" sollen helfen, machen es nicht besser, da hatten wir erst kürzlich einen Fall (wo es am Ende auch an den Routing Grundlagen gescheitert ist). Bei mir laufen Docker Container nur innerhalb eines lxd Containers, da kann Docker sich in den Firewalls austoben, wie es will. Den lxd Container erreicht nur das, was ich vorher dahin durchlasse. Und bei mir ist die iptables Liste komplett manuell gepflegt, ohne Zusatztools.
Es nützt nichts, man muss verstehen, was man tut. Da helfen fertige Konfig Dateien nicht weiter. Anleitungen lesen, verstehen, auf die eigene Situation adaptieren und dann umsetzen, das empfehle ich bei jeder Gelegenheit. Ja, ist nicht bequem und kostet Zeit, aber ist der einzige Weg, wenn man nicht 5-stellige Summen als Schadensersatz für gehackte Server riskieren will.
Ich stimme zu, dass blindes Abtippen in fast allen Fällen eher kontrproduktiv und vielleicht sogar gefährlich ist.
Ich persönlich finde es aber äußerst hilfreich, eine (funktionierende) Beispielkonfiguration zu analysieren und daraus eine für mich passende abzuleiten.
Das hilft mir meist mehr als irgendeiner verbalen Beschreibung zu folgen.
Dazu kommt, dass ich kein Netzwerk/Routing-Experte bin.
Ich habe begrenzte Erfahrung auf allen Ebenen des OSI Modells und verbringe beruflich leider zu viel Zeit auf Layer 8.
Meist scheitert es weniger am generellen Verständnis als daran, es in der richtigen Syntax in den System zu konfigurieren...
Display MoreHallo Netcup Gemeinde.
Hab da "eigentlich" ein simples Problem, bei dem ich aber irgendwie auf dem Schlauch stehe.
Auf einem VPS läuft Docker, dessen Container per IPv6 ONLY extern erreichbar sein sollen.
Der VPS hat ein IPv6 Präfix von Netcup bekommen (z.B. 1234:1234:1234:1234::/64).
Unter Docker ist ein Network mit IPv6 eingerichtet, 1234:1234:1234:1234:abcd:abcd:abcd:0/112
Ein erster Container bekommt die IPv6 1234:1234:1234:1234:abcd:abcd:abcd:1000. Dieser läßt sich einwandfrei anpingen.
Zu Testzwecken ist jegliche Firewall mal deaktiviert.
Das ETH0 hat die IPv6 1234:1234:1234:1234:0123:0123:0123:0123/64.
Von Extern komme ich nicht auf den Docker Container, auch kein Ping. Als würde es ihn nicht geben.Jetzt werde ich den Verdacht nicht los, dass mir da ein Routing zwischen ETH0 und dem Docker Network fehlt.
Ein HOST Network möchte ich nicht, da der Container seine eigen IPv6 bekommen soll.
Bitte keine Vorschläge zu IPv4 und Portforwarding und warum, wieso kein IPv4 etc.etc.
Es MUSS IPv6 Only sein!
DANKE für die vielen Beiträge hier.
Meine Frage ist mehr als beantwortet.
Bin an dieser Stelle jetzt raus.
Gruß
Bin an dieser Stelle jetzt raus.
schade, ich hätte noch gerne Deine IPv6 routingkünste in einem IPv4 tunnel anhand eines traceroutes gesehen.
Wenn die Dienste wirklich IPv6 nutzen, fließen sie am VPN vorbei. Darauf hatte ich ja oben schon aufmerksam gemacht. Das würde mir zu denken geben, denn wenn sie funktionieren, heißt das, dass sich die Systeme gegenseitig übers Internet erreichen können. Was bedeuten könnte, dass sie auch für jeden anderen erreichbar sind.
Da stimme ich H6G zu. Die Konfiguration eines anderen Systems hilft nicht weiter. Die typischen Howtos aus dem Internet funktionieren auch immer nur für den einen spezifischen Fall. Sobald man was anpassen muss, hat man ohne Grundlagenkenntnisse verloren.
schade, ich hätte noch gerne Deine IPv6 routingkünste in einem IPv4 tunnel anhand eines traceroutes gesehen
Seit ihr jetzt mit eurer Lästerei durch?
Es funktioniert und im Inet kann man nachlesen warum das so ist. Beispielzeilen sind ja hier nicht erwünscht.
Ich stimme zu, dass blindes Abtippen in fast allen Fällen eher kontrproduktiv und vielleicht sogar gefährlich ist.
Naja blindes Abtippen fördert nicht gerade das Lernen und sich mit dem Stoff zu beschäftigen und ihn zu verstehen
Wenn die Dienste wirklich IPv6 nutzen, fließen sie am VPN vorbei. Darauf hatte ich ja oben schon aufmerksam gemacht. Das würde mir zu denken geben, denn wenn sie funktionieren, heißt das, dass sich die Systeme gegenseitig übers Internet erreichen können. Was bedeuten könnte, dass sie auch für jeden anderen erreichbar sind.
Wenn du gelesen hättest, was ich geschrieben habe, dann würdest du obiges nicht schreiben brauchen.
Aber es kann ja nicht funktionieren was nicht funktionieren darf oder was man glaubt zu wissen, das es nicht funktionieren kann.
Ich bezweifle, dass du den Sinn der Posts verstanden hast. Es geht hier nicht um die allgemeine Funktionalität deines Konstrukts, sondern um eventuelle Fehler. Und Lästerei konnte ich auch nicht erkennen.
Das sehe ich komplett anders. Meines Erachtens ist UFW eine Katastrophe, und vor allem im Zusammenspiel mit Docker für Anfänger absolut ungeeignet.
Wie ich schon geschrieben habe, wenn's denn einer gelesen hat, ist das System KOMPLETT dicht!
Da geht nix rein oder raus, auch kein Ping und kein Pong. Nach dem Motto: Gibt es die IP überhaupt?
UFW ist ein super Consolen Werkzeug. Man sollte es nicht in der Standard Konfiguration nutzen.
Also erst einmal ALLE Regeln raus und nur das bearbeiten was man WIRKLICH braucht.
Nach >20 Jahren IPTABLES macht UFW vieles einfacher.
Übrigens ist eines Standard bei mir:
Docker installieren und alle Regeln aus UFW und Iptables raus, aber wirklich alle!
IN and OUT drop ALL!
schade, ich hätte noch gerne Deine IPv6 routingkünste in einem IPv4 tunnel anhand eines traceroutes gesehen.
Es wäre jetzt echt nicht gut hier Zeilen reinzuschreiben, welche stumpf übernommen werden könnten.
Da ist es doch sinnvoller sich mit der Materie zu beschäftigen und selber herauszufinden wie es geht.
Es funktioniert und im Inet kann man nachlesen warum das so ist. Beispielzeilen sind ja hier nicht erwünscht.
Polemik hat am Ende noch nie weitergeholfen. Und beachte bitte den Kontext, in dem Aussagen getätigt werden. Haufenweise Konfigs als Lehrstoff sind nicht zielführend, aber zur Fehleranalyse sind sie unerlässlich. Hier sollte man differenzieren.
UFW ist ein super Consolen Werkzeug. Man sollte es nicht in der Standard Konfiguration nutzen.
Also erst einmal ALLE Regeln raus und nur das bearbeiten was man WIRKLICH braucht.
Nach >20 Jahren IPTABLES macht UFW vieles einfacher.
Mit der Aussage gehe ich überhaupt nicht mit. ufw kann vieles einfacher machen, eben durch die Default Regeln, die es mitbringt, vor allem für Anfänger. An die Grenzen kommt man dann, wenn weitere Frameworks ufw in die Regeln grätschen, z.B. Docker. Aber erst mal alles löschen und dann selber machen sollte man mit ufw auf keinen Fall, dann kann man auch direkt iptables oder nftables nutzen, das ist deutlich schlanker. Leute mit 20 Jahren iptables Erfahrung würden den Weg jedenfalls nicht gehen, soviel ist sicher.
Wie ich schon geschrieben habe, wenn's denn einer gelesen hat, ist das System KOMPLETT dicht!
Da geht nix rein oder raus, auch kein Ping und kein Pong. Nach dem Motto: Gibt es die IP überhaupt?
Dann fließen die Daten nicht über IPv6. Denn durch den Tunnel fließen keine IPv6 Daten, soviel ist sicher.
Also eine deiner Aussagen stimmt nachweislich nicht:
Du darfst uns jetzt eines Besseren belehren. Gerne mit Konfigurationsdateien und Pakettraces.
Du darfst uns jetzt eines Besseren belehren. Gerne mit Konfigurationsdateien und Pakettraces.
nö...
Lass gut sein - Bringt hier nichts mehr
Diskutiere nicht über etwas, was nicht seinen soll oder darf.
Dir ist klar, dass dein Verhalten bei uns nur einen Schluss zulässt? Also, nutze die Chance, und zu erklären, was genau bei dir passiert ist. Auch wenn sich herausstellt, dass es kein IPv6 über VPN war, ist das nichts wofür man sich schämen müsste. Nur ein wichtiger Hinweis für alle, die sich mit solchen Themen befassen.