3
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1908673536
Url: https://administrator.de/contentid/1908673536
Printed on: April 27, 2024 at 05:04 o'clock
3 Comments
Latest comment
Hier noch mal eine Übersicht
A: Dual Stack
B: IPv6
C: IPv4
A: Dual Stack
B: IPv6
C: IPv4
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.
Lieber Aqui, das verstehe ich nicht. Du hast mir exakt diese Konfig (bis auf ein paar zusätzliche Cryptokey-Routen, die jetzt dazu gekommen sind) abgenommen: Wireguard Routing über 3 Netzwerke
Vorher hast du (und ein anderer) mir die ganzen nötigen Rück-Routen (AllowedIPs) erklärt, die ich damals vergessen hatte.
Versteh´ ich nicht wie man seine Meinung um 180° ändern kann - was damals richtig war ist nun falsch - hä?
Die echte Konfig sieht so aus:
Der Übersichthalber habe ich "AllowedIPs" beim ersten Peer verdoppelt, da die Zeile sonst zu lang wird.
Die von mir in Word erstellte Ansicht ist so formatiert, dass man die IPs einfacher lesen kann.
Das hat sich auch nicht geändert, seit Oktober.
C ist nicht mein zentraler Responder, alle drei sind Responder.
Zu meinen eigentlichen beiden Fragen kannst du nichts sagen?
aqui 06.10.2023 um 09:40:25 Uhr
Konfig ist soweit OK.
Konfig ist soweit OK.
Vorher hast du (und ein anderer) mir die ganzen nötigen Rück-Routen (AllowedIPs) erklärt, die ich damals vergessen hatte.
Versteh´ ich nicht wie man seine Meinung um 180° ändern kann - was damals richtig war ist nun falsch - hä?
Deine "AllowedIPs" Sektion ist in allen 3 Konfigs falsch! Dort wird IPv4 und v6 zusammen aufgeführt.
IPv4 und v6 wurden schon immer zusammen aufgeführtDie echte Konfig sieht so aus:
[Peer]
PublicKey = xy
AllowedIPs = 192.168.99.1/32, 192.168.99.2/32, 192.168.99.5/32, 192.168.99.10/32, 192.168.99.11/32, 192.168.74.0/24, 192.168.168.0/24
AllowedIPs = fd08::1/128, fd08::2/128, fd08::5/128, fd08::10/128, fd08::11/128, fd00:aaaa::/64, fd00:bbbb::/64
[Peer]
PublicKey = yz
AllowedIPs = 192.168.99.21/32, fd08::21/128
[Peer]
PublicKey = zy
AllowedIPs = 192.168.99.22/32, fd08::22/128
[Peer]
PublicKey = yx
AllowedIPs = 192.168.99.23/32, fd08::23/128Die von mir in Word erstellte Ansicht ist so formatiert, dass man die IPs einfacher lesen kann.
Bei den reinen Initiators (Clients) wird niemals ein Listen Port definiert.
Jeder Wireguard Server benötigt einen Listen Port, sonst kann ich mich nicht von außen drauf einwählen.Das hat sich auch nicht geändert, seit Oktober.
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.
C ist nicht mein zentraler Responder, alle drei sind Responder.
Zu meinen eigentlichen beiden Fragen kannst du nichts sagen?