[gelöst] wireguard neuer Client - connect ja, kein Transfer
[gelöst] wireguard neuer Client - connect ja, kein Transfer
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
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
Zuletzt geändert von snowy am 14.11.2021 18:09:30, insgesamt 1-mal geändert.
Re: wireguard neuer Client - connect ja, kein Transfer
Und durch Eintrag des pubkey beim anderen WireGuard-Server, oder?snowy hat geschrieben:31.10.2021 16:30:33Das Umhängen auf den anderen Wireguard-Server hat nur durch Überschreiben der Client-Konfiguration wg0.conf stattgefunden.
Poste mal vom Client und vom Server die richtig anonymisierten Ausgaben von:
Code: Alles auswählen
wg
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>
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'
Re: wireguard neuer Client - connect ja, kein Transfer
@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
Der Rechner ist nicht vor Ort, aber demnächst bin ich wieder dort und werde dann berichten
Re: wireguard neuer Client - connect ja, kein Transfer
@mat6937, konnte zwar noch nicht die Tests durchführen, aber ich habe mir Deine Anweisungen nochmals durchgelesen.
Netzwerkseitig bin ich nicht sehr gut bewandert
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.
Netzwerkseitig bin ich nicht sehr gut bewandert
Code: Alles auswählen
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
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.
Re: wireguard neuer Client - connect ja, kein Transfer
Alles geht nach stdout (tcpdump) bzw. syslog/dmesg. Es muss nicht in eine Datei umgeleitet werden.snowy hat geschrieben:02.11.2021 21:45:42wo geht das der Debugging-Output hin? Und wie schalte ich das Debugging dann wieder ab?Code: Alles auswählen
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
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.
Beenden kannst Du mit:
Code: Alles auswählen
echo module wireguard -p > /sys/kernel/debug/dynamic_debug/control
Re: wireguard neuer Client - connect ja, kein Transfer
@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
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
Re: wireguard neuer Client - connect ja, kein Transfer
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
Re: wireguard neuer Client - connect ja, kein Transfer
nachfolgend die Ausgaben vom "defekten" wg-Client
die andere Seite kann ich erst heute abend testen, kann ja von der defekten Seite nicht zugreifen
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
Re: wireguard neuer Client - connect ja, kein Transfer
Konfiguriere zusätzlich auf dem "defekten" wg-Client:snowy hat geschrieben:13.11.2021 14:59:10nachfolgend die Ausgaben vom "defekten" wg-ClientCode: 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
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
Re: wireguard neuer Client - connect ja, kein Transfer
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
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
Re: wireguard neuer Client - connect ja, kein Transfer
Das eth0-Interface gibt es auf dem Server nicht. D. h. man muss dbzgl. für den WireGuard auch nichts konfigurieren.snowy hat geschrieben:13.11.2021 20:12:46Poste 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
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
Re: wireguard neuer Client - connect ja, kein Transfer
ja, die eth0 Zeile ist mir vorhin auch aufgefallen.
Noch eine Leiche von vor dem Update Buster auf Bullseye ?
ä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
kann man in ganz kurzen Worten beschreiben was die Zeile eigentlich macht/bedeutet ?
Noch eine Leiche von vor dem Update Buster auf Bullseye ?
Code: Alles auswählen
Wenn schon geschehen, dann ersetzen mit "enxb827ebe88bfe".
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
Re: wireguard neuer Client - connect ja, kein Transfer
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.
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 hat geschrieben:13.11.2021 22:04:12kann man in ganz kurzen Worten beschreiben was die Zeile eigentlich macht/bedeutet ?
Re: wireguard neuer Client - connect ja, kein Transfer
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?
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?
Re: wireguard neuer Client - connect ja, kein Transfer
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.snowy hat geschrieben:13.11.2021 22:16:55was 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?
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.
Re: wireguard neuer Client - connect ja, kein Transfer
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
Und danach funktioniert das VPN wieder.
Aus Laiensicht würde ich sagen, damit überschreibe ich wohl dynamisch die falsche Regel.
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, ...."
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
Aus Laiensicht würde ich sagen, damit überschreibe ich wohl dynamisch die falsche Regel.
das habe ich schon zigfach vor Eröffnung dieses Threads gemacht.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.
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, ...."
Re: wireguard neuer Client - connect ja, kein Transfer
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.
Re: wireguard neuer Client - connect ja, kein Transfer
man kann es kontrollieren und kontrollieren, aber scheinbar war doch ein Fehler in der Konfiguration des Clients auf Seiten des WG-Servers.das habe ich schon zigfach vor Eröffnung dieses Threads gemacht.
Außer den natürlich unterschiedlichen Keys kann ich keine Unterschiede sehen
Client auf Serverseite entfernt und nochmals neu aufgesetzt.
Schwupps, lief das VPN
Danke an @mat6937 für seine geduldige Unterstützung