[gelöst] Port Forwarding in OpenVPN-Tunnel

[scriptorius]

Die Frage, die dahinter steckt, ist: Was ist das Ziel?

Du hast im Verlauf hier von 6tunnel gesprochen.
Dieses Programm hat seinen Zweck temporär gut erfüllt - das habe ich getestet.
Mein Ziel, das ich erreichen möchte, ist, die Funktion dieses Programms stabil und möglichst sicher hinzubekommen.
Ich hoffe, dass ich dies über OpenVPN hinbekommen kann oder liegt darin ein Denkfehler?

[andydld]

6tunnel funktioniert, je nach Ziel meiner Erfahrung nach gut.
Funktioniert halt nur mit TCP-Verbindungen.

https://www.andysblog.de/zugriff-auf-se ... schluessen

Bei OpenVPN auf dem vServer bin ich nach gar keiner Anleitung vorgegangen, da ich ein wenig Erfahrung damit habe und wenn es doch mal hakt die Log-Meldungen recht eindeutig sind und diese im Idealfall auch gleich quasi die Lösung anbieten.

Um das Ganze mal kurz abhandeln zu können anbei ein paar Schritte basierend auf Debian 10 Buster, wie es auf meinem Test-vServer eingerichtet wurde:

Routing aktivieren:

Code: Alles auswählen

nano /etc/sysctl.conf
net.ipv4.ip_forward=1

Anschl. einmal:

Code: Alles auswählen

sysctl -p

OpenVPN-Server:

Code: Alles auswählen

apt install openvpn
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server
gzip -d /etc/openvpn/server/server.conf.gz
mv /etc/openvpn/server/server.conf /etc/openvpn/

shared key erstellen:

Code: Alles auswählen

cd /etc/openvpn
openvpn --genkey --secret static.key

Konfiguration anpassen:

Code: Alles auswählen

nano server.conf

wie folgt ändern:

Code: Alles auswählen

# ca ca.crt
# cert server.crt
# key server.key # This file should be kept secret

secret /etc/openvpn/static.key

# server 10.8.0.0 255.255.255.0

# ifconfig-pool-persist /var/log/openvpn/ipp.txt

ifconfig 10.8.0.1 10.8.0.2

# dh dh2048.pem

# tls-auth ta.key 0 # This file is secret

log         /var/log/openvpn/openvpn.log

auth SHA256
comp-noadapt

route 192.168.1.0 255.255.255.0

Daemon aktivieren und starten:

Code: Alles auswählen

systemctl enable openvpn@server
systemctl start openvpn@server

Soweit, so gut, dann kommt der Firewall-Part, iptables, nftables, etc. da bin ich noch dran.

Auf der Client-Seite läuft im Moment eine pfSense.

Besser ist's mit Zertifikaten, aber halt auch etwas aufwendiger. Für (m)einen Test sollte shared key reichen.

[TomL]

Die Notwendigkeit eines Relay-Servers sehe ich momentan noch nicht.

Nur adhoc-Verbindungen... i.ü.S. sowas wie Wählverbindungen...?... oder ein permanenter Tunnel zwischen Heimnetz und VServer?

[scriptorius]

Hi,
vielen Dank, damit komme ich wieder weiter.
Teste es bis zum Wochenende.

[scriptorius]

Die Notwendigkeit eines Relay-Servers sehe ich momentan noch nicht.

Nur adhoc-Verbindungen... i.ü.S. sowas wie Wählverbindungen...?... oder ein permanenter Tunnel zwischen Heimnetz und VServer?

... doch sollte schon ein permanenter Tunnel sein.
Was muss geändert werden?

[scriptorius]

Ich habe noch mal in dem Buch nachgelesen, wie der die Firewall konfiguriert hat.
Der nutzt ufw.
Er konfiguriert:
/etc/ufw/before.rules
# OPENVPN MASKIERUNG
ANFANG
# NAT Regel definieren
*nat
:POSTROUTING ACCEPT [0:0]
# Erlaubt den Datenverkehr vom OpenVPN-Client zum Interface.
# (Ändern Sie hier das Interface in Ihr Interface)
-A POSTROUTING -s 10.8.0.0/8 -o enp0s3 -j MASQUERADE COMMIT
# OPENVPN MASKIERUNG ENDE

In:
/etc/default/ufw
setzt der:
DEFAULT_FORWARD_POLICY=“ACCEPT“

Vielleicht hilft das weiter? Da bin ich aber noch nicht ...

[TomL]

