Self-Hosted Proxy Server als Alternative zu VPN?

[x.treme]

Hallo zusammen,

derzeit greife ich auf meine Selbstgehosteten Dienste im Netzwerk via VPN zu (Synology Drive, Bitwarden, etc.)
Leider zieht ein aktivierter VPN insb. bei meinem Smartphone unterwegs den Akku leer.

Als Alternative habe ich mir überlegt:

• Self-Hosted SOCK5 Proxy Server z.B. bei IONOS für 1€ im Monat hosten
• Sophos Firewall Heimnetz alles außer die IP vom Proxy Server sperren

Damit sollte man ja den möglichen Angriffsvektor ziemlich minimieren können ...

Meinungen zu der Idee?

 

[eigs]

Ich würde WireGuard verwenden. Braucht weniger Strom als die meisten anderen VPN Lösungen.

 

[itm]

Ich mache sowas ähnliches allerdings nicht mit Sock5 sondern Wireguard und Caddyserver (man könnte da auch nginx reverse proxy nehmen) als Reverseproxy... Auch mit genau dem 1€ Server... Bitwarden liegt auf meinem Server @ Home...

 

[SlaterTh90]

Würde da auch WireGuard empfehlen. Das macht nur "on demand" etwas und braucht so sehr wenig Strom. Es wird nichtmal ne Verbindung offen gehalten (ist UDP) außer man stellt es extra ein.

 

[x.treme]

Ich mache sowas ähnliches allerdings nicht mit Sock5 sondern Wireguard und Caddyserver (man könnte da auch nginx reverse proxy nehmen) als Reverseproxy... Auch mit genau dem 1€ Server... Bitwarden liegt auf meinem Server @ Home...

Die Idee klingt auch nicht so verkehrt.

Beim WireGuard Routing kann ich vmtl. nur IPs (e.g. 192.168.0.5) und keine Domains wie local.mydomain.de angeben?
Wenn ich den kompletten Traffic (und DNS-Anfragen) durchschicke löst dies ja das Energie-Problem nicht.

Das wäre dämlich, weil ich so keine HTTPS-Let's-Encrypt Zertifikate für meine Dienste nutzen kann.

 

[andy_m4]

Beim WireGuard Routing kann ich vmtl. nur IPs (e.g. 192.168.0.5) und keine Domains wie local.mydomain.de angeben?

Ähm.
Was hat jetzt VPN mit Namensauflösung zu tun?
Was hat Routing mit Namensauflösung zu tun?

 

[Bob.Dig]

Vielleicht besser den Akku wechseln? Nutze OpenVPN und habe da kein Problem. Aber ja, es verbraucht mehr als ohne.

Ergänzung (22. Dezember 2021)

Was hat jetzt VPN mit Namensauflösung zu tun?

Wenn es lokal sein soll, dann einiges.

 

[andy_m4]

Wenn es lokal sein soll, dann einiges.

Für lokal gibts die /etc/hosts

 

[Der Lord]

Das wäre dämlich, weil ich so keine HTTPS-Let's-Encrypt Zertifikate für meine Dienste nutzen kann.

kannst du das mal bitte näher erläutern? ich verstehe den Zusammenhang zwischen einem Client, der via VPN auf Dienste zugreift, und LE-Certs am Host nicht wirklich.

bzgl. nicht alles durch den Tunnel jagen: Split-Tunnel könnte helfen.

 

[SlaterTh90]

Beim WireGuard Routing kann ich vmtl. nur IPs (e.g. 192.168.0.5) und keine Domains wie local.mydomain.de angeben?
Wenn ich den kompletten Traffic (und DNS-Anfragen) durchschicke löst dies ja das Energie-Problem nicht.

Das wäre dämlich, weil ich so keine HTTPS-Let's-Encrypt Zertifikate für meine Dienste nutzen kann

Man kann einzelne IPs oder auch ganze Netze durch WireGuard Routen (oder halt alles wenn man will). Man kann auch spezielle DNS Server festlegen.

So in der Art hatte ich das auch schon am laufen, Handys/Tablets mit WireGuard Zugriff von außen geben, WireGuard so eingestellt das nur IPs vom Heimnetzwerk durch geschleift werden. Dann noch einen eigenen DNS-Server (macht die Firewall mit unbound, sowas wie pihole tut aber auch) der per local override die lokale IP für die Services rausgibt (z.B. 192.168.199.10).

