Lokales Netz über wireguard VPN an VServer - Routing

[darkiop]

Hallo zusammem,
ich bin gerade dabei mein lokales Netz an einen Vserver anzubinden.
Später soll dort mal eine weitere Proxmox VE / Proxmox Backup Server auf einem Mietserver laufen der nur über die VPN-Verbindung / dessen lokales Netz erreichbar sein soll. Das alles hier sind also nur Trockenübungen

Die VPN Verbindung läuft über Wireguard auf einem lokalen LXC zum Vserver - und die auch stabil.

Allerdings ist der Vserver aus dem lokalen Netz nur direkt übers Gateway (UDMP), den Wireguard-LXC oder über andere Clients aus dem Netz 10.4.1.0/24 erreichbar (= über die 172.31.0.2 & 192.168.2.2).

Ich hätte gerne Zugriff auf den Vserver und seine lokale IP (192.168.2.2) aus anderen Netzen, z.B. 10.1.0.0/24 (meine privaten Clients, siehe Tracert am Ende des Posts).

Steh grad etwas aufm Schlauch, hat jemand eine Idee was mir in meinem Setup noch fehlt und ich vergessen habe? Laut dem tracert verliert sich die Route auf 10.4.1.15.

Hier nun noch einige Infos zum Setup, falls noch etwas fehlt einfach melden. Im Anhang ist auch noch eine grafische Aufbereitung des Netzes.

Spoiler: IP-Übersicht

Gateway (UDMP)
192.168.1.1 (10.1.0.1, ..., 10.4.1.1)

Lokal
Lokale IP (LXC) 10.4.1.15
VPN 172.31.0.1

VServer
Lokale IP 192.168.2.2
VPN IP 172.31.0.2

Spoiler: Routen auf UDMP

192.168.2.0/24 > 10.4.1.15
172.31.0.0/24 > 10.4.1.15

Spoiler: route -n auf LXC

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.4.1.1 0.0.0.0 UG 0 0 0 eth0
10.4.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
172.31.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 wg0

Spoiler: wg0.conf LXC

[Interface]
PrivateKey = x
Address = 172.31.0.1/24

[Peer]
PublicKey = x
PresharedKey = x
Endpoint = ip-vserver:51820
AllowedIPs = 172.31.0.2/32, 192.168.2.2/32
PersistentKeepalive = 25

Spoiler: wg0.conf vserver

[Interface]
PrivateKey = x
Address = 172.31.0.2/24
ListenPort = 51820

[Peer]
PublicKey = x
PresharedKey = x
AllowedIPs = 172.31.0.1/32, 10.4.1.0/24

Spoiler: tracert Windows Client 10.1.0.2

C:\>tracert 192.168.2.2

Routenverfolgung zu 192.168.2.2 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 10.1.0.1
2 <1 ms <1 ms <1 ms 10.4.1.15
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.

 

[ksk23]

wow, krasse Planung!
sorry bin grad zu Faul mir das alles reinzuziehen, aber:
Du musst auf dem Vserver eine Verbindung zwischen den Network-Interfaces "wireguard" und "das wo die 192.168..."-drauf-ist herstellen.

Du möchtest also im Layer3, IP-Sprech traffic routen, schau mal zb hier:
https://wiki.debian.org/SimplePrivateTunnelVPNWithWireGuard#Routing_configuration
Das beschreibt, wie du quasi deinen Vserver als das was alle als "VPN" bezeichen nutzen würdest (== traffic deiner clients kann über den vserver laufen) - du willst aber quasi das gleiche in Grün, nicht an die externe IP des vservers NAT "translaten", sondern an eine interne.

Wo ich das geschrieben habe fällt mir ein: dass ist ggf nicht sinnvoll, und du solltest wenn du da keinen besonderen grund hast services auf dem Vserver eher über die "wireguard ip" anbieten; Man verkonfiguriert sich leicht, oder vergisst was, und schwupps haben alle leute die an dem VPN hängen zugriff auf etwas, von dem du vielleicht dachtest, es sei nur "Lokal" auf dem Sörver erreichbar, bla..