Eigentlich klingt die Anforderung für mich ein wenig nach Bridging und tap-Device. Aber dann solls anscheinend durch Routing mit dem Tun-Device und NAT passieren. So richtig scheint mir das eigentliche Ziel also noch nicht klar zu sein. Aber einen Hinweis dazu, UFW als Firewall brauchts beim Routing defnitiv nicht. Fürs masquerading reichen 2 simple Bash-Statements, die das notwendige tun - dafür brauchts kein zusätzliches Paket. Die Nat-Regeln brauchts beim Routing dann auch nur allein auf dem als VPN-Server arbeitenden System... aber nur dann, wenn die Daten-Pakete dieses System wieder verlassen sollen... z.B. auf andere Clients im Subnet hinter dem VPN-Server, oder bei Verwendung des Default-Gateway durch den VPN-Client. Aber diese Anforderungen kann ja weder sinnvoll der VServer als Client stellen, weil der ja wohl kaum aus sicherheitstechnischen Überlegungen willkürlich diverse private Clients kontaktieren sollen dürfte, noch die Heimserver-Seite, weils auf der VServer-Seite ja keine Clients gibt... höchstens ein Default-Gateway... aber das zu tun erschließt sich mir noch nicht der Sinn.

Irgendwie fällts mir schwer, bei solchen vagen Anforderungen sinnvolle Ratschläge zu geben.

[scriptorius]

Danke für die Hinweise.
Ich denke, es ist offensichtlich, dass (zumindest ich) mich hier auf Neuland begebe und deshalb für jeden Tipp dankbar bin.

Klarer kann ich deshalb mein Ziel nicht formulieren:
Ich möchte mit Hilfe des vServers (und dessen öffentlicher ipv4 Adresse) auf meinen Server zu Hause (mit ds-lite Anschluss) zugreifen und dessen Dienste (etwa nextcloud etc.) nutzen können.

Die Anleitung von andydid (s.o.) bringt OpenVPN schon mal zum "Laufen" (das konnte ich schon testen - vielen Dank dafür). Allerdings scheint hier noch einiges zu fehlen (bez. firewall, Zertifikate etc.), wie er selber schreibt.

Kannst Du dazu praxisorientiert noch etwas
"verbessern" oder beitragen?

[andydld]

Firewall/NAT/Forwarding mässig mit nftables sieht's bei mir auf dem vServer so aus:

Code: Alles auswählen

apt install nftables
systemctl enable nftables.service

Dann

Code: Alles auswählen

/etc/nftables.conf

und folgendes einfügen (natürlich den eigenen Gegebenheiten anpassen):

Code: Alles auswählen

table ip nat {
chain prerouting {
type nat hook prerouting priority 0;
# redirect port 80/tcp (http) to webserver
iif eth0 tcp dport { 80 } dnat 192.168.1.2
}
chain postrouting {
type nat hook postrouting priority 100;
oif tun0 masquerade
}
}

Das ist soweit nur eine Minimal-Konfig.
Anschl. die neue Konfig. laden/aktivieren:

Code: Alles auswählen

nft -f /etc/nftables.conf

Kannst du vom vServer aus Systeme im LAN erreichen?
In meinem Beispiel und sofern alles passt und die Firewalls es durchlassen kann man den Webserver mit der 192.168.1.2 anpingen.

[scriptorius]

Ja, das scheint soweit zu klappen.

[TomL]

Kannst Du dazu praxisorientiert noch etwas "verbessern" oder beitragen?

Nur als Anregung... vielleicht kannst Du darüber das eine oder andere ableiten oder übernehmen ... ... es ist allerdings anders, weil ich das Road-Warrior-Konzept verfolge ... guck einfach mal hier nach ... schädlich wirds nicht sein. Auf einer weiteren Seite habe ich das auch mit dem Paketfilter und weiteren Sicherheitsüberlegungen tiefergehend betrachtet. Vielleicht hilft das ja auch irgendwie weiter.

[scriptorius]

Vielen Dank,
ja, das erschwert die Sache zusätzlich, dass es wohl ziemlich viele Ansätze gibt. Gleichzeitig ist es nicht einfach, eine praxisorientierte Schritt für Schritt Anleitung im Netz zu finden.
Es scheint sich bei OpenVPN in der letzten Zeit auch etwas hinsichtlich der Konfiguration geändert zu haben.
Ich meine, diese Anleitung im Netz kommt dem hier eingeschlagenem Weg am nächsten:

https://palitechsociety.blogspot.com/20 ... 0.html?m=1

... zumindest werden hier die Variablen passend konfiguriert.

[scriptorius]

Hallo TomL,
ich möchte mich noch mal für die ausführliche Anleitung bedanken.
Das war sicherlich sehr viel Arbeit.
Du solltest ein Buch zu dem Thema veröffentlichtlichen.

Jetzt am Wochenende werde ich mich mal einlesen. Sicherlich werde ich da einiges über nehmen können.

