VPS Docker IPv6

Zitat von netsch1967

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.

Zitat von netsch1967

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.

Mich würde auch interessieren, wie man IPv6 Traffic über ein VPN interface (tun0, wg0 etc. pp.) routet wo im Tunnel selber nur Adressen aus dem 10.0.0.0/8 Netz verwendet werden. Insbesondere wie sieht hier die Routing table aus?

Wäre dann ja etwa sowas:

2a03:4000:bla1:bla1::0/64 via 10.0.0.1 metric 1000 dev tun0

tunnel mode ipv6ip / 6to4 ?

Zitat von saremox

Mich würde auch interessieren, wie man IPv6 Traffic über ein VPN interface (tun0, wg0 etc. pp.) routet wo im Tunnel selber nur Adressen aus dem 10.0.0.0/8 Netz verwendet werden. Insbesondere wie sieht hier die Routing table aus?

Wäre dann ja etwa sowas:

2a03:4000:bla1:bla1::0/64 via 10.0.0.1 metric 1000 dev tun0

IPv4 und IPv6 sind zwei unterschiedliche Protokolle die zueinander inkompatibel sind. Das kannst du dir etwa wie ein Schienenfahrzeug und ein Auto vorstellen.

Das Auto kann auf der Schiene nicht fahren und der Zug hat Probleme auf der Autobahn. Beide fahren jedoch auf dem Erdboden (Layer 2, bspw. Ethernet) und beide transportieren Menschen und Waren (Layer 4, bspw. TCP und UDP), Komisches Beispiel, aber naja.

Im Endeffekt braucht jeder Teilnehmer im Tunnel und jeder Tunnelendpunkt eine IPv6 Adresse, vergleichbar mit dem 10.0.0.0/8 Netz. Dabei bieten sich bspw. fc00::/7 Blöcke an, es können aber auch öffentliche Präfixe benutzt werden.

Die Routingtabelle sieht dann entsprechend so aus:

fd00:68::2 via fd00:68::1 metric 1000 dev tun0

Zitat von H6G

IPv4 und IPv6 sind zwei unterschiedliche Protokolle die zueinander inkompatibel sind. Das kannst du dir etwa wie ein Schienenfahrzeug und ein Auto vorstellen.

Das Auto kann auf der Schiene nicht fahren und der Zug hat Probleme auf der Autobahn. Beide fahren jedoch auf dem Erdboden (Layer 2, bspw. Ethernet) und beide transportieren Menschen und Waren (Layer 4, bspw. TCP und UDP), Komisches Beispiel, aber naja.

Im Endeffekt braucht jeder Teilnehmer im Tunnel und jeder Tunnelendpunkt eine IPv6 Adresse, vergleichbar mit dem 10.0.0.0/8 Netz. Dabei bieten sich bspw. fc00::/7 Blöcke an, es können aber auch öffentliche Präfixe benutzt werden.

Die Routingtabelle sieht dann entsprechend so aus:

fd00:68::2 via fd00:68::1 metric 1000 dev tun0

Das ist mir bewusst. 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. So zumindest bisher meine Interpretation des hier geschriebenen.

Der Threadersteller hat auch mehrfach jetzt geschrieben das es funktioniert in einen IPv4 only VPN tunnel IPv6 traffic zu routen. Deswegen die Frage wie das laut Threadersteller funktioniert. Mir ist zumindest keine Möglichkeit bekannt das ohne den von dir beschriebenen Weg zu bewerkstelligen.

Zitat von netsch1967

Es wäre jetzt echt nicht gut hier Zeilen reinzuschreiben, welche stumpf übernommen werden könnten.

den unterschied zwischen konfiguration (wireguard config) und ergebnis (traceroute) vermagst Du offensichtlich nicht zu erkennen.

ich wäre wirklich daran interessiert wie man IPv6 über einen IPv4 tunnel drüberbekommt. leider kamen von Dir dbzgl weder stichhaltige beweise noch entsprechende config snippets.

Zitat von aRaphael

tunnel mode ipv6ip / 6to4 ?

vielleicht, wissen wir nicht, hat er ja nichtmal in seinem sermon beschrieben.

wäre aber umständlich, ginge ja viel einfacher wenigstens eine ULA ans interface zu pappen.

Zitat von saremox

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.

Ich habe mir vor einiger Zeit ein Netzwerksetup eingerichtet um es zu untersuchen und besser zu verstehen. Ein IPv6-only Tunnel verbindet hier zwei IPv4-Netze. Vielleicht gibt das einen Ansatz, dass es möglich ist IPv4 durch einen IPv6-only Tunnel zu routen. Im Thread hier ging es zwar um die andere Richtung IPv6 durch einen IPv4-only Tunnel zu routen, aber das dürfte darauf gut übertragbar sein.

