VPN-Verbindung über Hosted Server

[tollertyp]

Hallo,

ich habe selbst keine eigene öffentliche IP-Adresse (Provider-NAT), aber einen Server bei IONOS gemietet mit fester IP. Ich möchte nun versuchen, dass mein Raspi (der auch u.a. als Pi-Hole fungiert) eine VPN-Verbindung zu diesem Server aufbaut, so dass ich auf ausgewählte Dienste auch vom Internet aus zugreifen kann.

Grundsätzlich gibt es ja viele Anleitungen zur Konfiguration von OpenVPN, aber so richtig "schlau" bin ich nicht immer daraus geworden.

Als Anleitung habe ich bislang diese als Basis verwendet: https://wiki.ubuntuusers.de/OpenVPN/
Stehe gerade beim Erzeugen der Zertifikate, habe aber auch seit Tagen nicht weiter gemacht, weil es nicht die höchste Prio hat.

Denkt ihr, die Anleitung ist angemessen? Und kann ich die Zertifikate auch alle einfach in einer lokalen Umgebung (z.B. WSL) erzeugen und dann auf die Geräte kopieren, soltle ja auch gehen, nehme ich an?
Oder ist die Anleitung eh viel zu umständlich und es geht einfacher?

Also grundsätzlich bin ich kein Idiot und auch des Googlens mächtig, aber außer im Studium habe ich noch nie unter Linux eine VPN-Verbindung (Server+Client) konfiguriert.

 

[_anonymous0815_]

Nutze lieber die Anleitungen aus dem arch-Wiki, die sind aktueller:

https://wiki.archlinux.org/title/OpenVPN
https://wiki.archlinux.org/title/Easy-RSA

 

[tollertyp]

Aber die Easy-RSA-Sachen kann ich in der WSL machen, oder?

Hatte den Ubuntu-Artikel, weil ich bei IONOS halt ein Ubuntu-Image eingespielt hatte.

 

[_anonymous0815_]

Anbei mal (m)eine funktionierende Server-/Client-Config

Spoiler: Beispiel-Server-Config

port 1194

mode server

proto udp4

dev tun

user nobody
group nogroup

server 172.16.0.0 255.255.255.0
topology subnet

push "dhcp-option DNS 192.168.178.10"
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway def1"

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/debian-vpn.crt
key /etc/openvpn/server/debian-vpn.key  # This file should be kept secret

dh /etc/openvpn/server/dh.pem

remote-cert-tls client
verify-client-cert require
tls-version-min 1.3
auth SHA256
tls-crypt /etc/openvpn/server/ta.key
tls-ciphersuites TLS_AES_128_GCM_SHA256
cipher AES-128-GCM
tls-server

client-to-client

keepalive 10 20
persist-key
persist-tun

log /etc/openvpn/openvpn.log
verb 3

Spoiler: Beispiel-Client-Config

remote ionosip:1194

client

dev tun
proto udp4

pull
pull-filter ignore redirect-gateway #ich weiß, dass diese Zeile die Gateway-Option vom Server deaktiviert, das soll bei diesem Client so sein ^^


auth SHA256
tls-version-min 1.3

cipher AES-128-GCM
tls-client

remote-cert-tls server

ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/Ionos-Node1.crt
key /etc/openvpn/client/Ionos-Node1.key
dh /etc/openvpn/client/dh.pem

tls-crypt /etc/openvpn/client/ta.key

resolv-retry infinite

Ergänzung (29. Juni 2022)

Aber die Easy-RSA-Sachen kann ich in der WSL machen, oder?

Sollte gehen, brauchst sowieso eine VM oder einen Container der als Certificate Authority gilt und die Certs signiert.

 

[Nilson]

Zugriff über IPv6 keine Option? Dann sparst du dir den ganzen Umweg über VPN bzw. einen 4o6-Tunnel.
Sonst, schau dir mal PiVPN an. Eigentlich dafür gedacht OpenVPN bzw. Wireguard auf einem Raspberry einzurichten sollte es laut Doku auch mit Debian und dessen Abwandlungen klar kommen: https://www.pivpn.io

 