@andydid
Bist Du denn schon weiter gekommen?

[andydld]

Leider bin ich noch nicht weiter dazugekommen.
Ein Supporter lies mich wissen, das unklar wäre, wie lange es nftables noch geben wird, da es mit BPF bereits einen Nachfolger gibt.

[TomL]

Ein Supporter lies mich wissen, das unklar wäre, wie lange es nftables noch geben wird, da es mit BPF bereits einen Nachfolger gibt.

Nein, gibt es nicht.... zumindest auf Jahre hinaus noch nicht. Das ist meines Wissens nach in einem total frühen Entwicklungsstadium, noch weit entfernt von wirklicher Inbetriebnahme. Darüber hinaus wird das wohl auch nur die Kernelmodule betreffen und soll auf die Frontends im Userspace mit iptables und nftables keinen Einfluss haben.

Stand heute sind im Kernel die alten statischen iptables-Tabellen durch die flexibleren nftables-Module ausgetauscht, das alte Frontend 'iptables' wurde gegen ein neues Frontend 'nftables' ausgetauscht.... ipstables-Statements funktioneren aber trotzdem immer noch, sie werden halt nur durch einen Parser/Generator in nftables-Syntax übersetzt. Das bedeutet, sogar die iptables-Syntax lebt heute immer noch weiter. Wobei ich das heute gar nicht mehr nutze, die nftables-Syntax ist deutlich besser zu handhaben.

BTW, welcher Supporter war das, an welcher Stelle kann man das nachlesen?

[andydld]

Ein Kollege von Heinlein Support hat mir das mitgeteilt, ich hatte dort eine Support-Anfrage zu diesem Thema gestellt. Das ist schon eine Weile/Wochen her und heute kam eben diese Antwort. Man habe dort zudem keine Erfahrung mit nftables und nutze nach wie vor iptables. Wird aber vmtl. so sein wie von dir beschrieben, das es automatisch "übersetzt" wird.

[MSfree]

Nein, gibt es nicht....

BPF ist doch der Berkeley Paket Filter, also eigentlich BSD-Unix. Bist du sicher, daß der überhaupt jemals in Linux Einzug halten wird?

[TomL]

Ich habe echt keine Ahnung, wie da die Zukunft aussieht. Ich habe nur gelesen, dass man resp. die Entwickler sich davon gravierende Performance-Vorteile versprechen.... was man da irgendwie aus den vagen Meldungen so herauslesen kann. Allerdings vermute ich auch, dass wir hier selbst mit Bullseye noch nichts davon sehen werden.... aber wie gesagt, alles nur raterei. Für mich war der Wechsel von iptables auf nftables tatsächlich eine ähnlich positive Erfahrung, wie damals der Wechsel von sysv nach systemd. Deswegen hoffe ich für mich, dass nftables noch lange Zeit so bleibt.

[andydld]

Gute Frage. Habe gerade mal auf die Schnelle gesucht, dazu bspw. das hier gefunden:

https://www.admin-magazin.de/Das-Heft/2 ... rn-mit-XDP

Wenn dann geht's wohl eher um eBPF.

Doku gibt's zudem auf der Kernel-Seite:

http://man7.org/linux/man-pages/man2/bpf.2.html

[TomL]

Ein Kollege von Heinlein Support hat mir das mitgeteilt, ich hatte dort eine Support-Anfrage zu diesem Thema gestellt. .... Man habe dort zudem keine Erfahrung mit nftables und nutze nach wie vor iptables.

Nuja, das ist aber auch ein bisschen so, als frage man den Berliner Konditor nach dem Rezept für "Rheinischer Sauerbraten". Besser wäre es, wenn Du diese Frage in der nftables-Mailing-Liste stellen würdest. Wobei ich vermute, dass es selbst von da keine abschließende Antwort gibt.

[andydld]

Tilt. Den Vergleich verstehe ich nun nicht.

Das Thema ist ja "Port Forwarding in OpenVPN-Tunnel" und nicht ob nftables durch bpf(ilfter) etc. ersetzt werden wird.
Trotz vorhandener Glaskugel konnte man im Vorfeld ja nicht wissen, wer mit was welche Erfahrung hat.

Bei Heinlein Support hatte ich zum Thema (s.o.) eine Frage gestellt, das war glaub ich seinerzeit noch bevor es diesen Thread gab und zudem aus positiver Erfahrung heraus bei einer anderen Sache.

[TomL]

Den Vergleich verstehe ich nun nicht.