Vielleicht kann ich damit der Diskussion einen sinnvollen Beitrag geben. Ich kam noch nicht wirklich dazu mir dieses Netzwerksetup genauer anzusehen und mit über Vor- und Nachteile Gedanken zu machen. Falls wir mehr darüber diskutieren wollen kann ich gerne einen neuen Thread aus diesem Beitrag machen.

❯ ip a
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e6:f3:32:fe:2f:ee brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    inet 192.168.1.2/24 brd 192.168.1.255 scope global ens4
       valid_lft forever preferred_lft forever
    inet6 fd6b:96ee:1f2b:1::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::e4f3:32ff:fefe:2fee/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet6 fe80::1/64 scope link
       valid_lft forever preferred_lft forever

❯ ip route
default via (public IPv4) dev ens3 proto static
(public IPv4-network)/22 dev ens3 proto kernel scope link src (public IPv4)
192.168.0.0/16 via inet6 fe80::2 dev wg0 proto static src 192.168.1.2
192.168.1.0/24 dev ens4 proto kernel scope link src 192.168.1.2

❯ wg
interface: wg0
  public key: X0C6aNL5FfJv6g2FPmc29+kqwxxbRMegbKnyOiGCrjg=
  private key: (hidden)
  listening port: 51820

peer: 6CZxdkiS0KRi3Mbth9Fmg9MqTbP+30MoMy0DGHeLd0g=
  preshared key: (hidden)
  allowed ips: 0.0.0.0/0, fd00::/8, fe80::/64

Das Interface ens4 ist einem vlan bei Netcup zugeordnet. Der Host 192.168.1.4, der später noch auftaucht, ist auch Teil dieses vlan.

❯ ip a
2: enu1u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b8:27:eb:9d:d9:d4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.3/24 brd 192.168.2.255 scope global enu1u1
       valid_lft forever preferred_lft forever
    inet6 (public IPv6) scope global
       valid_lft forever preferred_lft forever
    inet6 fd6b:96ee:1f2b:2::3/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe9d:d9d4/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet6 fe80::2/64 scope link
       valid_lft forever preferred_lft forever

❯ ip route
default via 192.168.2.1 dev enu1u1 proto static
192.168.1.0/24 via inet6 fe80::1 dev wg0 proto static
192.168.2.0/24 dev enu1u1 proto kernel scope link src 192.168.2.3
❯ wg
interface: wg0
  public key: 6CZxdkiS0KRi3Mbth9Fmg9MqTbP+30MoMy0DGHeLd0g=
  private key: (hidden)
  listening port: 59230

peer: X0C6aNL5FfJv6g2FPmc29+kqwxxbRMegbKnyOiGCrjg=
  preshared key: (hidden)
  endpoint: (netcup RS IPv6):51820
  allowed ips: 0.0.0.0/0, fd00::/8, fe80::/64

❯ tracepath 192.168.2.1
 1?: [LOCALHOST]                      pmtu 1420
 1:  192.168.2.3                                          27.844ms
 1:  192.168.2.3                                          22.265ms
 2:  192.168.2.1                                          23.437ms reached
     Resume: pmtu 1420 hops 2 back 2

❯ tracepath 192.168.1.4 -n
 1?: [LOCALHOST]                      pmtu 1420
 1:  192.168.1.2                                          27.543ms
 1:  192.168.1.2                                          25.709ms
 2:  192.168.1.4                                          18.525ms reached
     Resume: pmtu 1420 hops 2 back 2

❯ tracepath 192.168.2.1 -n
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.2                                           0.481ms
 1:  192.168.1.2                                           0.328ms
 2:  192.168.1.2                                           0.387ms pmtu 1420
 2:  192.168.2.3                                          19.011ms
 3:  192.168.2.1                                          23.448ms reached
     Resume: pmtu 1420 hops 3 back 3

❯ tracepath 192.168.1.4
 1?: [LOCALHOST]                      pmtu 1420
 1:  192.168.2.3                                           0.997ms
 1:  192.168.2.3                                           0.823ms
 2:  192.168.1.2                                          26.869ms
 3:  192.168.1.4                                          19.053ms reached
     Resume: pmtu 1420 hops 3 back 3

Zitat von femur

Vielleicht gibt das einen Ansatz, dass es möglich ist IPv4 durch einen IPv6-only Tunnel zu routen.

Das ist kein reiner IPv6 Tunnel. Du hast lediglich kein dediziertes IPv4 Transportnetz spezifiziert. Das klappt aber nur für reine LAN-LAN Setups, nicht für Roadwarrior. AVM macht das auch so für enige Setups. Aber im Tunnel Setup erlaubst du IPv4 Netze, und das ist der Unterschied zu oben. Dort werden keine IPv6 Adressen im Tunnel erlaubt. Deshalb können dort keine IPv6 Daten fließen.