[tollertyp]

Nein, kein IPv6. :-/

 

[snaxilian]

Anstatt openVPN würde ich Wireguard bevorzugen, damit wirst du deutlich mehr Bandbreite nutzen können. Allerdings musst dich afaik selbst um das Thema Routing/Forwarding kümmern müssen. Wireguard ist rein VPN, Zusatzfunktionen die openVPN mit bringt, fehlen bzw. sind selbst umzusetzen.

Ja, easy-rsa kannst in der WSL machen oder aufm Raspi, ist egal. Musst halt nur dran denken, dass du die irgendwann austauschen musst.

 

[tollertyp]

So, kurzes Update: Ich hab eine VPN-Verbindung zwischen meinem Raspi und dem Server herstellen können und es auch schon via systemctl so eingerichtet, dass OpenVPN automatisch auf Client und Server startet.

Ob die Netzwerkkonfiguration passt und wie ich über die Verbindung kommunizieren kann, das muss ich noch testen :-)

Das mit dem automatisch verbinden auf dem Client muss ich glaub wieder deaktivieren, weil der Raspi ja auch mein DNS-Server ist, und irgendwie ist er gerade dann regelmäßig nicht mehr unter seiner IP erreichbar.

 

[tollertyp]

Update:

Also grundsätzlich bin ich kein Idiot und auch des Googlens mächtig

Das nehme ich denke ich zurück.

Jedenfalls habe ich nun eine Verbindung zwischen Ionos-Server und Raspi-Client, ohne dass der Raspi sich aus dem LAN "verabschiedet".

Meine Konfiguration sieht gerade so aus:

Spoiler: Server (IONOS)

port 1194

mode server

proto udp4

dev tun

user nobody
group nogroup

server 172.16.0.0 255.255.255.0
topology subnet

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/servername.crt
key /etc/openvpn/server/servername.key # This file should be kept secret
dh none
ecdh-curve secp521r1

remote-cert-tls client
verify-client-cert require
tls-version-min 1.3
auth SHA512
tls-crypt /etc/openvpn/server/ta.key
tls-ciphersuites TLS_AES_128_GCM_SHA256
cipher AES-128-GCM
tls-server

client-to-client

keepalive 10 20
persist-key
persist-tun

log /etc/openvpn/openvpn.log
verb 3

Spoiler: Raspi (Client)

remote 212.227.xxx.xxx

client

dev tun
proto udp4

pull

auth SHA512
tls-version-min 1.3

cipher AES-128-GCM
tls-client

remote-cert-tls server

ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client1.crt
key /etc/openvpn/client/client1.key

tls-crypt /etc/openvpn/client/ta.key

resolv-retry infinite

Also Server und Client können sich mit 172.16.0.x gegenseitig anpingen. Die gepushten Routen habe ich entfernt, weil ich sonst den Raspi nicht mehr im LAN erreichen konnte. Irgendwie scheitere ich auch daran, via ccd die Route vom Server ins Raspi-LAN (192.168.0.0) einzurichten. Dazu hatte ich in der server.conf probiert:

client-config-dir /etc/openvpn/ccd
route 192.168.0.0 255.255.255.0

Und in /etc/openvpn/ccd liegt eine Datei mit:

iroute 192.168.0.0 255.255.255.0

Beim Namen der Datei bin ich unschlüssig, wie sie heißen muss. Entsprechend der Zertifkatsdatei (client1) oder wie der Name des Clients ist (wie in den logs). Beides probiert, hat m.E. nicht funktioniert.

Was ich noch nicht hinbekomme ist es, dass ich nun von Außen über die Server-IP und einem passenden Port auf Dienste im LAN zugreifen kann. Ich bin jetzt auch nicht sicher, ob dafür der Tunnel-Modus das beste ist, es hört sich für mich so an, als wäre der Bridge-Modus da wohl besser geeignet aber in der Konfiguration etwas aufwändiger.

Was würde ich gerne anbieten:

