[gelöst] wireguard neuer Client - connect ja, kein Transfer

[snowy]

Hi,

betreibe schon einige Monate auf einem Raspberry mit Raspbian (Buster) erfolgreich einen Wireguard-Server.
Bisher habe ich zwei Clients daran hängen, die regelmäßig mit dem Server kommunizieren.

Nun wollte ich einen weiteren Client (Debian Stretch) konfigurieren. Hier habe ich aber irgendwelche Schwierigkeiten und komme nicht weiter
Der neue Client verbindet sich "erfolgreich" mit dem Server, zumindest zeigt der Server mit wg den 3.Client an (public-private Keys scheinen also zu stimmen), allerdings ist keinerlei Datentransfer möglich.
Wenn ich auf dem neuen Client mit ip a kontrollieren, dann ist auch die Schnittstelle wg0 scheinbar korrekt angelegt.

Ich sehe keine Fehler, kein gar nichts, weder auf dem Client noch auf dem Server. Vermutlich weil ich nicht an der richtigen Stellen suche
Wo kann ich denn kontrollieren, woran es klemmen könnte?

PS: die neue Client-Maschine war mal an einem anderen Wireguard-Server gehängt. Die Installation ist also schon verifiziert gewesen.
Das Umhängen auf den anderen Wireguard-Server hat nur durch Überschreiben der Client-Konfiguration wg0.conf stattgefunden.
Ein Fehler ?

Danke für jegliche Tipps

[mat6937]

Das Umhängen auf den anderen Wireguard-Server hat nur durch Überschreiben der Client-Konfiguration wg0.conf stattgefunden.

Und durch Eintrag des pubkey beim anderen WireGuard-Server, oder?

Poste mal vom Client und vom Server die richtig anonymisierten Ausgaben von:

Code: Alles auswählen

wg

Wie ist die MTU in deinem WG-VPN (d. h. auf Server und Clients) konfiguriert?
Starte mal auf dem WG-Client der noch nicht funktioniert, dass debugging mit z. B.:

Code: Alles auswählen

echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

Mach einen Ping vom störrischen WG-Client zum WG-Server mit dem wg0-Interface als source. Z. B. (auf dem WG-Client):

Code: Alles auswählen

tcpdump -c 500 -vvveni wg0 icmp
ping -c 3 -I wg0 <wg0-IP-Adresse-Server>

Poste das Ergebnis des Pings bzw. des tcpdumps und die Ausgabe vom debugging (auf dem WG-Client).
Den Wireguard-Traffic am wan/lan-Interface (nicht das wg0) kannst Du mit Z. B. folgendem Filter sniffen:

Code: Alles auswählen

tcpdump -c 1000 -vvveni eth0 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'

(eth0 evtl. anpassen).

[snowy]

@mat6937, Danke für die Tipps u. Unterstützung.
Der Rechner ist nicht vor Ort, aber demnächst bin ich wieder dort und werde dann berichten

[snowy]

@mat6937, konnte zwar noch nicht die Tests durchführen, aber ich habe mir Deine Anweisungen nochmals durchgelesen.
Netzwerkseitig bin ich nicht sehr gut bewandert

Code: Alles auswählen

echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

wo geht das der Debugging-Output hin? Und wie schalte ich das Debugging dann wieder ab?
Mit Deinem Command schreibe ich ja nur diese eine Zeile in die Datei.
Habe gerade auf meinem eigenen Debian (nicht das Problem-System) nachgesehen, in meiner Datei stehen für 3466 Zeilen.
Auf einem anderen gerade installiertem Debian-System sind sogar über 7000 Zeilen in der Datei
Beim "Querlesen" habe ich nur Bahnhof verstanden.

Und bzgl. dem tcpdump auch die gleiche Frage, wohin geht der Output? Ich vermute mal nach stdout und ich sollte es wohl in eine Datei umleiten.

[mat6937]

Code: Alles auswählen

echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

wo geht das der Debugging-Output hin? Und wie schalte ich das Debugging dann wieder ab?
Mit Deinem Command schreibe ich ja nur diese eine Zeile in die Datei.
...
Und bzgl. dem tcpdump auch die gleiche Frage, wohin geht der Output? Ich vermute mal nach stdout und ich sollte es wohl in eine Datei umleiten.

Alles geht nach stdout (tcpdump) bzw. syslog/dmesg. Es muss nicht in eine Datei umgeleitet werden.
Beenden kannst Du mit:

Code: Alles auswählen

echo module wireguard -p > /sys/kernel/debug/dynamic_debug/control

