lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Im Netzwerkmanager käme m.E. nur folgende Option in Betracht (siehe Screenshot):
Naja, aus diesem Screenshot werde ich nicht schlau. Was ist "zu überwachender Port" und warum steht das mit dem "Listen port number" weiter unten bei "fwmark"? Oder hast Du das dort eingetragen, vor dem erstellen des Screenshots?
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Das, was über dem Feld "fwmark" steht, wird als Erklärung für das darüber stehende Feld "Zu überwachender Port" eingeblendet, wenn man mit der Maus über letzteres drüberhovert. Das verdeckt dann das Eingabefeld für "fwmark". EDIT:
"Zu überwachender Port" klang für mich am ehesten nach "ListenPort". Ich habe jetzt in die Konfigurationsdatei /etc/wireguard/Pulse15.conf (für das wg-quick up-Szenario) im Abschnitt "Interface" die Zeile
ListenPort = 59980
eingefügt.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Das, was über dem Feld "fwmark" steht, wird als Erklärung für das darüber stehende Feld "Zu überwachender Port" eingeblendet, wenn man mit der Maus über letzteres drüberhovert.
OK, dann wird der "zu überwachende Port", der feste Port sein auf dem der WG-Client lauscht bzw. den er als source-Port benutzt.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Ich habe jetzt in die Konfigurationsdatei /etc/wireguard/Pulse15.conf (für das wg-quick up-Szenario) im Abschnitt "Interface" die Zeile
ListenPort = 59980
eingefügt.
OK, im NM kannst Du dann den Port:
59981
eintragen.
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Okay, nächster Test, diesmal mit angepassten Ports: 59980 im wg-quick up-Szenario (/etc/wireguard/Pulse15.conf) und 59981 im NM-Szenario (eingetragen in der GUI-Konfiguration). Netzwerkmanager-Szenario: Client:
interface: Pulse15
public key: $CLIENT_PUBLIC_KEY
private key: (hidden)
listening port: 59981
fwmark: 0xcb0d
peer: $PI_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:5998
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 10 seconds ago
transfer: 17.76 KiB received, 17.11 KiB sent
Server:
interface: wg0
public key: $PI_PUBLIC_KEY
private key: (hidden)
listening port: 5998
peer: $CLIENT_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:30805
allowed ips: 10.6.0.4/32
latest handshake: 1 minute, 17 seconds ago
transfer: 1.96 MiB received, 4.77 MiB sent
In diesem Fall war auch im NM-Szenario ein Ping (sowohl auf den Pi - 10.6.0.1/24 - als auch auf einen Host in meinem Heimnetz - 192.168.69.1) erfolgreich! wg-quick up-Szenario: Client:
interface: Pulse15
public key: $CLIENT_PUBLIC_KEY
private key: (hidden)
listening port: 59980
fwmark: 0xca6c
peer: $PI_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:5998
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 3 seconds ago
transfer: 8.64 KiB received, 5.71 KiB sent
Server:
interface: wg0
public key: $PI_PUBLIC_KEY
private key: (hidden)
listening port: 5998
peer: $CLIENT_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:16680
allowed ips: 10.6.0.4/32
latest handshake: 23 seconds ago
transfer: 2.05 MiB received, 4.87 MiB sent Jetzt funktioniert die Verbindung auch per Netzwerkmanager. Heißt das jetzt, dass die zufällige Wahl ("choosen randomly...") des ListenPorts seitens des Netzwerkmanagers verbuggt / defekt ist ? Oder fehlt in der Konfigurationsdatei (die ich in den Netzwerkmanager importiert habe) ein Hinweis darauf, dass er sich den Port selbst aussuchen soll ? Auf jeden Fall an dieser Stelle schonmal vielen herzlichen Dank für deine Zeit und dein Know-How! 👍
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Okay, nächster Test, diesmal mit angepassten Ports: 59980 im wg-quick up-Szenario (/etc/wireguard/Pulse15.conf) und 59981 im NM-Szenario (eingetragen in der GUI-Konfiguration). Netzwerkmanager-Szenario:
Server:
peer: $CLIENT_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:30805
allowed ips: 10.6.0.4/32
latest handshake: 1 minute, 17 seconds ago
transfer: 1.96 MiB received, 4.77 MiB sent
wg-quick up-Szenario:
Server:
peer: $CLIENT_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:16680
allowed ips: 10.6.0.4/32
latest handshake: 23 seconds ago
transfer: 2.05 MiB received, 4.87 MiB sent Jetzt funktioniert die Verbindung auch per Netzwerkmanager.
Hast Du zwischen den beiden Szenarien, den wg-Server neu gestartet? Ich verstehe es trotzdem nicht ... Warum wird vom Server, beim peer-Endpoint als Port, nicht der fest konfigurierte ListenPort des WG-Clienten angezeigt? Schau mal mit tcpdump in beiden Szenarien nach, welchen source-Port der WG-Client zum herstellen des WG-Tunnels benutzt. EDIT: Evtl. hast Du nur die Porteintragungen beim WG-Client für beide Szenarien gemacht, aber nicht dafür gesorgt, dass diese Eintragungen (d. h. diese Änderungen in der Konfiguration des WG-Client) auch wirksam werden? Hast Du den WG-Client, nach den Änderungen, neu gestartet? EDIT 2: Patient0 schrieb: Heißt das jetzt, dass die zufällige Wahl ("choosen randomly...") des ListenPorts seitens des Netzwerkmanagers verbuggt / defekt ist ?
Nein, es liegt nicht am NM. Ich habe das jetzt mit dem WG-Server auf Linux(raspbian), FreeBSD und OpenBSD getestet. Das Problem liegt in der Authentifizierung beim WG-Server. Der source-Port des WG-Clienten ist in der Authentifizierung mit beinhaltet. Mit einem festen source Port beim WG-Client hatte ich keine Probleme und mit einem geänderten source-Port lehnt der WG-Server die Neu-Verbindung ab. Evtl. gibt es auch einen timeout für den geänderten source-Port beim WG-Client, der aber für eine sofortige Neu-Verbindung des WG-Clienten nutzlos ist.
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Zu früh gefreut. Der Erfolg ist nicht reproduzierbar. Ein erneuter Versuch mit der NM-Veriante funktioniert wieder nicht. lubux schrieb: Hast Du zwischen den beiden Szenarien, den wg-Server neu gestartet?
Nein. Würde das einen Unterschied machen ? Ich habe ja nur die Client-Konfiguration geändert.
Ich verstehe es trotzdem nicht ... Warum wird vom Server, beim peer-Endpoint als Port, nicht der fest konfigurierte ListenPort des WG-Clienten angezeigt? Schau mal mit tcpdump in beiden Szenarien nach, welchen source-Port der WG-Client zum herstellen des WG-Tunnels benutzt.
tcpdump ergibt jetzt im Netzwerkmanager-Szenario wieder keine Ausgaben (also kommt keine Verbindung zu Stande), im wg-quick up-Szenario kommen folgende Ausgaben (je eine beispielhafte In-/Output-Verbindung aus Sicht des Clients):
13:42:59.772399 IP 192.168.43.50.59980 > 36d2150e.access.ecotel.net.5998: UDP, length 112
13:43:00.006223 IP 36d2150e.access.ecotel.net.5998 > 192.168.43.50.59980: UDP, length 208
wg-quick up-Szenario, tcpdump aus Sicht des Servers:
14:07:16.417326 IP 192.168.69.175.5998 > dynamic-046-109-134-116.32.145.pool.telefonica.de.15301: UDP, length 240
14:07:16.481724 IP dynamic-046-109-134-116.32.145.pool.telefonica.de.15301 > 192.168.69.175.5998: UDP, length 96
Schließe ich daraus korrekt, dass er den in der /etc/wireguard/Pulse15.conf gesetzen Port nicht nutzt ?
Evtl. hast Du nur die Porteintragungen beim WG-Client für beide Szenarien gemacht, aber nicht dafür gesorgt, dass diese Eintragungen (d. h. diese Änderungen in der Konfiguration des WG-Client) auch wirksam werden? Hast Du den WG-Client, nach den Änderungen, neu gestartet?
Wie starte ich den Client neu ? Der Client ist doch kein dauerhaft laufender Dienst, den ich neu starten müsste, oder ? Ich habe natürlich immer erst die Verbindung des einen Szenarios beendet (im GUI Verbindung beendet bzw. wg-quick down Pulse15), bevor ich das nächste gestartet habe.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Nein. Würde das einen Unterschied machen ? Ich habe ja nur die Client-Konfiguration geändert.
Nach Änderungen in der config, muss der Client (oder der server) neu gestartet werden. Versuch mit:
sudo wg setconf wg0 /etc/wireguard/wg0.conf
(oder gleichwertig; d. h. das wg-Interface, den Pfad und die config-datei anpassen).
Zwischen den Tests mit den verschiedenen Szenarien musst Du auch den WG-Server neu starten, damit er den source-Port vom WG-Client vergessen kann. Siehe mein EDIT 2 oben. EDIT: Patient0 schrieb: Der Client ist doch kein dauerhaft laufender Dienst, den ich neu starten müsste, oder ?
Doch, der WG-Client ist ein dauerhaft laufender Dienst, genau so wie der WG-Server.
Das kannst Du mit "ip a", "ss -u -a -n", mit tcpdump, mit "sudo wg" auf dem Client und mit der debug-Funktion von WireGuard (dmesg) sehen. BTW: Auf dem WG-Client solltest Du auch "PersistentKeepalive" konfigurieren.
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
lubux schrieb: Nach Änderungen in der config, muss der Client (oder der server) neu gestartet werden. Versuch mit:
sudo wg setconf wg0 /etc/wireguard/wg0.conf
(oder gleichwertig; d. h. das wg-Interface, den Pfad und die config-datei anpassen).
Beim Server (Pi) ergibt der angepasste Befehl:
sudo wg setconf wg0 /etc/wireguard/wg0.conf
Line unrecognized: `Address=10.6.0.1/24'
Configuration parsing error
Auf dem Client ergibt der angepasste Befehl:
sudo wg setconf Pulse15 /etc/wireguard/Pulse15.conf
Line unrecognized: `Address=10.6.0.4/24'
Configuration parsing error
Zwischen den Tests mit den verschiedenen Szenarien musst Du auch den WG-Server neu starten, damit er den source-Port vom WG-Client vergessen kann. Siehe mein EDIT 2 oben.
Als Systemd-Service gibt es von Wireguard auf dem Server "wg-quick@wg0.service" (das WG-Interface des Pi's heißt wg0).
Diesen einfach per
sudo systemctl restart wg-quick@wg0.service
neu starten, nehme ich an ? EDIT:
lubux schrieb: EDIT:
Patient0 schrieb: Der Client ist doch kein dauerhaft laufender Dienst, den ich neu starten müsste, oder ?
Doch, der WG-Client ist ein dauerhaft laufender Dienst, genau so wie der WG-Server.
Das kannst Du mit "ip a", "ss -u -a -n", mit tcpdump, mit "sudo wg" auf dem Client und mit der debug-Funktion von WireGuard (dmesg) sehen.
Der Befehl wg-quick down scheint diesen Dienst aber zu beenden. Nach wg-quick down sehe ich mit "ip a" und "sudo wg" kein vorhandenes Wireguard-Interface mehr. (nach dem Beenden der Verbindung über den Netzwerk-Manager übrigens auch nicht). BTW: Auf dem WG-Client solltest Du auch "PersistentKeepalive" konfigurieren.
Das hat aber nichts damit zu tun, dass die Verbindung gar nicht erst aufgebaut wird, nehme ich an ?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Als Systemd-Service gibt es von Wireguard auf dem Server "wg-quick@wg0.service" (das WG-Interface des Pi's heißt wg0).
Diesen einfach per
sudo systemctl restart wg-quick@wg0.service
neu starten, nehme ich an ?
Ja, ... siehe aber vor und nach dem Restart, die Ausgabe von:
systemctl status wg-quick@wg0.service
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Die Ausgabe des Status ist davor wie danach identisch.
sudo systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2021-03-21 14:47:48 CET; 5s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 29774 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 29774 (code=exited, status=0/SUCCESS)
Mär 21 14:47:48 PiVPN systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] ip link add wg0 type wireguard
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] wg setconf wg0 /dev/fd/63
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] ip -4 address add 10.6.0.1/24 dev wg0
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] ip link set mtu 1420 up dev wg0
Mär 21 14:47:48 PiVPN systemd[1]: Started WireGuard via wg-quick(8) for wg0.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Die Ausgabe des Status ist davor wie danach identisch.
Kann nicht sein. Schau dir die Zeilen:
Active: active (exited) since Sun 2021-03-21 14:47:48 CET; 5s ago
Process: 29774 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 29774 (code=exited, status=0/SUCCESS)
bzw. die Zeilen mit Datum und Uhrzeit an. EDIT: Hier ein Beispiel für das sich immer wiederholende handshake/rekeying bei einer funktionierenden Tunnel-Verbindung zwischen WG-Server und WG-Client (oder zwischen zwei WG-peers):
Mar 21 14:34:10 yxyxyx user.debug kernel: [19822.172202] wireguard: wg0: Sending handshake initiation to peer 1 (192.168.xxx.xx:#####)
Mar 21 14:34:10 yxyxyx user.debug kernel: [19822.190658] wireguard: wg0: Receiving handshake response from peer 1 (192.168.xxx.xx:#####)
Mar 21 14:34:10 yxyxyx user.debug kernel: [19822.190680] wireguard: wg0: Keypair 403 destroyed for peer 1
Mar 21 14:34:10 yxyxyx user.debug kernel: [19822.190685] wireguard: wg0: Keypair 409 created for peer 1
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
lubux schrieb: Kann nicht sein.
Tatsache. Mein Fehler. davor:
sudo systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2021-03-21 14:30:43 CET; 15min ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 29401 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 29401 (code=exited, status=0/SUCCESS)
Mär 21 14:30:43 PiVPN systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Mär 21 14:30:43 PiVPN wg-quick[29401]: [#] ip link add wg0 type wireguard
Mär 21 14:30:43 PiVPN wg-quick[29401]: [#] wg setconf wg0 /dev/fd/63
Mär 21 14:30:43 PiVPN wg-quick[29401]: [#] ip -4 address add 10.6.0.1/24 dev wg0
Mär 21 14:30:43 PiVPN wg-quick[29401]: [#] ip link set mtu 1420 up dev wg0
Mär 21 14:30:43 PiVPN systemd[1]: Started WireGuard via wg-quick(8) for wg0.
Neustart:
sudo systemctl restart wg-quick@wg0.service
Danach:
sudo systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: active (exited) since Sun 2021-03-21 14:47:48 CET; 5s ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 29774 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
Main PID: 29774 (code=exited, status=0/SUCCESS)
Mär 21 14:47:48 PiVPN systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] ip link add wg0 type wireguard
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] wg setconf wg0 /dev/fd/63
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] ip -4 address add 10.6.0.1/24 dev wg0
Mär 21 14:47:48 PiVPN wg-quick[29774]: [#] ip link set mtu 1420 up dev wg0
Mär 21 14:47:48 PiVPN systemd[1]: Started WireGuard via wg-quick(8) for wg0. EDIT: Habe jetzt nochmal getestet, diesmal mit einem Neustart "sudo systemctl restart wg-quick@wg0.service" auf dem Pi dazwischen. Dmesg meldet auf dem Server in beiden Szenarien (egal, ob es funktioniert oder nicht) nichts zu Wireguard.
Im funktionierenden wg-quick up-Szenario gibt "sudo wg" auf dem Server (Pi) folgendes aus:
interface: wg0
public key: $PI_PUBLIC_KEY
private key: (hidden)
listening port: 5998
peer: $CLIENT_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:4126
allowed ips: 10.6.0.4/32
latest handshake: 20 seconds ago
transfer: 47.24 KiB received, 19.71 KiB sent Im wg-quick up-Szenario steht auf dem Client im Output von
dmesg
[186436.296411] wireguard: Pulse15: Sending handshake initiation to peer 38 ($PUBLIC_IP:5998)
[186436.363085] wireguard: Pulse15: Receiving handshake response from peer 38 ($PUBLIC_IP:5998)
[186436.363091] wireguard: Pulse15: Keypair 57 created for peer 38
und die Ausgabe eines (ebenfalls auf dem Client ausgeführten)
sudo tcpdump 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'
16:21:33.806840 IP 192.168.43.50.59980 > 36d2150e.access.ecotel.net.5998: UDP, length 112
16:21:33.892620 IP 36d2150e.access.ecotel.net.5998 > 192.168.43.50.59980: UDP, length 96
Hier (bei wg-quick up) scheint er also den gesetzten Port zu übernehmen. Ein auf dem Server ausgeführtes
sudo tcpdump 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'
16:27:08.926159 IP dynamic-046-109-134-116.32.145.pool.telefonica.de.4126 > 192.168.69.175.5998: UDP, length 1280
16:27:08.926765 IP 192.168.69.175.5998 > dynamic-046-109-134-116.32.145.pool.telefonica.de.4126: UDP, length 96 Im NM-Szenario ergibt ein auf dem Client ausgeführtes
sudo dmesg
[185026.047480] wireguard: Pulse15: Interface created
[185026.129892] wireguard: Pulse15: Peer 32 created
[185026.133538] net_ratelimit: 38 callbacks suppressed
[185026.133540] wireguard: Pulse15: No valid endpoint has been configured or discovered for peer 32
[185026.158907] wireguard: Pulse15: No valid endpoint has been configured or discovered for peer 32
[185026.207589] wireguard: Pulse15: No valid endpoint has been configured or discovered for peer 32
usw. usf.
[186574.391220] wireguard: Pulse15: Sending handshake initiation to peer 39 ($PUBLIC_IP:5998)
[186579.511298] wireguard: Pulse15: Handshake for peer 39 ($PUBLIC_IP:5998) did not complete after 5 seconds, retrying (try 2)
[186579.511356] wireguard: Pulse15: Sending handshake initiation to peer 39 ($PUBLIC_IP:5998)
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Patient0 schrieb: Dmesg meldet auf dem Server in beiden Szenarien (egal, ob es funktioniert oder nicht) nichts zu Wireguard.
Ja das ist richtig, und Du hast doch gesehen, dass im raspbian der Kernel, ohne WIREGURAD_DEBUG kompiliert worden ist. Patient0 schrieb: Im funktionierenden wg-quick up-Szenario gibt "sudo wg" auf dem Server (Pi) folgendes aus:
interface: wg0
public key: $PI_PUBLIC_KEY
private key: (hidden)
listening port: 5998
peer: $CLIENT_PUBLIC_KEY
preshared key: (hidden)
endpoint: $PUBLIC_IP:4126
allowed ips: 10.6.0.4/32
latest handshake: 20 seconds ago
transfer: 47.24 KiB received, 19.71 KiB sent
Das verstehe ich nicht. Du hast doch im Client einen festen Port konfiguriert. Woher kommt der Port 4126 für den Client?
Poste mal die richtig anonymisierte config des Clienten, die mit wg-quick benutzt wird. BTW: Wenn Du zwischen den Clients (NM und wg-quick) wechselst, solltest Du den aktiven Client immer richtig stoppen/beenden/deaktivieren, danach den WG auf dem Server restarten und erst danach mit dem anderen Client verbinden. Beide Clients sollen nicht gleichzeitig aktiv sein. Das ist ja auch nur eine Ausnahme (d. h. zum testen), dass Du 2 Clients von einem Gerät benutzt. I. d. R. sollte man nur einen Client benutzen (entweder mit dem NM oder mit wg-quick).
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
lubux schrieb: Das verstehe ich nicht. Du hast doch im Client einen festen Port konfiguriert. Woher kommt der Port 4126 für den Client?
Poste mal die richtig anonymisierte config des Clienten, die mit wg-quick benutzt wird.
sudo cat /etc/wireguard/Pulse15.conf
[Interface]
Address = 10.6.0.4/24
PrivateKey = $PRIVATE_KEY
ListenPort = 59980
DNS = 10.6.0.1
[Peer]
PublicKey = $PI_PUBLIC_KEY
PresharedKey = $PSK
Endpoint = $DYNDNS_FQDN:5998
AllowedIPs = 0.0.0.0/0, ::0/0
Das entsprechende Gegenstück aus der /etc/wireguard/wg0.conf des Servers:
sudo cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = $PI_PRIVATE_KEY
Address = 10.6.0.1/24
ListenPort = 5998
### begin Pulse15 ###
[Peer]
PublicKey = $CLIENT_PUBLIC_KEY
PresharedKey = $PSK
AllowedIPs = 10.6.0.4/32
### end Pulse15 ###
BTW: Wenn Du zwischen den Clients (NM und wg-quick) wechselst, solltest Du den aktiven Client immer richtig stoppen/beenden/deaktivieren, danach den WG auf dem Server restarten und erst danach mit dem anderen Client verbinden.
Wie oben bereits geschrieben verstehe ich nicht zu 100%, ob das stoppen/beenden/deaktivieren über entweder das Deaktivieren im Netzwerkmanager oder ein "wg-quick down Pulse15" hinaus geht. Nach beiden Methoden ist das Interface (geprüft mit "ip a") weg und zeigt "sudo wg" nichts mehr an. Genauso gibt "sudo tcpdump 'udp[8:4] >= 0x1000000 and udp[8:4] ⇐ 0x4000000'" nichts mehr aus. Gibt es noch irgendein Deaktivieren / Beenden, was darüber hinaus geht ? Beide Clients sollen nicht gleichzeitig aktiv sein. Das ist ja auch nur eine Ausnahme (d. h. zum testen), dass Du 2 Clients von einem Gerät benutzt. I. d. R. sollte man nur einen Client benutzen (entweder mit dem NM oder mit wg-quick).
Das ist mir soweit klar. Daher beende ich die jeweilige Methode ja auch immer vor dem Start der jeweils anderen.
|