• Vaultwarden (auf dem Raspi)
• Extrem nice to have: Zugriff auf emby Webinterface (auf einem anderen Rechner im LAN)

Die Frage ist, ob eine Port-Weiterleitung von IONOS-Server auf Raspi für Vaultwarden ausreicht? Bin da auch nicht ganz sicher in der iptables-Konfiguration. Meine Devices auf dem IONOS-Server heißen:

• ens192 (der Controoller, der mit der öffentlichen IP)
• tun0

Server tun0 hat 172.16.0.1, Raspi tun0 hat 172.16.0.2.

Um ein Zertifikat von Let's Encrypt würde sich Vaultwarden (bzw. Traefik oder wie das heißt), dazu müsste halt auch noch eine passende Weiterleitung eingerichtet werden.

 

[_anonymous0815_]

ob dafür der Tunnel-Modus das beste ist, es hört sich für mich so an, als wäre der Bridge-Modus da wohl besser geeignet

TUN arbeitet auf Layer 3, IP, TAP auf Layer 2 Ethernet, wenn Du kein anderes Protokoll als TCP/IP fahren möchtest, ist das also völlig unnötig. Die wenigsten Clients unterstützen außerdem TAP.

Ergänzung (30. Juni 2022)

Damit Geräte aus dem Heimnetz jetzt auch den IONOS-Server über das VPN-Subnetz erreichen können, bedarf es einer Einstellung in Deinem Router zu Hause. In meinem Fall ist das eine Fritz!Box 7590 und die Route sieht so aus:

Das Gateway stellt einfach deinen Raspi dar.
Des Weiteren muss Routing bei Deinem Raspi aktiviert sein, das macht man so:

echo 1 > /proc/sys/net/ipv4/ip_forward

Ergänzung (30. Juni 2022)

Beim Namen der Datei bin ich unschlüssig, wie sie heißen muss. Entsprechend der Zertifkatsdatei (client1)

Sollte der Name des Zertifikates sein, ist aber ein Weilchen her, dass ich das mal getestet habe.
EDIT: Laut dieser Webseite https://serverfault.com/questions/919989/openvpn-ccd-file-extensions sind es wirklich die Zertifikatnamen. Schau mal bei Deiner Certificate Authority unter diesem Verzeichnis nach, so wie sie dort stehen, müssen sie heißen (ohne .crt):

Ergänzung (30. Juni 2022)

Und mir fiele zu Deinem eigentlichen Anliegen erst mal folgendes ein:
Wenn die VPN-Verbindung bidirektional steht, Du also von Deinen Heimgeräten die 172.16.0.1 erreichen kannst und von der 172.16.0.1 die IPs in Deinem Heimnetz, wäre es denkbar, dass Du bei Deinem Ionos-Server Ports öffnest und die per iptables an Deinen Pi (Heimnetz-IP) weiterleitest. Das sollte von der Theorie her möglich sein, aber bei der Umsetzung kann ich Dir nicht helfen, da ich dies selbst noch nie probiert habe.

 

[_anonymous0815_]

Deine Updates würden mich brennend interessieren und obs am Ende wirklich läuft, falls die Telekom auch mal auf CG-NAT umstellt.

 

[tollertyp]

Okay danke, also beim Raspi stand wohl die 1 schon drin beim Forwarding, an das Gateway im Router hatte ich gar nicht gedacht. Hab es da mal eingestellt.

Sobald ich aber

push "route 192.168.0.0 255.255.255.0"

in der Server-Config habe, ist der Raspi nicht mehr im LAN zu erreichen.

Ich werde Updates geben :-)

Und gerade bei der IPTABLES-Geschichte hab ich halt auch noch nicht so richtig Plan :-)

 

[_anonymous0815_]

push "route 192.168.0.0 255.255.255.0"

Oh, ähm, wenn der Ionos-Server der OpenVPN-Server ist, ist diese Zeile nicht nötig.

Ergänzung (30. Juni 2022)

Ich bin beim schreiben davon ausgegangen, dass der Raspi den Server stellt und die Ionos-Kiste der Client ist.

 

[tollertyp]