Die Antwort hat Heinlein ja selber gegeben: "Man habe dort zudem keine Erfahrung mit nftables und nutze nach wie vor iptables."
Heinlein ist ein Dovecot- und Postfix-Guru, und genau dabei ohne jeden Zweifel eine absolute Kapazität.... aber eben nicht für OpenVPN oder gar den Paketfilter. Und wenn man sich an OpenVPN-Spezialisten wenden will, gibts auch dafür eine Mailing-Liste. In den Listen trifft man dann auf Leute wie Florian Westphal beim Paketfilter, oder für OpenVPN z.B. auf Keijser und Döring... die dort jeweils ebenfalls die Gurus sind.

[scriptorius]

Hallo,
mir ist es gelungen diesen ssh-Tunnel nach Anleitung des ct-Berichtes zu bauen.
https://www.heise.de/select/ct/2018/2/1515452696423264

Wenn man sich ein wenig einliest und -denkt, ist das gut zu schaffen.
Das scheint mit sicherer zu sein, als mit 6tunnel zu arbeiten. Liege ich da richtig?

Natürlich hätte ich am liebsten die Lösung mit OpenVPN, aber das Thema scheint mir jedoch sehr komplex.
Leider sind hier jetzt auch die Herbstferien vorbei.
Das Thema OpenVPN nehme ich mir für die Weihnachtsferien vor.

@TomL
Wenn es recht ist, würde ich mich dann noch mal mit Fragen melden,
Deine Seite habe ich runtergeladen. Die ist wirklich sehr gut

Vielen Dank für die Hilfe und, dass Ihr Euer Wissen hier teilt ...

P.S.: Ich habe einen Internetanschluss der Deutschen-Glasfaser und einen VServer bei IONOS gemietet für dauerhaft 1,-€ (VPS S
) im Monat

[andydld]

@TomL:

Auf deren Homepage ist generell von Linux zu lesen, das ist natürlich ein sehr weites Feld.
Jetzt mal überspitzt ausgedrückt steht da nichts von "Dovecot-/Postfix-only".
Das ist soweit jetzt ja auch nichts das Thema.
Man hat halt gefragt, man bekam eine Antwort, alles gut.

@scriptorius:

> Das scheint mit sicherer zu sein, als mit 6tunnel zu arbeiten. Liege ich da richtig?

Imho ja. 6tunnel leitet ja nur weiter bzw. um, ohne selbst (nochmal) irgendwie zu verschlüsseln.
Inwiefern das dann relevant ist, hängt davon ab, was man weiterleitet.

> P.S.: Ich habe einen Internetanschluss der Deutschen-Glasfaser

Das ist ein Grund, warum ich mir das gerade ansehe. Bei uns läuft aktuell die Nachfragebündelung, von persönlicher Neugierde mal ganz abgesehen.

[scriptorius]

Sehr verkürzt habe ich den Artikel so umgesetzt:

# Server-Umleitung mit einem ssh-Tunnel
> entsprechende Ports für Heimserver und vServer freigeben:

Auf dem root-Server (vServer)
• # nano /etc/ssh/sshd_config
>
PermitRootLogin without-password
GatewayPorts yes
ClientAliveInterval 10
ClientAliveCountMax 3

• # cd /root/
• # ssh-keygen -t ed25519 -N "" -f .ssh/example-root
• # cd /root/.ssh
• # cp example-root.pub authorized_keys
• # nano /root/.ssh/authorized_keys
> ganz am Anfang der Schlüsselzeile, also als erstes:
command="/bin/false"
• # chmod 600 /root/.ssh/authorized_keys
Die Datei /root/.ssh/example-root muss zum Heimserver kopiert werden
• # scp /root/.ssh/example-root [...]

Auf dem Heimserver
• # mv /home/>USER</example-root /home/>USER</.ssh/
• # chmod 600 /home/>USER</.ssh/example-root

Auf dem Heimserver > Aufbau des Tunnels:
temporärer Versuch:
• # ssh -R 80:hostname:80 -i /home/>user</.ssh/example-root -N root@ip-Adresse-vServer
Anmerkung: hostname des Heimservers > # hostname -f

Ein Script erstellen, dass den Tunnel automatisch startet:
Auf dem Heimserver
• # touch /root/ssh_tunnel.sh
• # nano /root/ssh_tunnel.sh
>
#!/bin/bash
while true
do
ssh -N -R 80:hostname:80 -i /home/>USER</.ssh/example-root -o ServerAliveInterval=10 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes root@IP-Adresse-vServer
sleep 1
done
• # chmod +x /root/ssh_tunnel.sh
• # crontab -e
>
@reboot /root/ssh_tunnel.sh

... wenn man den Artikel daneben legt, wird vieles klar. Den kann man da für 1,50€ runter laden.
https://shop.heise.de/zeitschriften/ct/ ... -t-02-2018
(S. 138)