Der Threadersteller hat aber hier geschrieben, dass in dem Tunnel / auf dem Tunnel Interface nur 10.0.0.0/8 Adressen liegen und darüber irgendwie auf die IPv6 Adressen auf dem docker0 interface / respektive die container interfaces routet.
Genau das schreibt er. Deshalb meine Befürchtung, dass die Daten am Tunnel vorbeifließen.
Es geht hier nicht darum, jemanden niederzumachen. Aber vielleicht ist da irgendwo eine Sicherheitslücke, über die er sich nicht bewusst ist.
Kann es sein, dass dir selber die Erfahrung fehlt und du hier Informationen abgrasen willst?
Ich arbeite mit Linux seit Mitte der 90er. Ob das dann fehlende Erfahrung ist, weiß ich nicht. Aber Informationen will ich abgrasen, das stimmt.
Wie kann jemand Lösungen finden bei etwas was nicht sein darf, weil es mit deiner Erfahrung nicht sind kann.
Ich will keine Lösung finden, mich interessiert, wie du es gelöst hast.
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.
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.
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.
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.
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:clxc 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/128Einige 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 ACCEPTDann 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.
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?
Nicht aus dem Nichts. Sie werden auf die Standard IPv6 deines Servers geroutet, also das mitgelieferte /64 Prefix + EUI-64 Interface-ID. Ausgehend einfach übers Default Gateway. Steht auch alles im Wiki.
Dann beschreib doch mal den kürzesten Weg ein /64er gerouteten Block (z.B. 1234:1234:1234:1234::/64) von ETH0 auf Docker zu legen.
Die Frage macht so keinen Sinn. Du legst vom zusätzlichen Subnetz nichts auf eth0. Du benutzt die Adressen einfach für die Container, aktivierst IP Forwarding und sorgst für ein sauberes Firewall und Routen Setup. Besonders die Firewall ist wichtig, das Netz hängt frei im Internet.
Also muss es doch eine Möglichkeit geben EINWANDFREI über IPv6 Internet<-->Container zu arbeiten.
Das kommt halt drauf an, wie der Hoster es umsetzt. Wenn das /64 auf deinen VPS geroutet wird, ist das kein Problem. Aber in dieser geswitchten Umgebung bei Netcup musst du das NDP Problem lösen, und das ist bislang nicht abschließend gelungen.
Ein geroutetes Subnetz für genau diesen Fall gibt es bei Netcup in Form eines zusätzlichen /64. Das nutze ich auch dafür, das geht absolut einwandfrei.
Jetzt fehlt noch das I-Tüpfelchen, dass der Container die IPv6 zurück gibt, mit der er angesprochen wurde.
Was meinst du mit IP zurückgeben?
Die Protokolle sagen aber etwas anderes -
Welche Protokolle? Zeige gern anonymisierte Beispiele.
Und wenn es direkt im Inet verfügbar wäre, wozu dann VPN -
Du solltest dir eher die Frage stellen, warum es ohne VPN klappen kann, wenn die Dienste eigentlich nicht öffentlich verfügbar sein sollten.
Was für mich aus den Beiträgen noch nicht so ganz klar geworden ist: Wie kommt es zu dem Paketverlust?
Das wissen wir leider nicht genau. Spätestens die Pings sollten die MAC Tabellen in den Switches aktuell halten.
Was würde einen anderen Netcup-Kunden daran hindern eine Solicitation nach meiner IP-Adresse als erstes zu beantworten?
Theoretisch ist das möglich. Inwiefern anschließend eine erfolgreiche Datenübertragung stattfindet, müsste man sich mal näher ansehen.
Wenn du Endpunkte über IPv6 miteinander reden lässt, fließen die Daten nicht durch den VPN Tunnel. Der überträgt ausschließlich IPv4 Daten. Lass dich nicht vom IPv6 Endpunkt täuschen. Die Payload im Tunnel ist ausschließlich IPv4.
Heißt auch: Wenn du Daten über IPv6 erfolgreich übertragen kannst, sind die Dienste direkt im Internet verfügbar und für die ganze Welt aufrufbar.
Nur als Hinweis: Das wird nicht dauerhaft stabil funktionieren. Es wird immer wieder zwischendurch zu Paketverlusten kommen. Ich empfehle die verlinkten Threads für die Beschreibung weiterer Maßnahmen, die das Problem lindern, aber nicht vollständig lösen. 100% Zuverlässigkeit erreicht man nur mit einem zusätzlichen IPv6 Netz.
Wie gesagt, das Vorgehen erlaubt es dir nicht, festzulegen, welche IP dein Container ausgehend benutzt. Bei TCP Verbindungen wird die Antwort vermutlich mit der IP gesendet, über die die Anfrage reinkam. Aber bei verbindungslosen Daten oder Verbindungsaufbauten aus dem Container heraus, wird die Standard-IP des Servers benutzt.
Zu empfehlen ist auch, dass auf dem Host nichts auf Port 80 und 443 läuft.
Das kann man ja gezielt steuern, an welche IP ein Server sich klemmt.
Das Thema hatten wir doch gerade erst. Siehe #2:
Dafür brauchen wir erheblich mehr Informationen. Betriebssystem, Netzwerkeinstellungen, Firewall (Server und Client).
Im Moment ist ja noch nicht mal klar, ob die Ping Pakete deinen Client überhaupt verlassen konnten, geschweige denn, wo sie ankommen könnten.
