Verständnisfrage IPv6 Route und Tunnelbroker HE
Hallo, ich habe weiterführende Fragen zu meinem letzten Thema siehe hier.
das Netzwerk "C" hat nun endlich den Glasfaseranschluss bekommen und eine FB5590.
Dem Netz habe ich analog den anderen beiden Netzen den Prävix fd00:cccc:: zugeordnet ("Unique Local Addresses (ULA) immer zuweisen" ULA-Präfix manuell festlegen: )
Die Routen in den drei Wireguard Servern entsprechend angepasst.
Nun ist aber folgendes Problem: der ISP am Netzwerk C unterstützt kein IPv6 (ja das gibt es tatsächlich noch).
Die FB5590 hatte ich zunächst mal so wie ausgeliefert auf "IPv6-Unterstützung aktiv ->IPv6-Anbindung ->Native IPv4-Anbindung verwenden" eingestellt.
D.h. die Clienten kriegen eine fd00:cccc:: Adresse zugewiesen und ich kann im LAN die Geräte untereinander auch per IPv6 fd00:cccc:: erreichen.
Was nicht funktioniert von Netzwerk C die Geräte per IPv6 in den Netzwerken A & B zu erreichen, also mit fd00:aaaa und fd00:bbbb - aber von Netzwerk A & B kann ich wiederum die die Geräte in Netzwerk C mit fd00:cccc: erreichen.
Ich habe dann zig mal die Wireguard configs nach Fehlern durchforstet und Routen ergänzt, aber es klappte nicht.
Irgendwann habe ich dann den "6in4" Tunnel aktiviert über Hurricane Electric Berlin, und ab da klappte die Erreichbarkeit von Netzwerk C -> A+B über fd00:aaaa: und fd00:bbbb:
Frage: Liegt es am (Windows) Client, dass dieser Anfragen zu fremden privaten IPv6-Netzen verwirft, wenn er keine öffentliche IPv6 zugeteilt bekommt ? Ich habe an den Routen in den FB/Wireguard nichts geändert.
Die tracert -6 Anfrage in Windows hatte auch überhaupt gar nicht reagiert, also nicht mal 1 hop zur FB.
2. Frage: spricht etwas dagegen den 6in4 Tunnel über HE Berlin laufen zu lassen ?
Was mich stört ist dass logischerweise nun IPv6 Standard ist und alles über HE läuft, denn sobald es eine öffentliche IPv6 gibt, wird das auch zuerst benutzt.
Die Latenz ist natürlich etwas höher, die Geschwindigkeit minimal geringer.
Gibt es sonst Bedenken gegen den Tunnelbroker?
MfG
das Netzwerk "C" hat nun endlich den Glasfaseranschluss bekommen und eine FB5590.
Dem Netz habe ich analog den anderen beiden Netzen den Prävix fd00:cccc:: zugeordnet ("Unique Local Addresses (ULA) immer zuweisen" ULA-Präfix manuell festlegen: )
Die Routen in den drei Wireguard Servern entsprechend angepasst.
Nun ist aber folgendes Problem: der ISP am Netzwerk C unterstützt kein IPv6 (ja das gibt es tatsächlich noch).
Die FB5590 hatte ich zunächst mal so wie ausgeliefert auf "IPv6-Unterstützung aktiv ->IPv6-Anbindung ->Native IPv4-Anbindung verwenden" eingestellt.
D.h. die Clienten kriegen eine fd00:cccc:: Adresse zugewiesen und ich kann im LAN die Geräte untereinander auch per IPv6 fd00:cccc:: erreichen.
Was nicht funktioniert von Netzwerk C die Geräte per IPv6 in den Netzwerken A & B zu erreichen, also mit fd00:aaaa und fd00:bbbb - aber von Netzwerk A & B kann ich wiederum die die Geräte in Netzwerk C mit fd00:cccc: erreichen.
Ich habe dann zig mal die Wireguard configs nach Fehlern durchforstet und Routen ergänzt, aber es klappte nicht.
Irgendwann habe ich dann den "6in4" Tunnel aktiviert über Hurricane Electric Berlin, und ab da klappte die Erreichbarkeit von Netzwerk C -> A+B über fd00:aaaa: und fd00:bbbb:
Frage: Liegt es am (Windows) Client, dass dieser Anfragen zu fremden privaten IPv6-Netzen verwirft, wenn er keine öffentliche IPv6 zugeteilt bekommt ? Ich habe an den Routen in den FB/Wireguard nichts geändert.
Die tracert -6 Anfrage in Windows hatte auch überhaupt gar nicht reagiert, also nicht mal 1 hop zur FB.
2. Frage: spricht etwas dagegen den 6in4 Tunnel über HE Berlin laufen zu lassen ?
Was mich stört ist dass logischerweise nun IPv6 Standard ist und alles über HE läuft, denn sobald es eine öffentliche IPv6 gibt, wird das auch zuerst benutzt.
Die Latenz ist natürlich etwas höher, die Geschwindigkeit minimal geringer.
Gibt es sonst Bedenken gegen den Tunnelbroker?
MfG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1908673536
Url: https://administrator.de/contentid/1908673536
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
3 Kommentare
Neuester Kommentar
Deine "AllowedIPs" Sektion ist in allen 3 Konfigs falsch! Dort wird IPv4 und v6 zusammen aufgeführt. Z.B. Netz C:
Ausserdem hast du mehrere weitere gravierende Konfig Fehler begangen und quasi als "Schrottschuss" alle IP Netze in den Allowed IPs definiert was vollkommen falsch ist.
Beim Responder (Server) werden in den Peers immer nur die Netze definiert dir dort am Peer auch vorhanden sind nicht mehr und nicht weniger.
Bei den reinen Initiators (Clients) wird niemals ein Listen Port definiert.
Außerdem stehen immer nur die Destination (Ziel) Netze bzw. Hosts bei internen IPs in den Allowed IPs die in den Tunnel geroutet werden müssen.
Fehlerhaft ist auch die Mobilclients sich in einen der Initiators einwählen zu lassen. Technisch möglich aber aus VPN nicht optimal. Wenn C dein zentraler Responder ist sollten sich auch nur das die mobilen Clients einwählen.
Mit anderen Worten: Deine 3 Konfigs sind syntaktisch und auch teilweise designtechnischer Murks. Zumindestens die groben Konfig Fehler oben solltest du dringenst beseitigen für ein sauberes Setup. Dann wird auch das VPN internet Routing sauber klappen.
Es hilft immer das Wireguard Tutorial wirklich genau zu lesen. Insbesondere das dortige Beispielsetup was identisch zu deinem ist. Leider ist das trotz Appell wohl unterblieben.
[Interface]
Address = 192.168.99.20, fd08::20/64
PrivateKey = xyz
ListenPort = 51822
# Netz A
[Peer]
PublicKey = zyx
AllowedIPs = 192.168.99.1/32, 192.168.74.0/24, fd08::1/128, fd00:aaaa::/64
# Netz B
[Peer]
PublicKey = qvv
AllowedIPs = 192.168.99.10/32, 192.168.168.0/24, fd08::10/128, fd00:bbbb::/64
# Mobil 1
[Peer]
PublicKey = fgh
AllowedIPs = 192.168.99.21/32, fd08::21/128
usw...
Ausserdem hast du mehrere weitere gravierende Konfig Fehler begangen und quasi als "Schrottschuss" alle IP Netze in den Allowed IPs definiert was vollkommen falsch ist.
Beim Responder (Server) werden in den Peers immer nur die Netze definiert dir dort am Peer auch vorhanden sind nicht mehr und nicht weniger.
Bei den reinen Initiators (Clients) wird niemals ein Listen Port definiert.
Außerdem stehen immer nur die Destination (Ziel) Netze bzw. Hosts bei internen IPs in den Allowed IPs die in den Tunnel geroutet werden müssen.
Fehlerhaft ist auch die Mobilclients sich in einen der Initiators einwählen zu lassen. Technisch möglich aber aus VPN nicht optimal. Wenn C dein zentraler Responder ist sollten sich auch nur das die mobilen Clients einwählen.
Mit anderen Worten: Deine 3 Konfigs sind syntaktisch und auch teilweise designtechnischer Murks. Zumindestens die groben Konfig Fehler oben solltest du dringenst beseitigen für ein sauberes Setup. Dann wird auch das VPN internet Routing sauber klappen.
Es hilft immer das Wireguard Tutorial wirklich genau zu lesen. Insbesondere das dortige Beispielsetup was identisch zu deinem ist. Leider ist das trotz Appell wohl unterblieben.