Die Anzahl der Zeilen mit tcpdump, wird mit "-c" geregelt.

[snowy]

@mat6937, hat etwas gedauert. Aber jetzt war ich wieder vor Ort und konnte die Befehle absetzen.
Interpretieren kann ich davon gar nichts (abgesehen von ip u. ping output )

Vielleicht noch ein Hinweis zu den 3 Netzwerkkarten.
Die Maschine ist eine VM, ens36 ist das interne Netzwerk, ens33 fürs Internet, ens37 ist z.Zt. offline

Code: Alles auswählen

$ ping 109.250.15.33
PING 109.250.15.33 (109.250.15.33) 56(84) bytes of data.
64 bytes from 109.250.15.33: icmp_seq=1 ttl=58 time=22.4 ms
64 bytes from 109.250.15.33: icmp_seq=2 ttl=58 time=22.2 ms
64 bytes from 109.250.15.33: icmp_seq=3 ttl=58 time=21.8 ms
64 bytes from 109.250.15.33: icmp_seq=4 ttl=58 time=21.9 ms

# ip -brief a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
ens33            UP             192.168.2.104/24 
ens36            UP             192.168.157.100/24 fe80::250:56ff:fe38:4352/64 
ens37            DOWN           
wg0              UNKNOWN        10.6.0.4/24

# wg

interface: wg0
  public key: *** removed ***
  private key: (hidden)
  listening port: 50579
  fwmark: 0xca6c

peer: *** removed ***
  preshared key: (hidden)
  endpoint: 109.250.15.33:51820
  allowed ips: 0.0.0.0/0, ::/0
  transfer: 0 B received, 148 B sent

# ping -c 3 -I wg0 109.250.15.33
PING 109.250.15.33 (109.250.15.33) from 10.6.0.4 wg0: 56(84) bytes of data.

--- 109.250.15.33 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 37ms

# tcpdump -c 500 -vvveni wg0 icmp
tcpdump: listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
14:17:51.940847 ip: (tos 0x0, ttl 64, id 22461, offset 0, flags [DF], proto ICMP (1), length 84)
    10.6.0.4 > 109.250.15.33: ICMP echo request, id 17304, seq 1, length 64
14:17:52.951878 ip: (tos 0x0, ttl 64, id 22489, offset 0, flags [DF], proto ICMP (1), length 84)
    10.6.0.4 > 109.250.15.33: ICMP echo request, id 17304, seq 2, length 64
14:17:53.975755 ip: (tos 0x0, ttl 64, id 22688, offset 0, flags [DF], proto ICMP (1), length 84)
    10.6.0.4 > 109.250.15.33: ICMP echo request, id 17304, seq 3, length 64


# tcpdump -c 1000 -vvveni ens33 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'

tcpdump: listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
14:23:30.169177 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 30607, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:23:35.148927 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 26262, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xea46!] UDP, length 148
14:23:35.175071 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 30876, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:23:40.150602 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 27507, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xc4b4!] UDP, length 148
14:23:40.177257 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 31182, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:23:45.153089 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 27510, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xf246!] UDP, length 148
14:23:45.179478 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 31462, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:23:50.153024 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 28604, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x0622!] UDP, length 148
14:23:50.179558 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 31468, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:23:55.169031 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 29602, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x0bc7!] UDP, length 148
14:23:55.195371 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 31538, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:00.504744 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 29929, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xe428!] UDP, length 148
14:24:00.531171 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 31788, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:05.884694 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 31126, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xec76!] UDP, length 148
14:24:05.911284 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 31857, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:11.192575 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 32066, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xec2a!] UDP, length 148
14:24:11.219174 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 32090, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:16.632452 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 32413, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x4850!] UDP, length 148
14:24:16.658718 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 32145, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:22.008632 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 32585, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x0cf2!] UDP, length 148
14:24:22.034361 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 32550, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:27.168485 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 32645, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xeb3e!] UDP, length 148
14:24:27.195056 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 32721, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:32.200976 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 33492, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x6825!] UDP, length 148
14:24:32.226969 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 32949, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:37.205005 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 33637, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xaa7d!] UDP, length 148
14:24:37.231483 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 33021, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:42.489359 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 34680, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x42e2!] UDP, length 148
14:24:42.515454 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 33433, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:47.774077 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 34829, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xedc8!] UDP, length 148
14:24:47.800628 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 33595, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:52.779934 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 35022, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0xc773!] UDP, length 148
14:24:52.806934 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 33900, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
14:24:58.104587 9e:53:59:19:87:42 > 00:09:4f:c1:40:90, ethertype IPv4 (0x0800), length 190: (tos 0x88, ttl 64, id 35613, offset 0, flags [none], proto UDP (17), length 176)
    192.168.2.104.50579 > 109.250.15.33.51820: [bad udp cksum 0x40d9 -> 0x4b84!] UDP, length 148
