Wireguard ändert eigenständig IP des Tunnelendpunktes

Technik
1

Ich versuche derzeit, die Verbindung zwischen den Systemen von L2TP auf (L2TP-over-) Wireguard umzustellen. Problem dabei: ich stelle in der /etc/wireguard/NAME.conf einen Tunnel zwischen den externen IPs ein, nach kurzer Laufzeit ändert Wireguard die Zieladresse aber auf interne Adressen. Tunnelverkehr durch den eigeen Tunnel zu schieben klappt aber eher nur so semi gut.

Das Verhalten ist zwar schnuckelig für Raodwarrior-Szenarien (von immer wechselnden IPs sich auf zentrales GW verbinden), macht Wireguard hier aber gerade unbrauchbar. Kennt dieses Problem schon jemand und, wichtiger, konnte er/sie/es Wireguard die dynamsche IP-Änderung abgewöhnen?

2

Benutzt Du einen speziellen fork ?
Der normale WG macht solche Spielchen nicht.
Wir haben das seit ca. 1 Jahr zum testen als site2site VPN laufen um unsere dev Umgebungen zu verbinden.

Ansonsten poste doch mal deine config

3

WireGuard-Pakete, s. u.; Config ist ja nicht viel … /etc/wireguard/wg-ZIEL.conf

[Interface]
ListenPort = 42424
PrivateKey = ...
# Address = 198.51.255.3 <> 198.51.255.7
# Address = 2001:bf7:1317:fffe:2::3/64


[Peer]
PublicKey = ...
AllowedIPs = 198.51.255.7/32, 2001:bf7:1317:fffe:2::7/128
Endpoint = fq.dn:42424

fq.dn löst auf 217… auf. Nach etwas Laufzeit:

root@QUELLE:~# wg show VZIEL
interface: VZIEL
  public key: ...
  private key: (hidden)
  listening port: 42424

peer: ...
  endpoint: 193.…:42424
  allowed ips: 198.51.255.7/32, 2001:bf7:1317:fffe:2::7/128
  latest handshake: 12 days, 7 hours, 24 minutes, 12 seconds ago
  transfer: 367.80 KiB received, 365.62 KiB sent

Irgendwie hat wg wohl ein Paket mit interner IP bekommen, und aufgrund des Ansatzes, alles authentifizierte anzunehmen, die Ziel-IP angepaßt. Und damit ist der Tunnel tot. Bei OpenVPN und anderen Protokollen muß man derlei explizit erlauben — ich habe nicht gefunden, wie man das Verhalten WireGuard verbieten kann.

root@QUELLE:~# dpkg -S $(which wg)
wireguard-tools: /usr/bin/wg
root@QUELLE:~# dpkg -l wireguard-tools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                  Version         Architecture    Description
+++-=====================-===============-===============-================================================
ii  wireguard-tools       0.0.20180625-wg amd64           fast, modern, secure kernel VPN tunnel (userland
4

hm, 0.0.20180625 ist ur-alt, bei der Entwicklungsgeschwindigkeit von Wireguard würd ich da erstmal nen Update machen…
Siehe: WireGuard - Debian Wiki
Dann nochmal berichten ob das Problem noch auftritt…

5

Problem besteht weiterhin, genauer: ein unerwünschter Nebeneffekt des »Built-in Roaming«-Features’. Wireguard bekommt ein Paket mit der falschen (internen) IP und ändert die Zieladresse — die aber hinter dem fraglichen Link liegt und damit war’s das:

root@gut01:~# ifup Vber01
root@gut01:~# wg show Vber01
interface: Vber01
  public key: hqj...
  private key: (hidden)
  listening port: 42424

peer: xte...
  endpoint: 217.2...:42424
  allowed ips: 198.51.255.3/32, 2001:bf7:1317:fffe:2::3/128

root@ber01:~# ping 198.51.255.7
PING 198.51.255.7 (198.51.255.7) 56(84) bytes of data.
64 bytes from 198.51.255.7: icmp_seq=1 ttl=64 time=16.5 ms
64 bytes from 198.51.255.7: icmp_seq=2 ttl=64 time=30.0 ms
64 bytes from 198.51.255.7: icmp_seq=3 ttl=64 time=17.0 ms
^C
--- 198.51.255.7 ping statistics ---
14 packets transmitted, 3 received, 78% packet loss, time 13007ms
rtt min/avg/max/mdev = 16.576/21.215/30.040/6.244 ms

root@gut01:~# wg show Vber01
interface: Vber01
  public key: hqj...
  private key: (hidden)
  listening port: 42424

peer: xte...
  endpoint: 193....:42424
  allowed ips: 198.51.255.3/32, 2001:bf7:1317:fffe:2::3/128
  latest handshake: 23 seconds ago
  transfer: 1.90 KiB received, 1.68 KiB sent

Doof, aber nicht zu ändern; also doch OpenVPN für da, wo GRE/L2TP eingeschränkt wird.

6

Hrmpft. Es fehlte auf einer Seite die Route „außenrum“ (Typo), daher der „Leak“ der internen Adresse. (Trotzdem wäre Abschaltmöglichkeit des Roamings schön, ein falsches Paket und das war’s :frowning: )