19
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 foreverWenn 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=15msOpenWRT 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 msIch 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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667550
Url: https://administrator.de/contentid/667550
Ausgedruckt am: 24.11.2024 um 16: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.
Hallo aqui,
Ich muss auch sagen, dass das garnicht schlecht ist, dass ich es nun so mache.
Jetzt habe ich ein paar Komponenten mehr drin und mich interessiert nun das Problem mit dem IPv6 LAN, hinter einem Wireguard VPN.
Dort habe ich wie beschrieben kein Problem.
Ist exakt die gleiche Config.
Die unterschiedlichgen Scopes (IPv6 Scope) waren mir bekannt, als ich die Frage gepostet habe und als ich den OpenWRT Router mit Wireguard eingerichtet habe.
Ich hoffe es gibt hier ein OpenWRT Speziallisten, der mir die Klicks und Configs sagen kann, dass das IPv6 vom Wireguard Server auch im OpenWRT LAN "erstrahlt".
Es wäre auch kein Problem den IPv6 Adressbereich des Wireguard mit den Global Scope Adressen zu erweitern oder zu ersetzen aber es wäre schön, wenn das jemand erklären könnte, wie und warum es dann funktioniert.
Wenn es nur funktionieren soll, dann könnte ich auch auf dem Ubuntu ein Wireguard Client installieren, dann wird es wahrscheinlich wie bei Windows 10 mit IPv4 und IPv6 funktionieren,
Grüße
FISI
Zitat von @aqui:
Ggf. hast du auch einen Internet Provider an deinem Heimrouter der schon einen Dual Stack Betrieb anbietet.
Leider nicht, weshalb ich ein IPv6 LAN einrichten will.Ggf. hast du auch einen Internet Provider an deinem Heimrouter der schon einen Dual Stack Betrieb anbietet.
Ich muss auch sagen, dass das garnicht schlecht ist, dass ich es nun so mache.
Jetzt habe ich ein paar Komponenten mehr drin und mich interessiert nun das Problem mit dem IPv6 LAN, hinter einem Wireguard VPN.
Aber dein wg0 Interface hat keine gültige öffentliche v6 Adresse. Stattdessen nutzt es eine im Internet unroutebare Unique_local_address im Bereich fc00::/7
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.
Dazu muss ich anmerken, dass ich deshalb die Wireguard Clienten auch direkt auf Windows 10 getestet habe.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.
Dort habe ich wie beschrieben kein Problem.
Ist exakt die gleiche Config.
Die unterschiedlichgen Scopes (IPv6 Scope) waren mir bekannt, als ich die Frage gepostet habe und als ich den OpenWRT Router mit Wireguard eingerichtet habe.
Ich hoffe es gibt hier ein OpenWRT Speziallisten, der mir die Klicks und Configs sagen kann, dass das IPv6 vom Wireguard Server auch im OpenWRT LAN "erstrahlt".
Es wäre auch kein Problem den IPv6 Adressbereich des Wireguard mit den Global Scope Adressen zu erweitern oder zu ersetzen aber es wäre schön, wenn das jemand erklären könnte, wie und warum es dann funktioniert.
Wenn es nur funktionieren soll, dann könnte ich auch auf dem Ubuntu ein Wireguard Client installieren, dann wird es wahrscheinlich wie bei Windows 10 mit IPv4 und IPv6 funktionieren,
Grüße
FISI
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.
Hallo aqui,
danke für die Rückmeldung.
Ich habe in OpenWRT alles über die GUI eingefügt.
Die Configs wurden vom System erstellt.
Deshalb kann ich zu den Hochkommas nichts weiter sage. Ich gehe davon aus, dass die so sein müssen, weil wie gesagt, das System die Configs generiert hat.
Den Wireguard Client habe ich nach der Anleitung eingefügt:
https://www.youtube.com/watch?v=0_zQAp3V18c
Hier das ip route show vom OpenWRT:
und ip -6 route show vom OpenWRT:
und traceroute6 vom OpenWRT aus:
Und hier vom Windows 10 die ipconfig.
Wie du schon richtig vermutet hast, sind hier IPv6 fd8e:
Grüße
FISI
danke für die Rückmeldung.
Zitat von @aqui:
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 ?!
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 ?!
Ich habe in OpenWRT alles über die GUI eingefügt.
Die Configs wurden vom System erstellt.
Deshalb kann ich zu den Hochkommas nichts weiter sage. Ich gehe davon aus, dass die so sein müssen, weil wie gesagt, das System die Configs generiert hat.
Den Wireguard Client habe ich nach der Anleitung eingefügt:
https://www.youtube.com/watch?v=0_zQAp3V18c
Hier das ip route show vom OpenWRT:
root@OpenWrt_IPv6:~# ip route show
default dev Wireguard proto static scope link
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.0.204
XX.XXX.186.65 via 10.1.0.1 dev eth0 proto static
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1und ip -6 route show vom OpenWRT:
root@OpenWrt_IPv6:~# ip -6 route show
fd42:42:42::2 dev Wireguard proto kernel metric 256 pref medium
fd8e:7cd3:b012::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd8e:7cd3:b012::/48 dev lo proto static metric 2147483647 error 4294967183 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default dev Wireguard proto static metric 1024 pref mediumund traceroute6 vom OpenWRT aus:
root@OpenWrt_IPv6:~# traceroute6 google.com
traceroute to google.com (2a00:1450:4001:80f::200e), 30 hops max, 72 byte packets
1 fd42:42:42::1 (fd42:42:42::1) 36.751 ms 41.591 ms 39.978 ms
2 2a03:4000:f::3 (2a03:4000:f::3) 37.947 ms 74.560 ms 32.999 ms
3 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 35.011 ms 38.088 ms 38.757 ms
4 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 40.122 ms 62.855 ms 40.944 ms
5 2001:4860:1:1::6bc (2001:4860:1:1::6bc) 40.158 ms 41.503 ms 39.938 ms
6 2001:4860:0:11e0::1 (2001:4860:0:11e0::1) 41.012 ms * 2001:4860:0:11e2::1 (2001:4860:0:11e2::1) 39.712 ms
7 2001:4860:0:1::3143 (2001:4860:0:1::3143) 50.402 ms 2001:4860:0:1::3131 (2001:4860:0:1::3131) 42.351 ms 39.594 ms
8 fra07s64-in-x200e.1e100.net (2a00:1450:4001:80f::200e) 39.019 ms 34.370 ms 40.084 msUnd hier vom Windows 10 die ipconfig.
Wie du schon richtig vermutet hast, sind hier IPv6 fd8e:
C:\Users\user>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : DESKTOP-ORF1HHJ
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : lan
Ethernet-Adapter Ethernet0:
Verbindungsspezifisches DNS-Suffix: lan
Beschreibung. . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physische Adresse . . . . . . . . : 00-0C-29-55-B4-F9
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : fd8e:7cd3:b012::dbf(Bevorzugt)
Lease erhalten. . . . . . . . . . : Sonntag, 13. Juni 2021 14:32:02
Lease läuft ab. . . . . . . . . . : Donnerstag, 21. Juli 2157 16:38:26
IPv6-Adresse. . . . . . . . . . . : fd8e:7cd3:b012:0:d1c3:81ac:1d65:cb9a(Bevorzugt)
Temporäre IPv6-Adresse. . . . . . : fd8e:7cd3:b012:0:4533:964f:2a3b:6ccf(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::d1c3:81ac:1d65:cb9a%4(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.111(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Montag, 14. Juni 2021 10:05:01
Lease läuft ab. . . . . . . . . . : Montag, 14. Juni 2021 22:05:01
Standardgateway . . . . . . . . . : 192.168.1.1
DHCP-Server . . . . . . . . . . . : 192.168.1.1
DHCPv6-IAID . . . . . . . . . . . : 100666409
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-28-57-6A-96-00-0C-29-55-B4-F9
DNS-Server . . . . . . . . . . . : fd8e:7cd3:b012::1
192.168.1.1
fd8e:7cd3:b012::1
NetBIOS über TCP/IP . . . . . . . : AktiviertGrüße
FISI
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.
Hallo aqui,
danke an der Stelle, erstmal für deine Zeit und Hilfe.
Für mich ist vieles von IPv6 natürlich noch völlig neu und unklar.
Nachdem ich im OpenWRT keine globale IPv6 Adresse sehe, habe ich nicht verstanden, warum ich im OpenWRT öffentliche IPv6 pingen kann.
Dachte dass das nicht geroutet wird.
Aber verstehe ich das richitg dass es da auch ein NAT gibt?
Der gleiche Fehler kommt, wenn ich die 2003:XXXX:XXXX global scope anpinge, vom Server anpinge.
Auch wenn ich die IPv6 des Wireguard (Server) von Windows aus anpinge kommt der Fehler:
Der Wireguard Server hat die fd42:42:42::1
Der Wireguard Client auf dem OpenWRT hat die fd42:42:42::2. Auch die kann ich von Windows aus, nicht anpingen.
Sieht so aus, wie wenn auf dem OpenWRT die IPv6 Funktionalität des Wireguard Tunnel endet.
Grüße
FISI
danke an der Stelle, erstmal für deine Zeit und Hilfe.
Für mich ist vieles von IPv6 natürlich noch völlig neu und unklar.
Nachdem ich im OpenWRT keine globale IPv6 Adresse sehe, habe ich nicht verstanden, warum ich im OpenWRT öffentliche IPv6 pingen kann.
Dachte dass das nicht geroutet wird.
Aber verstehe ich das richitg dass es da auch ein NAT gibt?
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)
Also ein ping -6 2a00:1450:4001:80f::200e (Google)
C:\Users\user>ping -6 2a00:1450:4001:80f::200e
Ping wird ausgeführt für 2a00:1450:4001:80f::200e mit 32 Bytes Daten:
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
Ping-Statistik für 2a00:1450:4001:80f::200e:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),Der gleiche Fehler kommt, wenn ich die 2003:XXXX:XXXX global scope anpinge, vom Server anpinge.
Auch wenn ich die IPv6 des Wireguard (Server) von Windows aus anpinge kommt der Fehler:
C:\Users\user>ping -6 fd42:42:42::1
Ping wird ausgeführt für fd42:42:42::1 mit 32 Bytes Daten:
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
PING: Fehler bei der Übertragung. Allgemeiner Fehler.
Ping-Statistik für fd42:42:42::1:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),Der Wireguard Server hat die fd42:42:42::1
Der Wireguard Client auf dem OpenWRT hat die fd42:42:42::2. Auch die kann ich von Windows aus, nicht anpingen.
Sieht so aus, wie wenn auf dem OpenWRT die IPv6 Funktionalität des Wireguard Tunnel endet.
Das natürlich generell v6 Forwarding im OpenWRT aktiviert sein muss nehmen wir mal als gegeben an.
Ja das ist aktiviert.# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings
kernel.panic=3
kernel.core_pattern=/tmp/%e.%t.%p.%s.core
fs.suid_dumpable=2
fs.protected_hardlinks=1
fs.protected_symlinks=1
net.core.bpf_jit_enable=1
net.ipv4.conf.default.arp_ignore=1
net.ipv4.conf.all.arp_ignore=1
net.ipv4.ip_forward=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.igmp_max_memberships=100
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_timestamps=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_dsack=1
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1Grüße
FISI
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 sehe gerade, dass meine Aussage, dass das IPv6 im LAN nicht funktioniert nicht ganz stimmt.
Ich kann die fe80::20c:29ff:fe23:564d des OpenWRT Router von Windows aus anpingen.
Ein tracert -6 geht natürlich dann auch zu der IPv6 die ich anpingen kann aber bei der Wireguard Clint IPv6 des OpenWRT ist Ende.
Ich habe das alles nach Anleitungen eingerichtet und installiert. Den Wireguard Server auf einem Debain Server bei einem Hoster mit einem Script (https://github.com/angristan/wireguard-install). Den Wireguard Client auf OpenWRT nach dem Youtube Video.
Ich habe jetz auf dem Ubuntu und Windows direkt die Wireguard Clienten installiert und werde mit dem Buch weitermachen.
Ist im Moment noch eine Nummer zu hoch, mit dem OpenWRT und Wireguard IPv6.
Eventuell hat hier, einer der Profis mal Zeit und erstellt ein Tutorial mit Wireguard Server und ein OpenWRT mit Wireguard Client und zeigt dann die Schritte oder Configs, um das einzurichten, dass IPv4 und IPv6 im LAN voll funktionieren.
Grüße
FISI
Ich kann die fe80::20c:29ff:fe23:564d des OpenWRT Router von Windows aus anpingen.
C:\Users\user>ping -6 fe80::20c:29ff:fe23:564d
Ping wird ausgeführt für fe80::20c:29ff:fe23:564d mit 32 Bytes Daten:
Antwort von fe80::20c:29ff:fe23:564d: Zeit<1ms
Antwort von fe80::20c:29ff:fe23:564d: Zeit<1ms
Antwort von fe80::20c:29ff:fe23:564d: Zeit<1ms
Antwort von fe80::20c:29ff:fe23:564d: Zeit<1ms
Ping-Statistik für fe80::20c:29ff:fe23:564d:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0msEin tracert -6 geht natürlich dann auch zu der IPv6 die ich anpingen kann aber bei der Wireguard Clint IPv6 des OpenWRT ist Ende.
C:\Users\user>tracert -6 fe80::20c:29ff:fe23:564d
Routenverfolgung zu fe80::20c:29ff:fe23:564d über maximal 30 Hops
1 <1 ms <1 ms <1 ms fe80::20c:29ff:fe23:564d
Ablaufverfolgung beendet.
C:\Users\user>tracert -6 fd42:42:42::2
Routenverfolgung zu fd42:42:42::2 über maximal 30 Hops
1 Übertragungsfehler: Fehlercode 1231.
Ablaufverfolgung beendet.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.
Kann das sein dass das eine Funktion des Wireguard Server ist.Ich habe das alles nach Anleitungen eingerichtet und installiert. Den Wireguard Server auf einem Debain Server bei einem Hoster mit einem Script (https://github.com/angristan/wireguard-install). Den Wireguard Client auf OpenWRT nach dem Youtube Video.
Ich habe jetz auf dem Ubuntu und Windows direkt die Wireguard Clienten installiert und werde mit dem Buch weitermachen.
Ist im Moment noch eine Nummer zu hoch, mit dem OpenWRT und Wireguard IPv6.
Eventuell hat hier, einer der Profis mal Zeit und erstellt ein Tutorial mit Wireguard Server und ein OpenWRT mit Wireguard Client und zeigt dann die Schritte oder Configs, um das einzurichten, dass IPv4 und IPv6 im LAN voll funktionieren.
Grüße
FISI
Ich habe das mal auf dem Ubuntu angeschaut und dort ist es wie auf dem OpenWRT.
Ich kann keine globale IPv6 sehen aber ich kann IPv6 von Google anpingen.
Auch DNS mit IPv6 funktioniert.
Aber klar, wenn es so im OpenWRT funktioniert hat, dann klappt das auch auf Ubuntu.
Das Problem war ja, dass bei dem Client in OpenWRT, diese Funktionalität, mit IPv6 nicht ins LAN weitergegeben wird.
Ich gehe mal, in meiner Unwissenheit, davon aus, dass das der Wireguard managed, dass ohne globale IPv6, mit IPv6 gearbeitet werden kann.
Grüße
FISI
Ich kann keine globale IPv6 sehen aber ich kann IPv6 von Google anpingen.
root@fuzzball:/home/user# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd8e:7cd3:b012::de6/128 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fd8e:7cd3:b012:0:20c:29ff:fe3a:59f4/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe3a:59f4/64 scope link
valid_lft forever preferred_lft forever
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::219:83ff:fe09:17da/64 scope link
valid_lft forever preferred_lft forever
5: wg: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000
inet6 fd42:42:42::5/128 scope global
valid_lft forever preferred_lft forever
root@fuzzball:/home/user# traceroute -6 2a00:1450:4001:80f::200e
traceroute to 2a00:1450:4001:80f::200e (2a00:1450:4001:80f::200e), 30 hops max, 80 byte packets
1 fd42:42:42::1 (fd42:42:42::1) 34.722 ms 37.678 ms 40.670 ms
2 2a03:4000:f::3 (2a03:4000:f::3) 42.725 ms 42.709 ms 42.686 ms
3 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 42.671 ms 42.640 ms 42.616 ms
4 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 44.510 ms 44.491 ms 44.466 ms
5 2001:4860:1:1::6bc (2001:4860:1:1::6bc) 44.439 ms 48.286 ms 45.242 ms
6 * 2001:4860:0:11e0::1 (2001:4860:0:11e0::1) 39.346 ms *
7 2001:4860:0:1::3131 (2001:4860:0:1::3131) 34.209 ms 2001:4860:0:1::3143 (2001:4860:0:1::3143) 39.376 ms 2001:4860:0:1::3131 (2001:4860:0:1::3131) 38.153 ms
8 fra07s64-in-x200e.1e100.net (2a00:1450:4001:80f::200e) 39.016 ms 38.098 ms 38.968 msAuch DNS mit IPv6 funktioniert.
root@fuzzball:/home/user# ping -6 google.com
PING google.com(bud02s26-in-x0e.1e100.net (2a00:1450:400d:809::200e)) 56 Datenbytes
64 Bytes von bud02s26-in-x0e.1e100.net (2a00:1450:400d:809::200e): icmp_seq=1 ttl=118 Zeit=48.4 ms
64 Bytes von bud02s26-in-x0e.1e100.net (2a00:1450:400d:809::200e): icmp_seq=2 ttl=118 Zeit=59.3 ms
64 Bytes von bud02s26-in-x0e.1e100.net (2a00:1450:400d:809::200e): icmp_seq=3 ttl=118 Zeit=44.9 ms
64 Bytes von bud02s26-in-x0e.1e100.net (2a00:1450:400d:809::200e): icmp_seq=4 ttl=118 Zeit=44.0 ms
^C
--- google.com ping statistics ---
4 Pakete übertragen, 4 empfangen, 0% Paketverlust, Zeit 3004ms
rtt min/avg/max/mdev = 43.958/49.125/59.305/6.105 msAber klar, wenn es so im OpenWRT funktioniert hat, dann klappt das auch auf Ubuntu.
Das Problem war ja, dass bei dem Client in OpenWRT, diese Funktionalität, mit IPv6 nicht ins LAN weitergegeben wird.
Ich gehe mal, in meiner Unwissenheit, davon aus, dass das der Wireguard managed, dass ohne globale IPv6, mit IPv6 gearbeitet werden kann.
Grüße
FISI
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 !! 
ok danke, dann habe ich jetzt mal ne Menge zu lesen und zu testen.
Aber das Merkzettel: VPN Installation mit Wireguard ist nur IPv4.
Das habe selbst ich verstanden
Grüße
FISI
Aber das Merkzettel: VPN Installation mit Wireguard ist nur IPv4.
Das habe selbst ich verstanden
Grüße
FISI
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 !!
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 !
Ja das bekomme ich hin Ich hatte mich schon gefreut, dass ich mir "kurz" die Umgebung, zusammenklicke und dann mit dem Buch weitermache.
Aber in der IT stellt man eine Frage, bekommt die zu einem Drittel beantwortet und hat dazu zehn neue Fragen.
bekommt die zu einem Drittel beantwortet und hat dazu zehn neue Fragen.
Willkommen im Club ! 🤣aber das Masquerading erstmal unbedingt weglassen !
Das ist ein guter Hinweis. Danke.Ich werde meine Trägheit überwinden und den Wireguardserver nicht mit einem Script aufsetzen sondern nach der von dir, in dem anderen Beitrag, verlinkten Anleitung https://meet-unix.org/2019-03-21-wireguard-vpn-server.html.
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 eth0Damit 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
1
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 @colinardo:
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.
Grüße Uwe
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
ip neigh add proxy 2a03:XXXX:XXXX::X dev eth0Damit reagiert der vServer per NDP auch auf die definierte Adresse mit seiner MAC.
Grüße Uwe
Danke dir für deine Info.
Da wäre ich nie drauf gekommen.
Grüße
FISI
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.
1