14:24:58.130944 00:09:4f:c1:40:90 > 9e:53:59:19:87:42, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 57, id 34121, offset 0, flags [none], proto UDP (17), length 120)
    109.250.15.33.51820 > 192.168.2.104.50579: [udp sum ok] UDP, length 92
35 packets captured
35 packets received by filter
0 packets dropped by kernel

[mat6937]

transfer: 0 B received, 148 B sent

Evtl. liegt es an den "AllowedIPs" der Gegenstelle bzw. am source-NAT (MASQUERADE) und am Routing der peers.
Zeige die Ausgaben von:

Code: Alles auswählen

route -n
iptables -nvx -L POSTROUTING -t nat

von beiden peers.

[snowy]

nachfolgend die Ausgaben vom "defekten" wg-Client
die andere Seite kann ich erst heute abend testen, kann ja von der defekten Seite nicht zugreifen

Code: Alles auswählen

iptables -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    102    0        0 ens33
10.6.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.2.0     0.0.0.0         255.255.255.0   U     102    0        0 ens33
192.168.157.0   0.0.0.0         255.255.255.0   U     101    0        0 ens36

[mat6937]

nachfolgend die Ausgaben vom "defekten" wg-Client

Code: Alles auswählen

iptables -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Konfiguriere zusätzlich auf dem "defekten" wg-Client:

Code: Alles auswählen

iptables -t nat -I POSTROUTING 1 -o wg0 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o ens33 -j MASQUERADE
iptables -t nat -I POSTROUTING 3 -o ens36 -j MASQUERADE

[snowy]

jetzt bin ich natürlich wieder an der Gegenstelle

Poste jetzt trotzdem mal noch die Infos vom WG-Server, vielleicht sind die Informationen trotzdem noch wichtig.
Verstehen tue ich sie nur rudimentär

Code: Alles auswählen

# iptables -nvx -L POSTROUTING -t nat