Opnsense Firewall ist zuhause die Gegenstelle. Das funktioniert einwandfrei, bis auf den Port für WireGuard kann die Firewall so auch ganz zu bleiben (falls man DNS01 challenges bei LetsEncrypt nutzt).

 

[Bob.Dig]

ich verstehe den Zusammenhang zwischen einem Client, der via VPN auf Dienste zugreift, und LE-Certs am Host nicht wirklich.

Private IPs und LE geht vor allem mit eigenem DNS gut.

 

[Der Lord]

Ach so ist das gemeint, ja ok, verstehe ich.
Ich nutze einfach ein Wildcard-LE-Zertifikat und kann es für alle meine privaten Dienste zuhause nutzen. ^^

 

[x.treme]

Hat's eigentlich irgendwelche Nachteile, wenn ich in den öffentlichen DNS-Einstellungen meiner Sub-Domain eine lokale IP angebe (e.g. 192.168.0.5).

Dann spare ich mir das Routen der DNS Anfragen durch den VPN
(Klar, für's Refreshen des Let's Encrypt Zertifikat muss ich dann wieder auf DynDNS umstellen. Aber das ist eh jedesmal ein manueller Aufwand wegen der Port-Freigabe hierfür)

 

[eigs]

Hat's eigentlich irgendwelche Nachteile, wenn ich in den öffentlichen DNS-Einstellungen meiner Sub-Domain eine lokale IP angebe (e.g. 192.168.0.5).

Jeder der die Subdomain auflöst bekommt die interne IP Adresse, du kannst keinen öffentlichen Dienst zeitgleich anbieten und sollte die Domain von jemand anderen übernommen werden könnte er sie auf eine beliebige andere IP Adresse auflösen lassen.

 

[x.treme]

Okay, ich glaube ich habe die perfekte Lösung gefunden:

• CloudFlare Free Account
• Vorgeschaltetete CloudFlare Teams mit SingleSignOn Authentification
• Nur die IP von ClouFlare im Router akzeptieren
• Ggf. den CloudFlare Tunnel nutzen, dann müssen garkeine Ports geöffnet werden

Was haltet ihr von so einem CloudFlare Setup?

 

[andy_m4]

Nichts. Macht wenig Sinn wenn man VPN und möglich viel selbstgehostetes Zeug hat um Datenkraken zu entgehen und dann den Kram über ausgerechnet CloudFlare laufen zu lassen.

 

[x.treme]

Ja auch gerade realisiert dass es ja eine Man in the Middle Lösung ist, eine End to End HTTPS Verschlüsselung von Client zu NAS ist damit nicht mehr gegeben .

 

[foo_1337]

Was genau ist denn jetzt das Problem, das via Wireguard zu machen?
Wenn du das via reverse proxy machen willst: Miete dir eine ARM Instanz aus dem always free tier (max 4 cores, 24GB RAM, 200GB SSD... sprich mehr als genug) und packe darauf einen nginx oder haproxy oder sonstiges deiner Wahl. Den lässt du via LE ein Cert holen und routest das zeug auf deine lokalen Kisten. Du lässt da halt nur die EXT-IP der Kiste in der Cloud zu. Die self signed Zertifikate bzw das CA cert von deinen Kisten zuhause musst du natürlich dem nginx bekannt machen, damit er denen vertrauen kann.

 

[x.treme]

Was genau ist denn jetzt das Problem, das via Wireguard zu machen?

z.B kein Zugriff wenn ich über meinen Arbeits-PC auf meine Wiki zugreifeb will, da ich hier keine eigenen VPN einrichten kann.

Werde Mal weiter nach Lösungen schauen wie ich einen SSO Service zur Authentifizierung davor schalten kann. Möchte meine Synology nicht direkt über 443 exposen ohne noch einen Filter davor.

 

[foo_1337]

Naja, wie oben geschrieben reicht hier ein nginx mit aktivierter basic auth, starkem Passwort, fail2ban oder ratelimit und optional noch 2FA vollkommen aus.
Das ganze wird natürlich die Synology apps brechen (außer die verstehen https://foo:bar@blargh). Daher wenn gewünscht noch nen wg tunnel fürs smartphone und per nginx acl dafür sorgen, dass alles was über den tunnel kommt, keine auth benötigt.