Denke generell ist der ganze Artikel empfehlenswert, das wiki leidet nur generell manchmal an etwas veralteten Inhalten.

 

[darkiop]

Wo ich das geschrieben habe fällt mir ein: dass ist ggf nicht sinnvoll, und du solltest wenn du da keinen besonderen grund hast services auf dem Vserver eher über die "wireguard ip" anbieten; Man verkonfiguriert sich leicht, oder vergisst was, und schwupps haben alle leute die an dem VPN hängen zugriff auf etwas, von dem du vielleicht dachtest, es sei nur "Lokal" auf dem Sörver erreichbar, bla..

Genau das habe ich Der soll dann auch nur per VPN erreichbar sein. Also auf seiner öffentlichen IP liegt dann nur der Wireguard Port an. Selbst SSH läuft dann da drüber bzw. über die VPN-IP.

Den Artikel schau ich mir Morgen mal an. Verstehe bisher noch nicht, wieso aus aus Teilen meines lokalen Netzes der Zugriff klappt und aus anderen wiederum nicht.

wow, krasse Planung!

Danke, das Entstand so nach und nach. Und die Tage hab ich das alles einfach mal aufgemalt. Lokal läuft hier auch alles soweit ganz gut. Ziel für die Zukunft ist dann noch die Anbindung der Netze aus der Familie - für Support und Backups

 

[snaxilian]

Also auf seiner öffentlichen IP liegt dann nur der Wireguard Port an. Selbst SSH läuft dann da drüber bzw. über die VPN-IP.

Dann hast hoffentlich eine Rettungskonsole beim Hoster für den Fall, dass der Wireguard-Service oder das OS ein Problem hat, sonst kommst nicht mehr an die Kiste ran^^

Beim tracert sieht man nur, dass am LXC für Wireguard Schluss ist. Kommen denn Pakete wirklich dort an? Im Zweifel tcpdump auf allen beteiligten Interfaces starten und gucken ob und was ankommt. Dann siehst du zumindest schon einmal ob Pakete zwischen zwei Systemen verloren gehen oder bei einem System zwar ankommen aber dort nicht weiter verarbeitet werden (können).
Das kann dann eine Firewallregel/-policy sein oder nicht aktiviertes Routing im LXC von Wireguard.
Hier hatte jemand mit Proxmox 5.x ein ähnliches Problem: https://forum.proxmox.com/threads/ip-forwarding-inside-an-lxc-on-5-0-not-working.35725/

Meine Vermutungen wäre neben der Firewall als Alternative irgendwo fehlende Routinginformationen, sodass z.B. Pakete zwar den Hinweg finden aber nicht zurück oder sowas in der Art.
Vielleicht hätte @Raijin hier noch eine Idee und wenn nicht freut er sich auf jeden Fall über die hervorragende dokumentarische Qualität von @darkiop, Chapeau auch von mir. Machte auf jeden Fall Freude so eine gute Problembeschreibung zu lesen. 😍

 

[darkiop]

Guten Morgen,

Dann hast hoffentlich eine Rettungskonsole beim Hoster für den Fall, dass der Wireguard-Service oder das OS ein Problem hat, sonst kommst nicht mehr an die Kiste ran^^

ja die ist vorhanden. Zumindest jetzt hier beim Test in der Hetzner-Cloud. Vermutlich aber auch später bei der Blechkiste

Hier hatte jemand mit Proxmox 5.x ein ähnliches Problem: https://forum.proxmox.com/threads/ip-forwarding-inside-an-lxc-on-5-0-not-working.35725/

Die Ursache beim LXC selbst, habe ich gerade ausgeschlossen: Mit privileged/unprivileged und auch in einer Ubuntu-VM mit WG, kommt es zur selben Situation.

Also weiter suchen beim Routing.

Meine Vermutungen wäre neben der Firewall als Alternative irgendwo fehlende Routinginformationen, sodass z.B. Pakete zwar den Hinweg finden aber nicht zurück oder sowas in der Art.

Was ich mir nicht erklären kann, das (WG im LXC):