Chain POSTROUTING (policy ACCEPT 88285 packets, 14541806 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 MASQUERADE  all  --  *      eth0    10.6.0.0/24          0.0.0.0/0            /* wireguard-nat-rule */
  258502 48440490 MASQUERADE  all  --  *      enxb827ebe88bfe  0.0.0.0/0            0.0.0.0/0    
  
# route -n
 
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.193.1   0.0.0.0         UG    202    0        0 enxb827ebe88bfe
10.6.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.193.0   0.0.0.0         255.255.255.0   U     202    0        0 enxb827ebe88bfe

# ip -brief a

lo               UNKNOWN        127.0.0.1/8 ::1/128 
enxb827ebe88bfe  UP             192.168.193.21/24 2001:9e8:36c9:b00:8f4:71ef:9b1a:2e1d/64 fe80::2ec0:8fbf:576d:e772/64 
wlan0            DOWN           
wg0              UNKNOWN        10.6.0.1/24 

[mat6937]

Poste jetzt trotzdem mal noch die Infos vom WG-Server, vielleicht sind die Informationen trotzdem noch wichtig.

Code: Alles auswählen

# iptables -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 88285 packets, 14541806 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 MASQUERADE  all  --  *      eth0    10.6.0.0/24          0.0.0.0/0            /* wireguard-nat-rule */
  258502 48440490 MASQUERADE  all  --  *      enxb827ebe88bfe  0.0.0.0/0            0.0.0.0/0    
  
# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.193.1   0.0.0.0         UG    202    0        0 enxb827ebe88bfe
10.6.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.193.0   0.0.0.0         255.255.255.0   U     202    0        0 enxb827ebe88bfe

Das eth0-Interface gibt es auf dem Server nicht. D. h. man muss dbzgl. für den WireGuard auch nichts konfigurieren.
Wenn schon geschehen, dann ersetzen mit "enxb827ebe88bfe".
Für das wg0-Interface auch eine MASQUERADE-Regel aktivieren:

Code: Alles auswählen

iptables -t nat -I POSTROUTING 1 -o wg0 -j MASQUERADE

[snowy]

ja, die eth0 Zeile ist mir vorhin auch aufgefallen.
Noch eine Leiche von vor dem Update Buster auf Bullseye ?

Code: Alles auswählen

Wenn schon geschehen, dann ersetzen mit "enxb827ebe88bfe".

ähhh, wie mache ich das?
an den iptables habe ich noch nie rumgebastelt

Und ich lerne gerne dazu, auch wenn ich von Netzen nicht so richtig viel verstehe

Code: Alles auswählen

Für das wg0-Interface auch eine MASQUERADE-Regel aktivieren: 
iptables -t nat -I POSTROUTING 1 -o wg0 -j MASQUERADE

kann man in ganz kurzen Worten beschreiben was die Zeile eigentlich macht/bedeutet ?

[mat6937]

ähhh, wie mache ich das?

Du schaust in allen config-Dateien für den WG und an allen anderen möglichen Stellen, die für den WG relevant sind nach, ob dort etwas mit "eth0" steht und wenn ja, dann ersetzen.

kann man in ganz kurzen Worten beschreiben was die Zeile eigentlich macht/bedeutet ?

MASQUERADE ist source-NAT. D. h. die Quelladresse des Pakets wird geändert bzw. festgelegt, so dass der Rückweg immer klar bzw. bekannt/möglich ist. BTW: Das findet man aber alles auch sehr ausführlich im Internet, zum nachlesen.

[snowy]

was mich aber mit der eth0-Zeile wundert, eigentlich würde ich jetzt erwarten, daß damit wireguard serverseitig fehlkonfiguriert und damit gar nichts geht.
Aber zwei andere Clients haben scheinbar damit gar kein Problem und können problemlos über das VPN/wireguard kommunizieren.
Gibt es dafür eine Erklärung?

[mat6937]

was mich aber mit der eth0-Zeile wundert, eigentlich würde ich jetzt erwarten, daß damit wireguard serverseitig fehlkonfiguriert und damit gar nichts geht.
Aber zwei andere Clients haben scheinbar damit gar kein Problem und können problemlos über das VPN/wireguard kommunizieren.
Gibt es dafür eine Erklärung?

Naja, das mit dem eth0 sind dann nur "Schönheitsfehler", denn iptables prüft beim setzen einer Regel nicht, ob es ein Interface "eth0" gibt oder nicht gibt. Und für das tatsächlich vorhandene Interface "enxb827ebe88bfe" gibt es ja auch eine MASQUERADE-Regel.
Wenn Du 2 Clients hast, bei denen die VPN-Verbindung funktioniert, kannst Du deren Konfiguration mit der Konfiguration des Clienten, bei dem die VPN-Verbindung nicht funktioniert, vergleichen.

[snowy]

gerade ist mir wieder eingefallen, daß damals nach dem Upgrade von Buster auf Bullseye Wireguard nicht mehr funktioniert hat
Vermutlich wegen dieser iptables Zeile mit der nach dem Upgrade falschen Interface Bezeichnung

Bei der Fehlersuche bin ich dann im Internet auf Hinweise gestoßen, daß man folgende Regeln in die wg0.conf aufnehmen soll

Code: Alles auswählen

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enxb827ebe88bfe -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o enxb827ebe88bfe -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enxb827ebe88bfe -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o enxb827ebe88bfe -j MASQUERADE

Und danach funktioniert das VPN wieder.
Aus Laiensicht würde ich sagen, damit überschreibe ich wohl dynamisch die falsche Regel.

Wenn Du 2 Clients hast, bei denen die VPN-Verbindung funktioniert, kannst Du deren Konfiguration mit der Konfiguration des Clienten, bei dem die VPN-Verbindung nicht funktioniert, vergleichen.

das habe ich schon zigfach vor Eröffnung dieses Threads gemacht.
Außer den natürlich unterschiedlichen Keys kann ich keine Unterschiede sehen.
Und der wg-Server läßt den 3. Client ja auch rein, d.h. der Key-Handshake scheint erfolgreich zu sein. Nur findet danach keinerlei Kommunikation mehr statt und alle IP-Paket des Clients laufen scheinbar auf Fehler "Browser Timeout, dig keine Antwort, ...."

[mat6937]

... auf Fehler "Browser Timeout, ...

Schau mal nach wie die MTU in deinem WG-VPN eingestellt/konfiguriert ist.
Versuch mal (als Test) überall im WG-VPN, mit einer MTU von z. B. 1392.

[snowy]

das habe ich schon zigfach vor Eröffnung dieses Threads gemacht.
Außer den natürlich unterschiedlichen Keys kann ich keine Unterschiede sehen

man kann es kontrollieren und kontrollieren, aber scheinbar war doch ein Fehler in der Konfiguration des Clients auf Seiten des WG-Servers.
Client auf Serverseite entfernt und nochmals neu aufgesetzt.
Schwupps, lief das VPN

Danke an @mat6937 für seine geduldige Unterstützung