ubuntuusers.de

Hallo Zusammen,

ich möchte dass sich VPN Clients sich am VPN Wireguard Server verbinden können und nach einem erfolgreichen Verbindungsaufbau soll nur die IP Adresse vom VPN Server aufrufbar sein, d.h. der Client kann im Browser nur 192.144.12.42 erreichen (Es ist ein HTTP Server installiert). Andere Verbindungen z.B. 192.144.12.x oder google.com soll das Netzwerk eth0 vom Client verwendet werden. Ich habe mal eine Übersicht gezeichnet, wie ich es meine:

[Bild Umgebung] https://media-cdn.ubuntu-de.org/forum/attachments/temp/fc28d689cf04445156d45f2964f6e07b

Es soll daher ein Split erfolgen, es soll nur tun0 verwendet werden, wenn die IP Adresse 192.144.12.42 eingegeben wird. Auf dem Server habe ich die IP-Tables Regel definiert:

1

iptables -t nat -A POSTROUTING -s 10.100.170.0/24 -d 192.144.12.42 -j MASQUERADE

Hierfür habe ich gelesen, dass die Client Konfiguration angepasst werden muss und zwar:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Interface]
PrivateKey = ???????????=
Address = 10.100.170.9/24,???:???:???:???::4/64
DNS = 9.9.9.9, 149.112.112.112

[Peer]
PublicKey = ?????????=
PresharedKey = U????????=0=
Endpoint = im.secret.domain:51820
AllowedIPs = 192.144.12.42/32

Dies funktioniert aber nicht, es werden weiterhin alle Verbindung über tun0 weitergeleitet. Eine zweite Möglichkeit ist, dass ich das Internet-Traffic weiterleite und zwar, wenn ich in /etc/sysctl.conf die sysctl net.ipv4.ip_forward=1 aktiviere. Dann ist aber der Effekt, dass zwar nun alle Adressen aufrufbar sind und auch das ganze interne Netzwerk, jedoch nicht die Adresse 192.144.12.42 Habt ihr eine Idee, wie ich es so umsetzten kann, dass nur die 192.144.12.42 aufrufbar ist und keine andere Adresse 192.144.12.x und dass alle anderen Anfragen wie z.B. google.de nicht über VPN gehen?

qeychon schrieb:

Hierfür habe ich gelesen, dass die Client Konfiguration angepasst werden muss und zwar:

[Interface]
PrivateKey = ???????????=
Address = 10.100.170.9/24,???:???:???:???::4/64
DNS = 9.9.9.9, 149.112.112.112

[Peer]
PublicKey = ?????????=
PresharedKey = U????????=0=
Endpoint = im.secret.domain:51820
AllowedIPs = 192.144.12.42/32

Dies funktioniert aber nicht, ...

Anpassen heißt nicht, abschreiben. Wie sind die Ausgaben von:

ip a
ip r
ip r g 192.144.12.42

?

@lubux, sry ich hatte bei meinem Eintrag eine wichtige Info vergessen.

Ich habe auf dem Linux Server:

1

iptables -t nat -A POSTROUTING -s 10.100.170.0/24 -d 192.144.12.42 -j MASQUERADE 

konfiguriert, denn die Idee war, dass der Anwender die IP Adresse 192.144.12.42 über VPN Verbindung aufrufen kann. Darum hatte ich die Client Konfiguration wie folgt angepasst:

Address = 10.100.170.9/24 // die Adresse erhält der Client
AllowedIPs = 192.144.12.42/32 // nur diese Adresse darf dieser aufrufen.

Daher war das bewusst (und offensichtlich falsch gedacht) so konfiguriert und es wurde nicht mit copy paste einfach hinzugefügt.

Die Eingabe ergeben folgendes Ergebnis:

ip a

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 dc:a6:32:c2:bd:54 brd ff:ff:ff:ff:ff:ff
    inet 192.144.12.42/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
       valid_lft 861824sec preferred_lft 753824sec
    inet6 2a01:41xx:xxxx:3000:b5ff:cxx3:1695:6eeb/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7062sec preferred_lft 3462sec
    inet6 fe80::5xx2:bx01:xxx:b3xx/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether dc:ax:x2:c2:xx:55 brd ff:ff:ff:ff:ff:ff
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.100.170.1/24 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fd11:5xx:bxx:c0de::1/64 scope global 
       valid_lft forever preferred_lft forever

ip r

default via 192.144.12.1 dev eth0 proto dhcp src 192.144.12.42 metric 202 
10.100.170.0/24 dev wg0 proto kernel scope link src 10.100.170.1 
192.144.12.0/24 dev eth0 proto dhcp scope link src 192.144.12.42 metric 202 

ip r g 192.144.12.42

local 192.144.12.42 dev lo src 192.144.12.42 uid 1000 
    cache <local> 

qeychon schrieb:

Ich habe auf dem Linux Server:

iptables -t nat -A POSTROUTING -s 10.100.170.0/24 -d 192.144.12.42 -j MASQUERADE 

konfiguriert, denn die Idee war, dass der Anwender die IP Adresse 192.144.12.42 über VPN Verbindung aufrufen kann.

Und das soll funktionieren, ... mit dem cryptokey-routing des Wireguard?
Wenn Du source-NAT machst, muss dann nicht ein anderes target (statt MASQUERADE) benutzt werden?

EDIT:

Warum benutzt Du 192.144.12.0/24 als WG-Subnetz? Siehe:

whois 192.144.12.1

qeychon schrieb:

[…] die IP Adresse 192.144.12.42

ist keine selbst zu verwaltende Adresse und somit nicht für die allgemeine Verwendung freigegeben.

Die darf nur von demjenigen benutzt werden, der sie offiziell registriert hat, weil sonst im Internet Störungen auftreten können. Hast Du diese Adresse registriert? Wenn nicht, dann ändere das bitte und verwende eine für private Zwecke freigegebene Adresse! (s. RFC 1918)

die Adresse habe ich nur als Beispiel verwendet (es ist eigentlich die 192.168.0.x)...das hat aber mit dem eigentlichen Thema nichts zu tun

qeychon schrieb:

die Adresse habe ich nur als Beispiel verwendet (es ist eigentlich die 192.168.0.x)...das hat aber mit dem eigentlichen Thema nichts zu tun

Das macht den Support aber nicht leichter. Für private Zwecke freigegebene Adressen wir 192.168.x.y brauchst Du auch weder zu ersetzen noch in Teilen unkenntlich zu machen. Damit kann im öffentlichen Netz niemand etwas (böses) anfangen.