ubuntuusers.de

Hallo,

ich habe ein Portforwarding (192.168.2.10:8123) auf meinem VPN Client (10.0.0.3) eingerichtet. Dieses bezweckt, dass der VPN Server (10.0.0.1) unter der Adresse 10.0.0.3:8123 den Dienst erreicht. Das funktioniert auch. Nun möchte ich, dass der Dienst bzw. Port ebenfalls unter der IP des VPN Servers erreichbar ist. Wie stelle ich das an? Ursprünglich dachte ich, es würde ausreichen, die unten angegeben iptables nur anzupassen. Leider ist dem nicht so.

Meine Client iptables sehen folgendermaßen aus:

1
2

iptables -A PREROUTING -t nat -i wg0 -p tcp --dport 8123 -j DNAT --to 192.168.2.10:8123
iptables -A FORWARD -p tcp -d 192.168.2.10 --dport 8123 -j ACCEPT

VG Pino

Pino schrieb:

Wie stelle ich das an?

Du benutzt WireGuard. Das kannst Du mit dem cryptorouting des WireGuard machen.

Hallo lubux,

danke für deine Antwort. Über Allowed IPs kann ich sicher etwas stricken. Nur müsste ich mindestens auf 192.168.2.10 entweder das Gateway ändern und dort mit iptables "spielen". Gleiches gilt für die Serverseite. Dies schafft nach meiner Meinung mehr Komplexität als nötig. Ich kann mich daran erinnern etwas ähnliches, wie von mir angedacht, schon einmal gebaut zu haben. Ich glaube es war eine Kombination aus DNAT und SNAT. Allerdings bekomme es leider nicht mehr zusammen.

VG Pino

Pino schrieb:

Nun möchte ich, dass der Dienst bzw. Port ebenfalls unter der IP des VPN Servers erreichbar ist.

Wie hast Du den Dienst konfiguriert? Auf welcher IP-Adresse lauscht der Dienst?

Wie ist die Ausgabe von:

sudo netstat -tulpena

?

Hallo lubux,

der Dienst lauscht auf 0.0.0.0:8123 und sollte so über mindestens alle internen Adressen aus dem gleichen Subnetz erreichbar sein.

Ich habe versucht den Aufbau vereinfacht darzustellen (siehe Anhang). Ich hoffe er hilft mehr als das er verwirrt. Aus dem Container des VPN-Servers heraus funktioniert die Kommunikation zu 10.0.0.3:8123. Daher habe ich versucht die im Eingangspost erwähnten iptables nur etwas umzustricken (s.u.) und auf dem VPN-Server zu nutzen, so dass auf 10.0.0.1:8123 bzw. 172.18.0.5:8123 der Webserver erreichbar ist. Also ein zweiten herkömmliches Forwarding. Nur leider ohne Erfolg. Nmap sagt, dass der Port 8123 auf 10.0.0.1 geschlossen sei.

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 8123 -j DNAT --to 10.0.0.3:8123
iptables -A FORWARD -p tcp -d 10.0.0.3 --dport 8123 -j ACCEPT

VG Pino

Pino schrieb:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 8123 -j DNAT --to 10.0.0.3:8123
iptables -A FORWARD -p tcp -d 10.0.0.3 --dport 8123 -j ACCEPT

Du kannst ein destination-NAT im VPN des WireGuard (vom WG-Server zum lauschenden WG-Client) machen. Z. B. auf dem WG-Server:

sysctl -w net.ipv4.ip_forward=1
iptables -I PREROUTING 1 -t nat -i wg0 -p tcp --dport 8123 -j DNAT --to-destination 10.0.0.3

Aber für aus dem eth0:Network ins wg0:Network (VPN), musst Du den WireGuard entsprechend konfigurieren.

Hallo lubux,

leider bin ich bisher keinen Millimeter weitergekommen. Mitterweile bin ich tatsächlich etwas frustriert ☹ Ich habe soweit alles an Ausgaben zusammengesammelt, die eventuell relavant sein könnten. Fällt dir noch etwas ein?

Aktueller Stand: 10.0.0.3:8123 ist vom Server erreichbar. 10.0.0.1:8123 ist vom Server nicht errichbar. 192.168.2.10:8123 ist vom client erreichbar.

net.ipv4.ip_forward ist auf beiden Containern gesetzt.

VPN Client

iptables -A PREROUTING -t nat -i wg0 -p tcp --dport 8123 -j DNAT --to 192.168.2.10:8123
iptables -A FORWARD -p tcp -d 192.168.2.10 --dport 8123 -j ACCEPT

ip addr

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
2: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.3/24 scope global wg0
       valid_lft forever preferred_lft forever
28: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.7/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

iptables -L -n -t nat

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8123 to:192.168.2.10:8123

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

VPN Server

iptables -I PREROUTING 1 -t nat -i wg0 -p tcp --dport 8123 -j DNAT --to-destination 10.0.0.3

ip addr

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
2: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever
254: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

iptables -L -n -t nat

target     prot opt source               destination
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8123 to:10.0.0.3

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

wget 10.0.0.1:8123 -O /dev/null

--2020-03-19 18:49:48--  http://10.0.0.1:8123/
Connecting to 10.0.0.1:8123... failed: Connection refused.

wget 10.0.0.3:8123 -O /dev/null

--2020-03-19 18:50:45--  http://10.0.0.3:8123/
Connecting to 10.0.0.3:8123... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3175 (3.1K) [text/html]
Saving to: '/dev/null'

/dev/null             100%[=========================>]   3.10K  --.-KB/s    in 0s

2020-03-19 18:50:45 (159 MB/s) - '/dev/null' saved [3175/3175]

VG Pino

Pino schrieb:

leider bin ich bisher keinen Millimeter weitergekommen. Mitterweile bin ich tatsächlich etwas frustriert ☹ Ich habe soweit alles an Ausgaben zusammengesammelt, die eventuell relavant sein könnten. Fällt dir noch etwas ein?

Hast Du schon mit:

AllowedIPs = 0.0.0.0/0

in den wg0.conf-Dateien versucht?

Denn lt. der manpage:

 AllowedIPs — a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traf‐
              fic  for  this  peer  is  allowed and to which outgoing traffic for this peer is directed. The catch-all
              0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0 may be specified for  matching  all
              IPv6 addresses. May be specified multiple times.

EDIT:

Siehe auch: https://www.wireguard.com/#cryptokey-routing

Nein, da der Client Container read-only ist und wireguard bei 0.0.0.0/0 den Schlüssel net.ipv4.conf.all.src_valid_mark schreiben möchte, der Container allerdings read-only ist. Stattdessen habe ich

AllowedIPs = 10.0.0.0/24, 192.168.2.0/24, 172.17.0.0/24

genutzt. Damit sind fürs Erste alle möglichen IPs abgedeckt.

VG Pino

Pino schrieb:

... alle möglichen IPs abgedeckt.

BTW: Das haben andere auch schon gedacht. Ich erlaube erstmal alles und wenn das funktioniert, schränke ich ein. Aber bei dir geht das ja nicht, wegen read-only.

EDIT:

Ich denke, das hat nichts mit read-only zu tun. Im Container werden evtl. auf Grund eines "security levels" bestimmte Konfigurationen nicht möglich sein. Denn das setzen von "net.ipv4.conf.all.src_valid_mark" ist ja nicht persistent. Und dieses setzen ist ja nicht die einzige (nicht persistente) Konfiguration im Container. Es wird z. B. ja auch wireguard-Interface generiert, ein nicht persistentes Routing, ein file descriptor, die MTU, ein fwmark für den listen Port, dort im Container konfiguriert bzw. erlaubt.