OpenWRT mit Wireguard IPv6 im LAN
Hallo zusammen,
ich lerne gerade Ipv6. Dazu habe ich mir das Buch Ipv6-Workshop von Dan Lüdtke geholt, weil dort praktische Übungen drin sind.
Er benutzt aber als System ein Ubuntu 12.04 und ein Tunnelbroker, den es nicht mehr gibt.
Jetzt will ich ein IPv6 LAN einrichten, um die Übungen angehen zu können.
Deshalb habe ich mir ein Wireguard VPN Server bei Netcup aufgesetzt und will nun ein OpenWRT Router mit einem Wireguard Client, der mir IPv6 ins OpenWRT LAN gibt.
Dann kann ich dort mit beliebigen Clienten üben.
Bisher sieht die Sache so aus, dass der Wireguard Server funktioniert, wenn ich ein z.B. Windows 10 mit Wireguard Client benutze, funktioniert IPv4 und IPv6.
Mit Client benutzen, meine ich, dass ich z.B. auf Windows den Wireguard Clienten installiere und einen Tunnel hinzufüge.
Dann habe ich mit dem Windows 10 Client IPv4 und IPv6.
Ich kann z.B. mit ping -6 google.com in der CMD pingen.
Mein Problem:
Wenn ich den Wireguard Client auf einem OpenWRT Router aktiviere, dann geht im OpenWRT LAN nur IPv4.
Im Terminal von OpenWRT geht IPv6 auch.
In der OpenWRT Firewall habe ich mal alles auf Durchzug gestellt.
Der Wireguard Server hat eine statische IPv4 Adresse und eine IPv6 Adresse XXXX:XXXX:f:87f::1/64.
Hier die Daten zum Server:
Wenn ich den Client im OpenWRT Router LAN hinzufüge, dann bekomme ich nur IPv4 im LAN.
Könnt ihr mir helfen, was ich konfigurieren muss, um Wireguard Server IPv6 auch im OpenWRT LAN zu haben?
Hier die Konfigurationen vom OpenWRT Router:
/etc/config/network:
/etc/config/dhcp:
/etc/config/firewall:
Wie schon erwähnt, kann ich IPv6 pingen, wenn ich den Wireguard Client direkt auf Windows 10 laufen habe:
OpenWRT selbst kann IPv6 pingen und DNS auflösen in IPv6:
Ich weiß nur nicht, wie ich OpenWRT dazu bringe, im LAN das IPv6 von Wireguard so zur Verfügung zu stellen, wie IPv4.
Grüße
FISI
ich lerne gerade Ipv6. Dazu habe ich mir das Buch Ipv6-Workshop von Dan Lüdtke geholt, weil dort praktische Übungen drin sind.
Er benutzt aber als System ein Ubuntu 12.04 und ein Tunnelbroker, den es nicht mehr gibt.
Jetzt will ich ein IPv6 LAN einrichten, um die Übungen angehen zu können.
Deshalb habe ich mir ein Wireguard VPN Server bei Netcup aufgesetzt und will nun ein OpenWRT Router mit einem Wireguard Client, der mir IPv6 ins OpenWRT LAN gibt.
Dann kann ich dort mit beliebigen Clienten üben.
Bisher sieht die Sache so aus, dass der Wireguard Server funktioniert, wenn ich ein z.B. Windows 10 mit Wireguard Client benutze, funktioniert IPv4 und IPv6.
Mit Client benutzen, meine ich, dass ich z.B. auf Windows den Wireguard Clienten installiere und einen Tunnel hinzufüge.
Dann habe ich mit dem Windows 10 Client IPv4 und IPv6.
Ich kann z.B. mit ping -6 google.com in der CMD pingen.
Mein Problem:
Wenn ich den Wireguard Client auf einem OpenWRT Router aktiviere, dann geht im OpenWRT LAN nur IPv4.
Im Terminal von OpenWRT geht IPv6 auch.
In der OpenWRT Firewall habe ich mal alles auf Durchzug gestellt.
Der Wireguard Server hat eine statische IPv4 Adresse und eine IPv6 Adresse XXXX:XXXX:f:87f::1/64.
Hier die Daten zum Server:
root@srv106:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e6:47:7b:c3:fb:60 brd ff:ff:ff:ff:ff:ff
inet XX.XX.186.65/22 brd XX.XX.187.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 XXXX:XXXX:f:87f::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::e447:7bff:fec3:fb60/64 scope link
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
inet 10.66.66.1/24 scope global wg0
valid_lft forever preferred_lft forever
inet6 fd42:42:42::1/64 scope global
valid_lft forever preferred_lft forever
Wenn ich den Client im OpenWRT Router LAN hinzufüge, dann bekomme ich nur IPv4 im LAN.
Könnt ihr mir helfen, was ich konfigurieren muss, um Wireguard Server IPv6 auch im OpenWRT LAN zu haben?
Hier die Konfigurationen vom OpenWRT Router:
-----------------------------------------------------
OpenWrt 19.07.7, r11306-c4a6851c72
-----------------------------------------------------
root@OpenWrt_IPv6:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:23:56:43 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.204/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe23:5643/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
link/ether 00:0c:29:23:56:4d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
link/ether 00:0c:29:23:56:57 brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:23:56:4d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fd8e:7cd3:b012::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe23:564d/64 scope link
valid_lft forever preferred_lft forever
7: Wireguard: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.66.66.2/32 brd 255.255.255.255 scope global Wireguard
valid_lft forever preferred_lft forever
inet6 fd42:42:42::2/128 scope global
valid_lft forever preferred_lft forever
/etc/config/network:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd8e:7cd3:b012::/48'
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option ifname 'eth1 eth2'
config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'
config interface 'wan6'
option ifname 'eth1'
option proto 'dhcpv6'
config interface 'Wireguard'
option proto 'wireguard'
list addresses '10.66.66.2/32'
list addresses 'fd42:42:42::2/128'
option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
config wireguard_Wireguard
option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
option description 'WGConnection'
option persistent_keepalive '25'
option endpoint_port '57310'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::/0'
option preshared_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
option endpoint_host 'XX.XXX.186.65'
option route_allowed_ips '1'
/etc/config/dhcp:
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ra_management '1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
/etc/config/firewall:
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'Wireguard'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
config forwarding
option dest 'lan'
option src 'wan'
Wie schon erwähnt, kann ich IPv6 pingen, wenn ich den Wireguard Client direkt auf Windows 10 laufen habe:
C:\Users\user>ping -6 google.com
Ping wird ausgeführt für google.com [2a00:1450:4001:80f::200e] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:80f::200e: Zeit=16ms
Antwort von 2a00:1450:4001:80f::200e: Zeit=14ms
Antwort von 2a00:1450:4001:80f::200e: Zeit=15ms
Antwort von 2a00:1450:4001:80f::200e: Zeit=15ms
OpenWRT selbst kann IPv6 pingen und DNS auflösen in IPv6:
root@OpenWrt_IPv6:~# ping -6 -c 2 google.com
PING google.com (2a00:1450:4001:80f::200e): 56 data bytes
64 bytes from 2a00:1450:4001:80f::200e: seq=0 ttl=119 time=37.455 ms
64 bytes from 2a00:1450:4001:80f::200e: seq=1 ttl=119 time=37.304 ms
--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 37.304/37.379/37.455 ms
Ich weiß nur nicht, wie ich OpenWRT dazu bringe, im LAN das IPv6 von Wireguard so zur Verfügung zu stellen, wie IPv4.
Grüße
FISI
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667550
Url: https://administrator.de/contentid/667550
Ausgedruckt am: 05.11.2024 um 15:11 Uhr
19 Kommentare
Neuester Kommentar
Statt des Tunnelbrokers vom v6 Workshop kannst du auch den von Hurricane nehmen:
https://www.tunnelbroker.net
Ist identisch.
Ggf. hast du auch einen Internet Provider an deinem Heimrouter der schon einen Dual Stack Betrieb anbietet wie z.B. die Telekom. Dann brauchst du Broker gar nicht.
Gut mit deinem IPv6 Ansatz über WireGuard geht das natürlich auch.
Diese entspricht den bei v4 privaten RFC 1918 IP Adressen und werden im Internet nicht geroutet. Damit scheitert dann natürlich ein v6 Internet Zugriff auf öffentliche v6IPs.
https://www.tunnelbroker.net
Ist identisch.
Ggf. hast du auch einen Internet Provider an deinem Heimrouter der schon einen Dual Stack Betrieb anbietet wie z.B. die Telekom. Dann brauchst du Broker gar nicht.
Gut mit deinem IPv6 Ansatz über WireGuard geht das natürlich auch.
Der Wireguard Server hat eine statische IPv4 Adresse und eine IPv6 Adresse
Aber dein wg0 Interface hat keine gültige öffentliche v6 Adresse. Stattdessen nutzt es eine im Internet unroutebare Unique_local_address im Bereich fc00::/7Diese entspricht den bei v4 privaten RFC 1918 IP Adressen und werden im Internet nicht geroutet. Damit scheitert dann natürlich ein v6 Internet Zugriff auf öffentliche v6IPs.
Sorry, war im Eifer des Gefechts auch etwas missverstanden, denn es geht dir ja rein nur um eine IPv6 Adressverteilung an die Clients im LAN wenn man den Thread richtig versteht. Den WG Tunnel an sich kann der OpenWRT ja problemlos etablieren.
Dafür gibt es 2 Optionen einmal mit DHCPv6:
config dhcp lan
option dhcpv6 server
option ra server
Oder aber mit SLAAC
config dhcp lan
option dhcpv6 disabled
option ra server
Oben in deiner Konfig machst du es ja über die Option DHCPv6 allerdings sieht die Konfig keine Hochkommans vor wie bei dir. Ggf. ein Fehler ?!
Die Frage die sich stellt ist WELCHE v6 IP Adresse bekommen denn deine am LAN Port des Routers angeschlossenen Clients und wie sieht es mit Gateway und DNS aus ?
Diese Info fehlt leider.
Das sollte ja laut deiner Interface Konfig eine v6 Adresse aus dem fd8e:7cd3:b012::1/60 Netz sein.
Dadurch das du im Wireguard Client ein Gateway Redirect machst und kein Split Tunneling wird ja der gesamte OpenWRT IP Traffic bei aktivem WG Tunnel so oder so komplett in den Tunnel geroutet. Hier wäre ein ip route show bei aktivem Tunnel sehr hilfreich.
Dafür gibt es 2 Optionen einmal mit DHCPv6:
config dhcp lan
option dhcpv6 server
option ra server
Oder aber mit SLAAC
config dhcp lan
option dhcpv6 disabled
option ra server
Oben in deiner Konfig machst du es ja über die Option DHCPv6 allerdings sieht die Konfig keine Hochkommans vor wie bei dir. Ggf. ein Fehler ?!
Die Frage die sich stellt ist WELCHE v6 IP Adresse bekommen denn deine am LAN Port des Routers angeschlossenen Clients und wie sieht es mit Gateway und DNS aus ?
Diese Info fehlt leider.
Das sollte ja laut deiner Interface Konfig eine v6 Adresse aus dem fd8e:7cd3:b012::1/60 Netz sein.
Dadurch das du im Wireguard Client ein Gateway Redirect machst und kein Split Tunneling wird ja der gesamte OpenWRT IP Traffic bei aktivem WG Tunnel so oder so komplett in den Tunnel geroutet. Hier wäre ein ip route show bei aktivem Tunnel sehr hilfreich.
Hier das ip route show vom OpenWRT:
Wie du sicher auch selber siehst ist das technisch auch absolut korrekt. Das Default Gateway ist fpr IPv4 und auch v6 der WG Tunnel. So wie es ja auch laut Konfig sein soll. Routingtechnisch ist das also absolut OK.Auch was die IPv6 Adressierung der Endgeräte im lokalen OpenWRT LAN anbetrifft ist das alles sauber und korrekt so. v6 Adresse ist aus dem fd8e:7cd3:b012::1/60 Netz wie es sein soll.
Spannend wäre jetzt einmal die Frage wenn du auf dem Windows Rechner eine direkte IPv6 Internet Adresse angibst beim Pingen um einmal v6 DNS Problemen aus dem Rege zu gehen und ob das klappt.
Also ein ping -6 2a00:1450:4001:80f::200e (Google)
Interessant auch ein v6 Ping auf die interne und externe v6 Adresse des remoten Servers bei Netcup.
Kann der Client diese IPs pingen, wovon mal auszugehen ist, zeigt das das der Fehler nur beim Übergang ins IPv6 Internet oder beim v6 DNS liegen kann. Gut, DNS Problematiken kann man immer einfach ausklammern wenn man direkt v6 IP Adressen als Ziel pingt wie oben empfohlen.
2 Dinge sind zu klären:
1.)
Du verwendest ja in deinem Netz v6 ULA Adressen die so im Internet nicht routebar sind ! Diese v6 Adressen dürfen also niemals im Internet auftauchen weil sonst eine Rückroute technisch unmöglich wäre. Das ist so als wenn man v4 RFC 1918 IPs verwendet. Technisch unmöglich.
Das lässt nur den alleinigen Schluss zu das dein v6 Server, der den WG Tunnel bedient, NAT macht also deine unroutebaren ULA Adressen auf seine öffentlich und damit routebare v6 Provideradresse per NAT umsetzt.
NAT und IPv6 ist eigentlich ein NoGo weil nicht wirklich definiert aber zum Testen mit Einschränkungen machbar.
Wenn ein interner v6 Ping problemlos klappt aber v6 Adressen im Internet nicht ist es möglich das das lokale v6 LAN nicht oder nicht sauber über das v6 NAT/Masquerading am Server ins Internet geht.
Das musst du einmal mit tcpdump genau checken.
2.)
Der OpenWRT gibt sich selber als v6 DNS den Endgeräten aus. OK, wenn er als v6 Proxy DNS rennt. Das er selber v6 Hostnamen auflösen kann siehst du ja selber am v6 Traceroute. Wichtig ist nur sicherzustellen das er auch als Proxy DNS arbeitet.
Mit nslookup oder dig ist das ja schnell prüfbar.
Das natürlich generell v6 Forwarding im OpenWRT aktiviert sein muss nehmen wir mal als gegeben an.
Diese Ping Tests solltest du also nochmal machen.
ULA Adressen sind natürlich enerell bei Internet Zugang keine wirklich gute Idee weil es eben NAT erfordert was es bei IPv6 eigentlich nicht gibt.
Du bekommst ja ein /60er Prefix von deinem Provider geroutet und solltest auch /64er Subnetze aus diesen /60er Kontingent nutzen damit es v6 technisch sauber ist.
Wie bereits gesagt: Testweise rennt das natürlich auch mit v6 NAT. Produktiv sollte man damit nicht gehen.
habe ich nicht verstanden, warum ich im OpenWRT öffentliche IPv6 pingen kann.
Das hat die Mehrheit der Forencommunity hier sicher auch nicht verstanden, denn es ist so technisch natürlich unmöglich, da diese ULA Adressen bekanntlich nicht geroutet werden.Einzig möglich Erklärung ist hier das der öffentliche Server Netzwerk Adress Translation der v6 Adressen ins Internet macht.
Der gleiche Fehler kommt, wenn ich die 2003:XXXX:XXXX global scope anpinge
Was passiert wenn du eine deiner eigenen fd... ULA Adressen am Server pingst ?!Sieh dir am Server auch nochmal die v6 Routing Tabelle bei aktivem OpenWRT Wireguard Link an. Dort muss eine statische Route aktiv sein die dir das lokale LAN Netz am OpenWRT in den VPN Tunnel routet. Ansonsten weiss der Server ja nicht das er das lokale OpenWRT LAN fd8e:7cd3:b012::1/60 in den Tunnel routen soll.
Hier musst du mal etwas mit v6 Traceroutes checken.
Auch wenn ich die IPv6 des Wireguard (Server) von Windows aus anpinge kommt der Fehler:
Spannend wäre mal ein Traceroute auf diese IP wie weit der Ping kommt.Der Fehler liegt sehr wahrscheinlich in deinem lokalen Routing. Dem Server ist das lokale OpenWRT LAN fd8e:7cd3:b012::1/60 vermutlich nicht bekannt so das die Rückroute fehlschlägt.
Ich kann die fe80::20c:29ff:fe23:564d des OpenWRT Router von Windows aus anpingen.
Das ist klar und evident, denn die FE80 Adressen sind ja Link Local Adressen. Das entspricht den IPv4 APIPA oder Zeroconf Adressen 169.254.x.y.Die sind aber fürs Routing nicht relevant ! Klar, denn sie gelten nur im jeweiligen Layer 2 Segment und sind nicht routebar. Es macht folglich dann also sehr wenig Sinn diese zu pingen und/oder zu tracerouten.
Kann das sein dass das eine Funktion des Wireguard Server ist.
Nein, niemals ! Sowas hat mit WireGuard nichts zu tun, das kann man einzig und allein nur im iptables Setup machen und ist immer Betriebssystem selber ! Siehe auch hier:Merkzettel: VPN Installation mit Wireguard
Scripte sind immer gefährlich denn man sollte sich sowas immer VORHER genau ansehen was das Script macht. Immer ein NoGo wenn man nicht weiss was die auf einem System anrichten. Ganz sicher wird dort auch ein iptables Masquerading aktiviert ansonsten ist die Erreichbarkeit der öffentlichen v6 Adressen nicht zu erklären.
Ein iptables -S oder auch iptables -L zeigt dir alle aktiven Regeln an.
Übrigens: Ein Test Setup mit 2 Raspberry Pis nach deinem Design rennt hier fehlerfrei.
Eventuell hat hier, einer der Profis mal Zeit und erstellt ein Tutorial mit Wireguard Server
Gibt es schon längst. Siehe oben. Einfach mal die Suchfunkltion hier benutzen !! Ich kann keine globale IPv6 sehen aber ich kann IPv6 von Google anpingen.
Dann bleibt nur die Möglichkeit das der Hosting Provider intern an seine Kunden ULA Adressen vergibt und ein zentrales NAT irgendwo mach mit CGN.Das wäre aber für IPv6 sehr ungewöhnlich.
ist nur IPv4.
Na ja mal ehrlich....da dann zusätzlich zu den v4 Adressen einfach noch ein paar v6 Adressen mit einem /64er Prefix dazuzutippen schafft ja auch der FiSi im ersten Lehrjahr ! Ansonsten hier abgucken aber das Masquerading erstmal unbedingt weglassen !
Bzw. sieh in die Server Konfigs was genau dort in deinen Wireguard Setup Dateien steht !!
Servus @FISI-Lehrling ,
Ein wichtiger Hinweis zur Verwendung von IPv6 bei Netcup. Das Standardmäßig in einem Vertrag für einen einfachen vServer enthaltene IPv6 64er Präfix wird dort nicht komplett geroutet sondern die am vServer genutzte IPv6-Adresse wird im SCP bei Netcup statisch hinterlegt. Das führt dazu das wenn man mit anderen IPv6 Adressen dieses Präfix nicht ins globale IPv6 Netz kommt weil das vorgelagerte GW via NDP nur die im SCP definierte IP des Servers kennt. Möchte man dort trotzdem mit den anderen Adressen ins Netz muss man am vServer einen NDP Proxy einrichten (oder weniger sinnvoll, statisch im SCP eintragen). Für einzelne Adressen geht das bspw. mittels
Damit reagiert der vServer per NDP auch auf die definierte Adresse mit seiner MAC.
Will man jetzt also das 64er Netz aufteilen um den globalen Adressraum an unterschiedlichen Interfaces zu nutzen, machst du das 64 Netz kleiner z.B. teilst es in 72er Netze auf.
Setzt also das WAN und das Wireguard-IF jeweils auf ein 72er Präfix damit der vServer die Netze routen kann. Am vServer setzt du dann bspw. noch eine Route zu einem weiteren 72er Netz dessen GW die interne IPv6-Adresse des OpenWRT-Routers im Wireguard Subnet ist, und weist im OpenWRT-Router dann dieses 72er Subnetz deinem internen Interface zu. Dort kannst du dann entweder manuell oder per DHCPv6 aus dem 72er Netz Adressen verteilen.
Zusätzlich bestellte IPv6 Subnetze bei Netcup (1€/Monat zus.) werden dagegen so wie es eigentlich sein sollte, komplett geroutet. Hier entfällt dann der NDP-Proxy, also Notlösung.
Grüße Uwe
Ein wichtiger Hinweis zur Verwendung von IPv6 bei Netcup. Das Standardmäßig in einem Vertrag für einen einfachen vServer enthaltene IPv6 64er Präfix wird dort nicht komplett geroutet sondern die am vServer genutzte IPv6-Adresse wird im SCP bei Netcup statisch hinterlegt. Das führt dazu das wenn man mit anderen IPv6 Adressen dieses Präfix nicht ins globale IPv6 Netz kommt weil das vorgelagerte GW via NDP nur die im SCP definierte IP des Servers kennt. Möchte man dort trotzdem mit den anderen Adressen ins Netz muss man am vServer einen NDP Proxy einrichten (oder weniger sinnvoll, statisch im SCP eintragen). Für einzelne Adressen geht das bspw. mittels
ip neigh add proxy 2a03:XXXX:XXXX::X dev eth0
Damit reagiert der vServer per NDP auch auf die definierte Adresse mit seiner MAC.
Will man jetzt also das 64er Netz aufteilen um den globalen Adressraum an unterschiedlichen Interfaces zu nutzen, machst du das 64 Netz kleiner z.B. teilst es in 72er Netze auf.
Setzt also das WAN und das Wireguard-IF jeweils auf ein 72er Präfix damit der vServer die Netze routen kann. Am vServer setzt du dann bspw. noch eine Route zu einem weiteren 72er Netz dessen GW die interne IPv6-Adresse des OpenWRT-Routers im Wireguard Subnet ist, und weist im OpenWRT-Router dann dieses 72er Subnetz deinem internen Interface zu. Dort kannst du dann entweder manuell oder per DHCPv6 aus dem 72er Netz Adressen verteilen.
Zusätzlich bestellte IPv6 Subnetze bei Netcup (1€/Monat zus.) werden dagegen so wie es eigentlich sein sollte, komplett geroutet. Hier entfällt dann der NDP-Proxy, also Notlösung.
Grüße Uwe
Oha, auf solche fiese Fussfalle vom Provider muss man aber auch erstmal kommen...
Hilfreich wäre jetzt den WG Konfig File zu kennen sowohl Server als auch Client. Leider stochern wir da noch im Trüben...
Dennoch eine Frage dazu Uwe.
Der Windows WG Client sendet ja bei aktivem Tunnel mit einer fd42:42:42::X/64 Absender IP und bekommt damit eine weltweite v6 Verbindung wie man ja oben sieht. Ebenso der OpenWRT WG Client.
Wenn der vServer also lediglich eine einfache statische v6 IP bekommen hat, dann muss er ja zwangsweise ein v6 NAT machen am Providerport machen auf seine öffentliche v6 IP dort. Anders wäre die öffentliche v6 Connectivity der WG Clients ja sonst nicht zu erklären. Diese besteht ja nachweislich für den Windows als auch den OpenWRT Client wie man am obigen v6 Pingcheck zweifelsohne sieht.
Wenn der vServer aber so oder so alles was er am Provider WAN Port v6 NATet (SRCNAT, Masquerading) dann müsste rein routingtechnisch gesehen ja auch alle seine dahinter liegenden ULA Netze geNATet werden und damit auch v6 Connectivity haben. Eigentlich...
Hilfreich wäre jetzt den WG Konfig File zu kennen sowohl Server als auch Client. Leider stochern wir da noch im Trüben...
Dennoch eine Frage dazu Uwe.
Der Windows WG Client sendet ja bei aktivem Tunnel mit einer fd42:42:42::X/64 Absender IP und bekommt damit eine weltweite v6 Verbindung wie man ja oben sieht. Ebenso der OpenWRT WG Client.
Wenn der vServer also lediglich eine einfache statische v6 IP bekommen hat, dann muss er ja zwangsweise ein v6 NAT machen am Providerport machen auf seine öffentliche v6 IP dort. Anders wäre die öffentliche v6 Connectivity der WG Clients ja sonst nicht zu erklären. Diese besteht ja nachweislich für den Windows als auch den OpenWRT Client wie man am obigen v6 Pingcheck zweifelsohne sieht.
Wenn der vServer aber so oder so alles was er am Provider WAN Port v6 NATet (SRCNAT, Masquerading) dann müsste rein routingtechnisch gesehen ja auch alle seine dahinter liegenden ULA Netze geNATet werden und damit auch v6 Connectivity haben. Eigentlich...
Zitat von @aqui:
Dennoch eine Frage dazu Uwe.
Der Windows WG Client sendet ja bei aktivem Tunnel mit einer fd42:42:42::X/64 Absender IP und bekommt eine weltweite v6 Verbindung wie man ja oben sieht. Ebenso der OpenWRT WG Client.
Wenn der vServer also lediglich eine einfache statische v6 IP bekommen hat, dann muss er ja zwangsweise ein v6 NAT machen am Providerportmachen auf seine öffentliche v6 IP dort.
Ja sehe ich genau so. Da wird Knecht Ruprecht wohl ein SRCNAT auch auf die öffentliche IPv6 des vServers eingerichtet haben, anders kann ich mir den Schuh auch nicht erklären.Dennoch eine Frage dazu Uwe.
Der Windows WG Client sendet ja bei aktivem Tunnel mit einer fd42:42:42::X/64 Absender IP und bekommt eine weltweite v6 Verbindung wie man ja oben sieht. Ebenso der OpenWRT WG Client.
Wenn der vServer also lediglich eine einfache statische v6 IP bekommen hat, dann muss er ja zwangsweise ein v6 NAT machen am Providerportmachen auf seine öffentliche v6 IP dort.