Und ich habe noch ein Problem in Dennis Video zur Fritteuse entdeckt.
Übernimmt man die Config für die Clients (PC, Smartphone, etc.) uverändert so wie im Video gezeigt
DNS = 86.54.11.100 nicht erreichen. Der ist ja nicht über die AllowedIPs = 192.168.178.0/24,10.7.0.0/24 des Tunnels zu erreichen. DNS-Auflösungen scheitern so.
Da hab ich halt Erfahrungswerte wo man anfängt nach Fehlern zu suchen. Mach IT ja nicht erst seit gestern 
Normal würde man ja im Log die Suche anfangen, aber diese vermaledeiten Fritteusen loggen ja nichts was mit Wireguard zu tun hat. Im Log der Fritteuse erscheint nur dann was im Log, wenn man eine neue Verbindung hinzugefügt hat und wenn diese dann auch erfolgreich aufgebaut werden konnte. Bei Misserfolg steht da mal einfach nichts drin.
Da mit aber aufgefallen war, dass die Verbindungen immer per IPv6 aufgebaut werden sollten, hab ich mir mal gedacht ich erzwinge Verbindungsaufbau per IPv4 (das geht halt am einfachsten wenn man statt der URL die IPv4-Adresse nimmt) und schmeiß dann auch gleich alles mit IPv6 aus der wg0.conf raus.
Wie genau wäre denn jetzt die richtige Lösung bzw. der richtige Weg?
Evtl. Ken @Dennis_Admin dazu auch was schreiben, da es ja doch kein Einzelfall zu sein scheint.
Für einen Client (PC, Notebook)?
root@Debian13:~# wg-quick up wg3
[#] ip link add wg3 type wireguard
[#] wg setconf wg3 /dev/fd/63
[#] ip -4 address add 10.7.0.3/32 dev wg3
[#] ip -6 address add fd64::3/128 dev wg3
[#] ip link set mtu 1392 up dev wg3
[#] resolvconf -a wg3 -m 0 -x
[#] ip -4 route add 192.168.178.0/24 dev wg3
[#] ip -4 route add 10.7.0.0/24 dev wg3
root@Debian13:~# nslookup google.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached
root@Debian13:~#
Wie man sieht scheitert die DNS-Auflösung. Also fügt man den beiden im Video gesetzten AllowedIPs (192.168.178.0/24 und 10.7.0.0/24) noch die .0.0.0.0/0 hinzu. Ergebnis dann:
root@Debian13:~# wg-quick up wg3
[#] ip link add wg3 type wireguard
[#] wg setconf wg3 /dev/fd/63
[#] ip -4 address add 10.7.0.3/32 dev wg3
[#] ip -6 address add fd64::3/128 dev wg3
[#] ip link set mtu 1392 up dev wg3
[#] resolvconf -a wg3 -m 0 -x
[#] ip -4 route add 192.168.178.0/24 dev wg3
[#] ip -4 route add 10.7.0.0/24 dev wg3
[#] wg set wg3 fwmark 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] ip -4 route add 0.0.0.0/0 dev wg3 table 51820
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] nft -f /dev/fd/63
root@Debian13:~# nslookup google.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: google.com
Address: 142.250.154.139
Name: google.com
Address: 142.250.154.100
Name: google.com
Address: 142.250.154.101
Name: google.com
Address: 142.250.154.102
Name: google.com
Address: 142.250.154.113
Name: google.com
Address: 142.250.154.138
Name: google.com
Address: 2a00:1450:4001:c21::66
Name: google.com
Address: 2a00:1450:4001:c21::71
Name: google.com
Address: 2a00:1450:4001:c21::8a
Name: google.com
Address: 2a00:1450:4001:c21::64
root@Debian13:~#
Die Ursache für das Ausgangsproblem ist vermutlich identifiziert.
Wow. Danke für die Details und das Feedback. Konnte es mir einfach auch nicht erklären. Aber das ist alles logisch/verständlich.
Hoffen wir, dass es bald gelöst ist/wird.
So, du kannst es nun nochmal ganz normal mit der URL versuchen. Das Problem wurde von Dennis behoben.
Siehe: Störung / Fehlfunktion IPv6 bei einigen Cloud Router - #11 von Dennis_Admin