Zitat von femur

192.168.0.0/16 via inet6 fe80::2 dev wg0 proto static src 192.168.1.2

192.168.1.0/24 dev ens4 proto kernel scope link src 192.168.1.2

Das ist im Grunde ein katastrophaler Fehler, denn die Netze überschneiden sich. Du hast Glück, dass die Maske auf ens4 kleiner ist, deshalb funktioniert es. Aber es ist extrem unsauber, und sobald sich Metriken ändern, geht das richtig schief.

Zitat von femur

allowed ips: 0.0.0.0/0, fd00::/8, fe80::/64

Du hast auf beiden Seiten 0.0.0.0/0 in der Konfig. Würdest du mit einem Transportnetz arbeiten, würde das auf beiden Seiten das Internet komplett abklemmen. So taucht die Default Route dann nicht in der Übersicht auf. Entfernst du sie manuell? Die Zielrouten setzt du ja auch manuell. Geschickt ist es trotzdem ncht, da der Fokus des Tunnels nicht eingeschränkt wird.

Warum hast du auf dem externen Interface des RS eine ULA Adresse?

Zitat von frank_m

Das ist kein reiner IPv6 Tunnel. Du hast lediglich kein dediziertes IPv4 Transportnetz spezifiziert. Das klappt aber nur für reine LAN-LAN Setups, nicht für Roadwarrior. AVM macht das auch so für enige Setups. Aber im Tunnel Setup erlaubst du IPv4 Netze, und das ist der Unterschied zu oben. Dort werden keine IPv6 Adressen im Tunnel erlaubt. Deshalb können dort keine IPv6 Daten fließen.

Du hast auf beiden Seiten 0.0.0.0/0 in der Konfig. Würdest du mit einem Transportnetz arbeiten, würde das auf beiden Seiten das Internet komplett abklemmen. So taucht die Default Route dann nicht in der Übersicht auf. Entfernst du sie manuell? Die Zielrouten setzt du ja auch manuell. Geschickt ist es trotzdem ncht, da der Fokus des Tunnels nicht eingeschränkt wird.

Ich hätte den Tunnel als IPv6-only Tunnel bezeichnet, weil die Tunnel-Interfaces selbst keine IPv4-Addressen zugewiesen haben. Natürlich hast du Recht, dass sehr wohl IPv4-Pakete darüber laufen. Der Tunnel sollte weiter eingeschränkt werden, das stimmt. Dieses Setup habe ich mal "auf die Schnelle" konfiguriert und ist nicht fertig. Die Routen sind alle manuell konfiguriert, deshalb gibt es auch keine Default-Route. Die wäre in diesem Fall sowieso sehr kontraproduktiv, vor allem so wie der Tunnel aktuell konfiguriert ist.

Zitat von frank_m

Das ist im Grunde ein katastrophaler Fehler, denn die Netze überschneiden sich. Du hast Glück, dass die Maske auf ens4 kleiner ist, deshalb funktioniert es. Aber es ist extrem unsauber, und sobald sich Metriken ändern, geht das richtig schief.

Das habe ich tatsächlich mit Absicht so gemacht. Die spezifischere Route /24 geht doch immer vor die weniger spezifische Route /16. Die Metrik greift erst später nach meinem Verständnis.

Zitat von frank_m

Warum hast du auf dem externen Interface des RS eine ULA Adresse?

Das ist ein VLAN-Interface, deshalb ist da eine ULA-Addresse drauf. Auf dem externen sind natürlich nur die externen, global routable Addressen drauf.

Zitat von femur

Die Routen sind alle manuell konfiguriert, deshalb gibt es auch keine Default-Route.

Normalerweise sorgt Wireguard für Routen, die zu den allowed IPs passen, und da steht 0.0.0.0/0 drin. Vielleicht unterbleibt es, weil keine IPv4 Adresse zugewiesen wurde, das hab ich noch nie ausprobiert. Ist dann aber eher Glück, dass es funktioniert.

Zitat von femur

Die wäre in diesem Fall sowieso sehr kontraproduktiv, vor allem so wie der Tunnel aktuell konfiguriert ist.

Default Route auf beiden Seiten geht niemals. Dann schicken sich die VPN Partner gegenseitig alle Pakete zu, das wird nichts. Mindestens auf einer Seite muss der Weg ins Internet frei sein.

Zitat von femur

Das habe ich tatsächlich mit Absicht so gemacht. Die spezifischere Route /24 geht doch immer vor die weniger spezifische Route /16.

Warum um Himmels willen würde man sowas absichtlich machen? Auf der anderen Seite hast du doch auch die passende Subnetzmaske eingerichtet.