nein, wenn die tunnelendpunkte kein IPv6 haben kannst da kein IPv6 drüberrouten!
Confi Client:
[Interface]
PrivateKey = blablabla
Address = 10.1.1.2/32
DNS = IPv6
[Peer]
PublicKey = blablabla
PresharedKey = blablabla
AllowedIPs = ::/0
EndPoint = IPv6.domain.de:123456
Confi Server:
[Interface]
Address = 10.1.1.1/24
ListenPort = 123456
PrivateKey = blablabla
[Peer]
PublicKey = blablabla
PresharedKey = blablabla
AllowedIPs = 10.1.1.2/32
Und was darf jetzt nicht funktionieren was doch funktioniert?
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.
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.
Die Protokolle sagen aber etwas anderes -
Und wenn es direkt im Inet verfügbar wäre, wozu dann VPN -
Du vermisst da etwas?
Address = 10.1.1.2/32, fd32::/128
Display MoreHier nun die "Quicky" Version um Docker Container über IPv6 Only aus dem /64 Block exclusive zugänglich zumachen.
Diese Lösung ist "noch nicht ganz sauber", d.h. für ausgehende Verbindungen wird zufällig eine der IPv6 von ETH0 genommen. Läst sich dann aber über IP6TABLES weiter einstellen. Zu empfehlen ist auch, dass auf dem Host nichts auf Port 80 und 443 läuft.
Datei erstellen --> /etc/network/interface.d/60-docker-ipv6-init.cfg
iface eth0 inet6 static
address Präfix:1234:1234:1234:1111/64
gateway fe80::1
iface eth0 inet6 static
address Präfix:1234:1234:1234:2222/64
gateway fe80::1
Firewall UFW einstellen:
- ufw allow from any to Präfix:1234:1234:1234:1111 port 80
- ufw allow from any to Präfix:1234:1234:1234:1111 port 443
- ufw allow from any to Präfix:1234:1234:1234:2222 port 80
- ufw allow from any to Präfix:1234:1234:1234:2222 port 443
Docker Container initialisieren und starten:
- docker run -d --name test1 -p Präfix:1234:1234:1234:1111:80:80 -p Präfix:1234:1234:1234:1111:443:443 -v /docker/test1/html:/usr/local/apache2/htdocs httpd
- docker run -d --name test2 -p Präfix:1234:1234:1234:2222:80:80 -p Präfix:1234:1234:1234:2222:443:443 -v /docker/test2/html:/usr/local/apache2/htdocs httpd
Jetzt fehlt noch das I-Tüpfelchen, dass der Container die IPv6 zurück gibt, mit der er angesprochen wurde.
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.
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?
Was meinst du mit IP zurückgeben?
Vergiss es, was Blödsinn 
Das Ding mit der IPv6 direkt zum Container.... Da hatte mich ein "VPS" von I0N0S drauf gebracht. Die lassen ihre "miniVPS" unter Docker laufen.
Also muss es doch eine Möglichkeit geben EINWANDFREI über IPv6 Internet<-->Container zu arbeiten.
Um mal meine Vorstellung noch etwas zu detaillieren:
So etwas hätte ich gerne!
Evtl. sogar die kürzere Variante 
Ziel wäre dann das Ergebnis:
Da hatte mich ein "VPS" von I0N0S drauf gebracht. Die lassen ihre "miniVPS" unter Docker laufen.
Komisch, ich dachte immer die nutzen LXC, LXD oder Virtuozzo.
Ziel wäre dann das Ergebnis:
Und das funktioniert gerade nicht?
Dann musst du wohl von oben anfangen: https://forum.netcup.de/admini…s-docker-ipv6/#post228377
Alternativ funktionieren auch die ip neighbor Tools vom Betriebssystem.
Habe jetzt in anderen Foren meine Lösung gefunden und leider nicht hier.
Danke für.... naja, was denn eigentlich
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.
Du vermisst da etwas?
Address = 10.1.1.2/32, fd32::/128
genau, bzw besser so etwas:
[Interface]
Address = 192.168.7.1/24,fd42:42:42::1/64magst Du vielleicht bitte mal einen traceroute von Deinem client zu einem container zeigen?!
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.
Ich bin ein großer Freund von IPv6 Only. Ist die Zukunft vom Inet.
Wenn das bei Netcup kein geroutetes IPv6 ist, was haben die dann da für eine dusslige Lösung gebastel?
Warum zerbreche ich mir dann eigentlich den Kopf, wenn es von Netcup eine einfache Lösung gibt -
Wo und wie und für was bekommt man das?
Komisch, ich dachte immer die nutzen LXC, LXD oder Virtuozzo.
Nun, I0N0S war mal einunseins und die gibt es nicht erst seit gestern -
Es war nun mal üblich die vielen kleinen VPS unter Docker anzubieten (512MB, 10GB).
Wo und wie und für was bekommt man das?
Jepp... just in this moment hat's der große Hahn ausgespuckt
Warum zerbreche ich mir dann eigentlich den Kopf, wenn es von Netcup eine einfache Lösung gibt -
Wo und wie und für was bekommt man das?
stand im zweiten post:
Eine wirklich saubere Lösung erreichst du nur mit einem zusätzlichen IPv6 Subnetz, welches auf deinen Server geroutet wird.
stand im zweiten post:
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.
Meinen kurzen Weg über Interfaces und ufw habe ich beschrieben.
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.
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.
Das heißt, die Daten kommen aus dem Nichts und landen im Docker Container?
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.
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.
...und das mitgelieferte /64 Präfix liegt am Interface eth0 an?
Wiki - Könnte man auch beim großen Hahn finden, oder?