10.4.1.15 > 172.31.0.1 > 172.31.0.2 > 192.168.2.2
192.168.1.1 > 10.4.1.15 > 172.31.0.1 > 172.31.0.2 > 192.168.2.2
10.4.1.x > 192.168.1.1 > 10.4.1.15 > 172.31.0.1 > 172.31.0.2 > 192.168.2.2

funktioniert, und

192.168.1.50 > 10.4.1.15 > 172.31.0.1 > 172.31.0.2 > 192.168.2.2
10.1.0.x > 192.168.1.1 > 10.4.1.15 > 172.31.0.1 > 172.31.0.2 > 192.168.2.2

nicht.

tcpdump krame ich später mal raus und schau ob ich auf 10.4.1.15 etwas sehe.

Vielleicht hätte @Raijin hier noch eine Idee und wenn nicht freut er sich auf jeden Fall über die hervorragende dokumentarische Qualität von @darkiop, Chapeau auch von mir. Machte auf jeden Fall Freude so eine gute Problembeschreibung zu lesen. 😍

Danke Erstens, so ein Problem lässt sich schwer ohne Transparenz beschreiben und lösen und Zweitens, ich würde hier auch nicht mehr durchblicken wenn ich nicht dokumentieren würde


Edit, noch eine Erkenntnis:

10.1.0.2 > 10.4.1.15 > 172.31.0.1
192.168.1.50 > 10.4.1.15 > 172.31.0.1

geht, und

10.1.0.2 > 10.4.1.15 > 172.31.0.1 > 172.31.0.2
192.168.1.50 > 10.4.1.15 > 172.31.0.1 > 172.31.0.2

nicht.

Edit-2 tcpdump:

Hier kam der Ping request von 10.1.0.2 an 172.31.0.2 und blieb ohne Antwort:

Und hier mit dem Ping von 192.168.1.1 (was auch gleichzeitig 10.4.1.1 ist, also meine UDMP):

 

[Bob.Dig]

Kann WG überhaupt routen? Mit OVPN soll das wohl "einfacher" gehen.

 

[darkiop]

Zum Teil funktioniert das Routing ja. Hab in meinem letzten Post nochmal einiges ergänzt.

 

[snaxilian]

@Bob.Dig Die Anwendung muss auch nicht routen können, weder Wireguard noch openVPN. Ob ein Linux Pakete weiter leitet oder nicht, sprich Pakete von anderen Hosts annimmt und weiter gibt, hängt davon ab ob IP-Forwarding aktiviert ist oder eben nicht.

Hier kam der Ping request von 10.1.0.2 an 172.31.0.2 und blieb ohne Antwort:

Dieser Text und die zwei Screenshots darunter widersprechen sich aber.
Sowohl Quelle mit 10.1.0.2 zeigt vier gesendete und vier Antworten und auch Ziel mit 172.31.0.2 zeigt im tcpdump eingehende ICMP Requests als auch die dazu passende Reply.
Auch im zweiten tcpdump sieht man eindeutig, dass Request ankommt und Reply raus geht.

 

[darkiop]

Guten Morgen,

@Bob.Dig Dieser Text und die zwei Screenshots darunter widersprechen sich aber.
Sowohl Quelle mit 10.1.0.2 zeigt vier gesendete und vier Antworten und auch Ziel mit 172.31.0.2 zeigt im tcpdump eingehende ICMP Requests als auch die dazu passende Reply.

Im ersten Screen fehlt das reply zum Ping an 172.31.0.2 (Remote) - das für 172.31.0.1 (Lokal) ist da.

@Bob.Dig
Auch im zweiten tcpdump sieht man eindeutig, dass Request ankommt und Reply raus geht.

Das passt auch, denn der zweite Screen zeigt die PIngs die von der UMDP gestartet wurden - und von da aus funktioniert das ja auch.

Ergänzung (16. Oktober 2021)

Und nochmal ein Guten Morgen,
ich glaube ich habe es, Teste es dieses WE aber noch detaillierter.

hängt davon ab ob IP-Forwarding aktiviert ist oder eben nicht.

Das brang mich dazu das natting in der wg0.conf für das wg0 im LXC zu aktivieren:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE

Nun gehen meine Pings durch. Hatte eigentlich gedacht das brauche ich nicht, wenn ich statische Routen auf den Routern habe.