Ziel
Ich versuche, ein WireGuard-VPN nur mit IPv6 einzurichten, über das ich (a) den gesamten Datenverkehr leiten möchte und (b) über einen Server, der vom Internet aus erreichbar ist. Da ich (a) nicht einmal zum Laufen bringen konnte, werde ich einfach versuchen, das zum Laufen zu bringen, (b) dient nur dem Kontext.
Ich habe einen VPS mit global routbarem IPv6 2a03:4000:xx:xx:18d7:b1ef:fe48:7d35/64(das ip asagt es mir) auf eth0. Ich werde ihn mit dem Hostnamen bezeichnen vps. Zu Testzwecken hat der Server keine Firewall und net.ipv6.conf.all.forwarding=1und
net.ipv6.conf.all.accept_ra=2.
2001:1715:yy:yy:db2d:ab24:ed3f:39d4/64Dann habe ich auch noch mein Gerät eingeschaltet , welches ebenfalls eine IPv6-Adresse besitzt wlan0(das sollte keine relevante Information sein, da sich diese Adresse ändert, wenn ich in einem anderen WLAN bin). Es trägt den Hostnamen laptop.
Ich möchte am Ende so etwas haben:
Internet <-> vps <-> laptop
Bei IPv4 würde ich NAT verwenden, in der IPv6-Welt wird NAT jedoch nicht empfohlen. Es ist schwer herauszufinden, was man stattdessen tun soll, aber wenn ich richtig gelesen habe, sollte ich dem 2a03:4000:xx:xx::/64Laptop eine andere IP-Adresse aus dem Block geben, den der VPS erhalten hat.
Aufstellen
Also schreibe ich diese beiden Wireguard-Konfigurationen:
VPS:
[Interface]
Address = fc01::1/128 # Shouldn't really matter?
ListenPort = 1935 # This port is open to UDP on most networks
PrivateKey = uLxxxxxxxxxxxxxxxxxxxxxxxxEQ=
[Peer]
# laptop
PublicKey = swxxxxxxxxxxxxxxxxxxxxxxxxxmQ=
AllowedIPs = 2a03:4000:xx:xx:ffff::3/128 # Is inside the vps' /64 block
Laptop:
[Interface]
Address = 2a03:4000:xx:xx:ffff::3/128 # The globally routable IP addr of my laptop via the vps
ListenPort = 1935
PrivateKey = yMxxxxxxxxxxxxxxxxxxxxxxxxxxxxm8=
[Peer]
PublicKey = pCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzs=
AllowedIPs = ::/0 # Route all traffic through this peer
Endpoint = [2a03:4000:xx:xx:18d7:b1ef:fe48:7d35]:1935
Ich bringe sie zur Sprache:
[root@vps ~]# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add fc01::1/128 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -6 route add 2a03:4000:xx:xx:ffff::3/128 dev wg0
[root@laptop ~]# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add 2a03:4000:xx:xx:ffff::3/128 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
... uuuuund es funktioniert nicht.
WireGuard scheint keine erfolgreiche Verbindung herzustellen. Der Laptop zeigt eine Verbindung an und zählt den gesendeten Datenverkehr (aber 0 B empfangen), aber der VPS zeigt keine Verbindung an.
Wie richtet man ein IPv6-only WireGuard VPN richtig ein? Und wenn dies richtig ist, warum kommt der an einem Ende gesendete Datenverkehr nicht am anderen Ende des Tunnels an?
Wenn weitere Informationen (PCAPs, ipAusgaben usw.) hilfreich wären, werde ich die Frage gerne ergänzen.
Antwort1
Dies funktioniert nicht, da das Gateway Ihres Servers davon ausgeht,das gesamte /64 ist „on-link“, das heißt, jede Adresse ist über dasselbe Ethernet-Segment direkt erreichbar. Das Gateway stellt also Neighbor Discovery-Anfragen nach der MAC-Adresse Ihres Laptops, erhält jedoch keine Antwort, da sich der Laptop überhaupt nicht auf derselben Verbindung befindet.
(Normalerweise antwortet der Server nicht im Namen von Adressen, die woanders hingeleitet werden – er antwortet nur für Adressen, die direkt seiner eigenen eth0-Schnittstelle zugewiesen sind.)
Damit dies mit On-Link-Adressen funktioniert, müssen Sie "Proxy NDP" verwenden, d. h. den Server tatsächlichGeben Sie NDP-Antworten im Namen des Laptops(und jede andere Adresse, die Sie über den Tunnel routen möchten).
Der zuverlässigste Weg, dies für IPv6 zu tun, besteht darin, den ndpresponderDaemon auf eth0 auszuführen. Er wartet auf Neighbor Solicitation-Pakete und sendet die richtigen Neighbor Advertisements.
(Ähnlich könnten Sie ndppdoder sogar die eingebaute proxy_ndpFunktion des Kernels verwenden, aber diese verhalten sichleichtunterscheidet sich von echten NDP-Antworten und besteht manchmal nicht die Anti-Spoofing-Prüfungen, die einige VPS-Hosting-Betreiber durchführen.)
Im Idealfall sollte das Hosting-Unternehmensollte Ihnen eineweitergeleitetPräfix– eine, bei der das Datacenter-Gateway explizit so konfiguriert ist, dass alles „über“ die primäre Adresse Ihres Servers geroutet wird. Dies wäre auch für sie von gewissem Vorteil, da eine einzelne statische Route effizienter wäre als viele dynamische Nachbarcache-Einträge.
(Leider verwenden viele Server-Hosting-Unternehmen intern eine bestimmte VPS-Verwaltungsplattform, die sie daran hindert, geroutete Präfixe anzubieten – ich habe gehört, dass das an SolusVM liegt, das auf dem „Flat On-Link /48“-Modell besteht.)
Hinweis: Dies ist in keiner Weise IPv6-spezifisch – die gleiche Unterscheidung zwischen „on-link“ und „routed“ besteht auch bei IPv4, mit dem einzigen Unterschied, dass IPv4 ARP statt NDP verwendet. (Wenn sich Ihr Server beispielsweise in 192.168.1.0/24 auf eth0 befände und Sie 192.168.1.7 an einen VPN-Client routen wollten, hätten Sie genau dasselbe Problem und müssten Proxy-ARP verwenden, um es zu umgehen.)