Okay, dachte ich mir dann auch irgendwie.
Ja, der Ionos-Server ist der VPN-Server, weil ich ja von dem gar nicht in mein LAN komme.

 

[_anonymous0815_]

Oh Mann, ja klar XD. Macht Sinn.

Ergänzung (30. Juni 2022)

Nächster Schritt sollte wie gesagt sein, von einer 192.168.0.0er IP den 172.16.0.1 Server anzupingen. Daraufhin solltest Du auf dem IONOS-Server eine permanente Route einrichten, welche besagt: "route 192.168.0.0/24 via 172.16.0.2 dev tun0".

 

[tollertyp]

Also wenn ich auf dem server "ip route" eingebe, erscheint die Route:

Den Raspi kann ich mit seiner IP auch anpingen:

Den Rest des LANs noch nicht, ergo ist das Problem auf dem Raspi dann.

Das Forwarding ist da zumindest mal drin:

Von meinem lokalen PC kann ich den Raspi unter seiner OpenVPN-IP auch anpingen:

Hier noch die Routen vom Raspi:

 

[snaxilian]

Gerade nur am Handy daher ohne Lösung: check bitte ob am Raspi iptables aktiv ist, vermutlich fehlen da die passenden Regeln. Nur weil der Raspi technisch jetzt Pakete routen kann, muss es die Firewall auch erlauben 😉
Zur Verifizierung einfach Mal tcpdump aufm Raspi 2x starten. Einmal auf eth0 und limitiert auf Ping und einmal auf tun0 mit gleichem Filter. Dann siehst den Ping ankommen, ggf raus gehen Richtung ionos und ggf auch zurück kommend.

 

[_anonymous0815_]

Also wenn ich auf dem server "ip route" eingebe, erscheint die Route:
[IMG]https://www.computerbase.de/forum/attachments/1656624737856-png.1234131/[/IMG]

Das sieht doch schon mal gut aus. Du kannst ja mal teshalber eine traceroute absetzen zu einer IP aus Deinem Heimnetz, die nicht der Raspi ist.

Das sollte ähnlich zu dem hier aussehen (ähnlich, nicht gleich, weil bei mir der Ionos-VPS der Client ist):

root@Ionos-Node1:~# traceroute 192.168.178.5
traceroute to 192.168.178.5 (192.168.178.5), 30 hops max, 60 byte packets
 1  172.16.0.1 (172.16.0.1)  29.764 ms  30.675 ms  30.679 ms
 2  192.168.178.5 (192.168.178.5)  30.676 ms  30.669 ms  30.664 ms

Den Rest des LANs noch nicht, ergo ist das Problem auf dem Raspi dann.

Könnte sein, Routing ist ja gesetzt, daher könnte es auch die statische Route im Router sein, könntest Du die mal posten?
Jedes IP-Paket bekommt ja eine Source und eine Destination-Adress in seinem Paket mit auf dem Weg. Vielleicht stellt der Raspi das Paket vom Server schon an die IP im Heimnetz durch, aber das Gerät im Heimnetz scheitert bei der Rücksendung, da es die 172.16.0.1 nicht aus dem eigenen Subnetz kennt, wird es sich an das Standardgateway wenden und wenn die Route dort nicht korrekt gesetzt ist, bleibt das Paket hängen.

check bitte ob am Raspi iptables aktiv ist

Das könnte natürlich auch ein Problem darstellen, Du kannst die auch getrost komplett "deaktivieren", das Ding ist ja trotzdem hinter einer Router-Firewall, Du musst dann nur drauf achten, dass Du vom Ionos-Server nicht alle Ports zum Raspi weiterleitest, sondern wirklich nur die einzelnen TCP/UDP-Ports für den jeweiligen Service.
Anstellen tut man das dann so:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

(Die bitte wirklich nur auf dem Raspi nutzen, nicht auf dem Ionos-Server, sonst sollten alle Ports ins Internet offen sein (Exposed Host))

 

[_anonymous0815_]

Wie ist denn bei Dir der aktuelle Stand oder hast Du das Vorhaben aufgegeben?