Wireguard MASQUERADE

[SeaSide]

Hallo,

ich habe mal eine Verständnisfrage zur Funktionsweise. Irgendwie finde ich dazu nichts im Netz.

Viele Konfigurationsbeschreibungen von Wireguard sind wie folgt eingerichtet bzw. werden so empfohlen:

Code: Alles auswählen

Address = 10.8.0.1/24
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

In einem Aufbau mit internem Netz, einem Debianserver inkl. Wireguard in dem internen Netz, und diverse Handys (Clints) mit Wireguard im Internet; verbinden sich auf diesem Wege via Tunnel nach Hause durch eine Firewall/Router (noch ohne Wireguard). Die Der Port wird am Gateway des Internets nur durchgereicht zum og. Debianserver. Funktioniert soweit gut. Alles gut. Auf dem Debianserver vergibt WG an die Clients IPs wie 10.8.0.3.
Nach innen ins Heimnetz sind die Clients aber mit dem inneren IP Bereich erkennbar. Dies wegen Masquerade. Alles soweit gut. Mir stellt sich die Frage, wie der Debianserver bzw, Wireguard zu den inneren IPs kommt. Holt er sich die DHCP Server, der er nicht selbst ist? Oder nimmt er irgendwelche IPs hinsichtlich Gefahrt der Doppeltvergabe. Es ist auch schwer nachzuvollziehen, welche IPs da genommen wurde. Erst mit IP Tracemethoden lässt sich das herausfinden. Kann hier mal jemand etwas Licht ins Dunkle bringen?

[mat6937]

Auf dem Debianserver vergibt WG an die Clients IPs wie 10.8.0.3.

Bist Du sicher, dass der Debian-Server die WG-VPN-IP-Adressen an die Peers zuweist? Wer hat dein WireGuard-VPN (Server und Clients) konfiguriert/eingerichtet?

Mir stellt sich die Frage, wie der Debianserver bzw, Wireguard zu den inneren IPs kommt.

Was genau meinst Du mit "inneren IPs"?
Wie sind auf dem Debian-Server die Ausgaben von:

Code: Alles auswählen

wg   # richtig/brauchbar anonymisiert
ip a
ip r
ip r g 10.8.0.3
ip r g <innere-IP-Adresse-Client>
iptables -nvx -L -t nat

?

[SeaSide]

Hallo,

das ist eine Standardkonfig die man überall an zig Stellen im Netz findet.
Der Server befindet sich im Heimnetz.
Da der Server aber nicht selbst der DHCP Server ist muss er bei Nutzung von MASQUERADE ja irgendwo die IPs herbekommen.

Folgende Infos zu den Abfragen.
WG:

Code: Alles auswählen

interface: wg0
  public key: xxxxxxxxx
  private key: (hidden)
  listening port: 51829

peer: xxxxxxxxxxxxx
  endpoint: 109.xxx.xxx.xxx:2204
  allowed ips: 10.8.0.3/32
  latest handshake: 19 seconds ago
  transfer: 61.03 MiB received, 1.03 GiB sent

peer: xxxxxxxxxxxxxxx
  endpoint: 91.xxx.xxx.xxx:38569
  allowed ips: 10.8.0.2/32
  latest handshake: 1 minute, 58 seconds ago
  transfer: 20.14 MiB received, 219.26 MiB sent

peer: xxxxxxxxxxxxxxxxx
  endpoint: 91.xxx.xxx.xxx:48520
  allowed ips: 10.8.0.4/32
  latest handshake: 18 hours, 35 minutes, 39 seconds ago
  transfer: 53.70 MiB received, 434.73 MiB sent

ip a:

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:00:02:01 brd ff:ff:ff:ff:ff:ff
    inet 172.28.0.10/16 brd 172.28.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe00:201/64 scope link
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.8.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

ip r:

Code: Alles auswählen

default via 172.28.0.1 dev eth0 onlink
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1
172.28.0.0/16 dev eth0 proto kernel scope link src 172.28.0.10

ip r g 10.8.0.3

Code: Alles auswählen

10.8.0.3 dev wg0 src 10.8.0.1 uid 0
    cache

ip r g 172.28.0.66

Code: Alles auswählen

172.28.0.66 dev eth0 src 172.28.0.10 uid 0
    cache

iptables -nvx -L -t nat

Code: Alles auswählen

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
   13150  4081949 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

[mat6937]

Da der Server aber nicht selbst der DHCP Server ist muss er bei Nutzung von MASQUERADE ja irgendwo die IPs herbekommen.

ip r:

Code: Alles auswählen

default via 172.28.0.1 dev eth0 onlink
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1
172.28.0.0/16 dev eth0 proto kernel scope link src 172.28.0.10

Code: Alles auswählen

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
   13150  4081949 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Das WG-VPN-Subnetz 10.8.0.0/24 bzw. die IP-Adressen aus diesem Subnetz, für den WG-Server und die WG-Clients ist von dem der die WG-VPN konfiguriert hat, gewählt worden und das Zuweisen der IP-Adressen erfolgte (manuell) durch den Eintrag in die wg*.conf-Dateien (oder *.network/*.netdev-Dateien wenn systemd-networkd verwendet worden ist). Ein DHCP-Server wird m. E., hier für das WG-VPN-Subnetz nicht verwendet.
Eine MASQUERADE-Regel ist (in ausreichender Weise bzw. in Zusammenhang mit dem WG-VPN) nur für das eth0-Interface konfiguriert worden.
Es könnte aber auch sein, dass ein Script (analog PiVPN) zum installieren und konfigurieren das WireGuard-VPN, verwendet worden ist. Ich gehe davon aus, dass nicht Du das gemacht hast, weil Du hier fragst.
BTW: Die Frage, wer das WG-VPN installiert hat, hast Du nicht beantwortet.

[SeaSide]

Hallo,

danke für die Info.
Wir haben doch zwei Subnetze. Einmal das 10.8.0.0/24 und das 172.28.0.0/16
Diese Netze sind getrennt und werden vom Debianserver/Wireguard miteinander verbunden. Das Handy mit IP 10.8.0.3 hat eine Verbindung mit beispielsweise einem anderen Server 172.28.0.2 im Heimnetz. Für den Heimserver 172.28.0.2 ist der Client aber nur mit 172.28.0.66 erkennbar, da der Debianserver/Wireguard via MASQUERADE die IP 10.8.0.3 auf 172.28.0.66 umbaut. Das funktioniert ja auch soweit alles hervorragend. Mich interessiert nur, wie der Debianserver/Wireguard nur an die 172.28.0.66 kommt. Diese ist im Wireguard und auch auf dem Debian nirgendswo konfiguriert worden. Offensichtlich fragt Netfilter diese beim DHCP im Netz ab?

Eigentlich könnte die Frage doch von Kennern einfach beantwortet werden - im Grunde hat das ja offensichtlich nichts mit Wireguard selbst zutun. Wo holt Netfilter sich die IP bei Nutzung von MASQUERADE her, wenn der Server selbst kein DHCP ist.

[mat6937]

Diese Netze sind getrennt und werden vom Debianserver/Wireguard miteinander verbunden.

So wie die "AllowedIPs= " (bei den WG-VPN-Interfaces/Peers) z. Zt. m. E. richtigerweise konfiguriert sind, werden diese Netze nicht "miteinander verbunden".

Wo holt Netfilter sich die IP bei Nutzung von MASQUERADE her, ...

Vom output-Interface, in deinem Fall vom eth0-Interface.