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?
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.
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.
hm, 0.0.20180625 ist ur-alt, bei der Entwicklungsgeschwindigkeit von Wireguard würd ich da erstmal nen Update machen…
Siehe: https://wiki.debian.org/Wireguard#Installation
Dann nochmal berichten ob das Problem noch auftritt…
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.
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 )