Cloudserver aus dem Netz erreichbar machen trotz VPN für Mediacenter auf Raspi
Hallo Leute,
Ich bin kein hauptberuflicher It-ler sondern hantiere nur in der Freizeit ein wenig mit solchen Sachen, daher bitte ich schon mal vorweg um ein wenig Nachsicht für DAUigkeit ;)
Habe mir vor ein paar Wochen einen Raspberry-pi b+ gekauft um darauf einen cloudserver und ein mediacenter laufen zu lassen.
Das funktioniert dank JanKarres Anleitungen auch alles ganz gut.
Auf dem pi sind 2 usb Sticks im RAID1, auf dem Router ist ein dyndns Dienst eingerichtet und die Ports für den Seafile cloudserver und eine ssh Verbindung zum steuern sind weitergeleitet.
D.h. ich kann sowohl vom LAN als auch aus dem Internets auf Dateien zugreifen die in der Cloud liegen.
Als zweite Komponente läuft auf dem pi ein xbmc media center.
da ja im Neuland mittlerweile überall zensiert und geblockt wird, kommt man auch beim xbmc nicht um eine Verschleierung der ip herum. Deswegen nutze ich einen vpn Anbieter um das geoblocking zu umgehen.
Dies funktioniert ebenfalls für sich gesehen ganz gut über openvpn, die Crux ist nur, dass sobald ich den openvpn Dienst per ssh vom Laptop aus einschalte, ist der Seafile Server nichtmehr aus dem internetz bzw. Über dyndns zu erreichen.
D.h. ich muss jedes mal mittels ssh den vpn Client ausschalten wenn ich vor die Tür gehe.
Da der vpn Anbieter auch socks Proxies anbietet habe ich versucht den xbmc über die integrierte Oberfläche über den Proxy zu leiten, jedoch ohne Erfolg. Ebenso habe ich dank Unterstützung des Anbieters dann per kommandozeile einen ssh Tunnel aufgebaut und versucht dann in der xbmc Oberfläche localhost anzugeben, was aber leider auch fehlschlug.
mir scheint das die Oberfläche des xbmc für Proxies defekt ist.
Tl;tr
-ich suche eine Möglichkeit entweder für den xbmc von " außen" eine Proxy Verbindung aufzwingen.
-oder xbmc und Seafile mittels vlan Adapter irgendwie zu trennen, dass man quasi nur für den xbmc die vpn Verbindung herstellt.
-oder eine Möglichkeit die Seafile Ports trotz vpn lokal an dieser vorbei für den Router zu öffnen.
- oder ganz andere Ansätze, die zum Ziel haben, dass mein Seafile Server aus dem Netz erreichbar bleibt und der xbmc gleichzeitig seine ip verschleiert.
Wa ales .
Ich bin kein hauptberuflicher It-ler sondern hantiere nur in der Freizeit ein wenig mit solchen Sachen, daher bitte ich schon mal vorweg um ein wenig Nachsicht für DAUigkeit ;)
Habe mir vor ein paar Wochen einen Raspberry-pi b+ gekauft um darauf einen cloudserver und ein mediacenter laufen zu lassen.
Das funktioniert dank JanKarres Anleitungen auch alles ganz gut.
Auf dem pi sind 2 usb Sticks im RAID1, auf dem Router ist ein dyndns Dienst eingerichtet und die Ports für den Seafile cloudserver und eine ssh Verbindung zum steuern sind weitergeleitet.
D.h. ich kann sowohl vom LAN als auch aus dem Internets auf Dateien zugreifen die in der Cloud liegen.
Als zweite Komponente läuft auf dem pi ein xbmc media center.
da ja im Neuland mittlerweile überall zensiert und geblockt wird, kommt man auch beim xbmc nicht um eine Verschleierung der ip herum. Deswegen nutze ich einen vpn Anbieter um das geoblocking zu umgehen.
Dies funktioniert ebenfalls für sich gesehen ganz gut über openvpn, die Crux ist nur, dass sobald ich den openvpn Dienst per ssh vom Laptop aus einschalte, ist der Seafile Server nichtmehr aus dem internetz bzw. Über dyndns zu erreichen.
D.h. ich muss jedes mal mittels ssh den vpn Client ausschalten wenn ich vor die Tür gehe.
Da der vpn Anbieter auch socks Proxies anbietet habe ich versucht den xbmc über die integrierte Oberfläche über den Proxy zu leiten, jedoch ohne Erfolg. Ebenso habe ich dank Unterstützung des Anbieters dann per kommandozeile einen ssh Tunnel aufgebaut und versucht dann in der xbmc Oberfläche localhost anzugeben, was aber leider auch fehlschlug.
mir scheint das die Oberfläche des xbmc für Proxies defekt ist.
Tl;tr
-ich suche eine Möglichkeit entweder für den xbmc von " außen" eine Proxy Verbindung aufzwingen.
-oder xbmc und Seafile mittels vlan Adapter irgendwie zu trennen, dass man quasi nur für den xbmc die vpn Verbindung herstellt.
-oder eine Möglichkeit die Seafile Ports trotz vpn lokal an dieser vorbei für den Router zu öffnen.
- oder ganz andere Ansätze, die zum Ziel haben, dass mein Seafile Server aus dem Netz erreichbar bleibt und der xbmc gleichzeitig seine ip verschleiert.
Wa ales .
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 258622
Url: https://administrator.de/forum/cloudserver-aus-dem-netz-erreichbar-machen-trotz-vpn-fuer-mediacenter-auf-raspi-258622.html
Ausgedruckt am: 29.04.2025 um 03:04 Uhr
5 Kommentare
Neuester Kommentar
Zuerst einmal Respekt, denn für einen Hobby ITler der sowas zum Fliegen bringt kann der DAUigkeit Level nicht sehr hoch sein 
Das Problem liegt nicht an dir sondern an deinem VPN Anbieter. Der setzt das Default Gateway des RasPi bei OVPN Einwahl über das Setup fest auf die VPN Tunneladresse des Servers so das ALLER Traffic in bzw. über den Tunnel geroutet wird...natürlich dann auch dein SSH.
Theoretisch müsstest du also nur die Tunnel IP ansprechen und du landest wieder auf deinem RasPi. Theoretisch...! Keiner der VPN Anbieter macht da ein Port Forwarding und damit entfällt dann diese Option. Das Verhalten ist also mit diesem Provider Setup normal.
Du könntest versuchen die gepushte Default Route nach der VPN Einwahl mit einem Script wieder "umzubiegen", so das du nur IP Traffic für die Zielnetze wo du deine IP verschleiern willst in den Tunnel routetst, alles andere aber über dein lokales Gateway.
Das ist erstmal mit minimalem Aufwand zu machen.
Die zweite Idee die möglich ist, ist einen USB Ethernet Adapter am RasPi zu verwenden und über ein zweites Netzwerk Interface bzw. IP Netz darüber den SSH Zugang zu realisieren.
Das RasPi_Tutorial hier beschreibt dir wie so ein Adapter einzubinden ist.
Das Problem liegt nicht an dir sondern an deinem VPN Anbieter. Der setzt das Default Gateway des RasPi bei OVPN Einwahl über das Setup fest auf die VPN Tunneladresse des Servers so das ALLER Traffic in bzw. über den Tunnel geroutet wird...natürlich dann auch dein SSH.
Theoretisch müsstest du also nur die Tunnel IP ansprechen und du landest wieder auf deinem RasPi. Theoretisch...! Keiner der VPN Anbieter macht da ein Port Forwarding und damit entfällt dann diese Option. Das Verhalten ist also mit diesem Provider Setup normal.
Du könntest versuchen die gepushte Default Route nach der VPN Einwahl mit einem Script wieder "umzubiegen", so das du nur IP Traffic für die Zielnetze wo du deine IP verschleiern willst in den Tunnel routetst, alles andere aber über dein lokales Gateway.
Das ist erstmal mit minimalem Aufwand zu machen.
Die zweite Idee die möglich ist, ist einen USB Ethernet Adapter am RasPi zu verwenden und über ein zweites Netzwerk Interface bzw. IP Netz darüber den SSH Zugang zu realisieren.
Das RasPi_Tutorial hier beschreibt dir wie so ein Adapter einzubinden ist.
Hallo aqui
dank der tollen Guides und Erklärungen von Leuten wie u.a. Dir und Jan ist es ja kein Hexenwerk mehr
OK. Das funktioniert zwar mit ssh, jedoch scheint Seafile darüber nicht ansprechbar zu sein. (zumindest hieße das , dass ich nun von unterwegs aus per ssh den ovpn clienten abschalten kann)
Das blöde ist aber, das die ports nicht permanent sind, sondern jede woche wechseln, d.h. man muss jede woche aufs neue einstellen, selbst wenn das mit seafile funktionieren würde.
Zudem habe ich von Scripten nicht wirklich Ahnung, und wüsste nicht wo ich da anfangen soll.
zb kann man ja mit :
sudo ip link add virtual0 link eth0 type macvlan mode bridge
sudo ip address add 192.168.2.x broadcast 192.168.2.255 dev virtual0
einen virtuellen adapter mit eigener mac adresse erstellen.
nur der router findet zwar jetzt die neue mac adresse, aber mit der LAN ip des eth0 adapters o.O
Aber egal ob über usb oder virtuell, wie bekomme ich denn den traffic getrennt, das auf dem einen adapter xbmc läuft und auf dem anderen seafile?
normalerweise nimmt das os bzw alle programme doch einfach den ersten adapter oder wie muss ich das machen ?
dank der tollen Guides und Erklärungen von Leuten wie u.a. Dir und Jan ist es ja kein Hexenwerk mehr
Keiner der VPN Anbieter macht da ein Port Forwarding
Das bringt mich gerade auf eine Idee, denn soweit ich weiß macht das Perfect-Privacy aber auch nur mit random Ports für maximal 7 Tage. Für jeden User wird dann quasi seperat auf dem entsprechenden Server weitergeleitet......OK. Das funktioniert zwar mit ssh, jedoch scheint Seafile darüber nicht ansprechbar zu sein. (zumindest hieße das , dass ich nun von unterwegs aus per ssh den ovpn clienten abschalten kann)
Das blöde ist aber, das die ports nicht permanent sind, sondern jede woche wechseln, d.h. man muss jede woche aufs neue einstellen, selbst wenn das mit seafile funktionieren würde.
so das du nur IP Traffic für die Zielnetze wo du deine IP verschleiern willst
Zielnetze wechseln beim xbmc ja immer je nach dem welchen dienst man gerade nutzt und den tunnelserver möchte man ja ggf auch wechseln um ein anderes herkunftsland vorzugaukeln.Zudem habe ich von Scripten nicht wirklich Ahnung, und wüsste nicht wo ich da anfangen soll.
und über ein zweites Netzwerk Interface
ginge das nicht auch mit einem virtuellen adapter?zb kann man ja mit :
sudo ip link add virtual0 link eth0 type macvlan mode bridge
sudo ip address add 192.168.2.x broadcast 192.168.2.255 dev virtual0
einen virtuellen adapter mit eigener mac adresse erstellen.
nur der router findet zwar jetzt die neue mac adresse, aber mit der LAN ip des eth0 adapters o.O
Aber egal ob über usb oder virtuell, wie bekomme ich denn den traffic getrennt, das auf dem einen adapter xbmc läuft und auf dem anderen seafile?
normalerweise nimmt das os bzw alle programme doch einfach den ersten adapter oder wie muss ich das machen ?
wie bekomme ich denn den traffic getrennt, das auf dem einen adapter xbmc läuft und auf dem anderen seafile?
Das macht man mit Policy based Routing 
1
Ahh ok
Werde mir nun mal http://wiki.linux-club.de/opensuse/Policy_Based_Routing zu gemüte führen und mich dann wieder melden :D
Werde mir nun mal http://wiki.linux-club.de/opensuse/Policy_Based_Routing zu gemüte führen und mich dann wieder melden :D
also irgendwie scheint das auch nicht so recht zu funktionieren, denn egal wo ich schaue, immer fungiert das gerät auf dem das routing geschieht immer nur als mittelstation und nicht als server.
mit diesem befehl zb markiere ich ja ein paket das von dyndns an meinen router und von diesem an den raspi mit der x.222 als ziel geschickt wird und auf dem port 1505 ankommt mit dem mark1
iptables -t mangle -A PREROUTING -p tcp -s 0/0 -d 192.168.2.222/32 --dport 1505 -j MARK --set-mark 1
und hiermit erstelle ich nun eine regel das alles mit dem mark1 die tabelle "novpn" nehmen soll
ip rule add fwmark 1 table novpn
und hiermit die tabelle novpn die das paket dann an den virtuellen adapter weiterleiten soll
ip route add 192.168.2.222 table novpn via 192.168.2.223 dev virtual0
das ganze habe ich nun noch in die /etc/network/interfaces geschrieben, damit es beim starten geladen wird.
post-up ip rule add fwmark 1 table novpn
post-up ip route add 192.168.2.222 table novpn via 192.168.2.223 dev virtual0
post-up iptables -t mangle -A PREROUTING -p tcp -s 0/0 -d 192.168.2.222/32 --dport 1505 -j MARK --set-mark 1
trotzdem kann ich von außen nicht über den port 1505 auf den raspi zugreifen, ergo läuft noch irgendwas nicht so wie es soll.
wo ist der fehler?
hier mal das ganze setup:
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether b8:27:eb:f1:16:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.222/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none
inet 10.15.12.16/25 brd 10.15.12.127 scope global tun0
valid_lft forever preferred_lft forever
5: virtual0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 66:e8:81:07:b9:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.223/32 brd 192.168.2.255 scope global virtual0
valid_lft forever preferred_lft forever
default via 192.168.2.1 dev eth0
10.15.12.0/25 dev tun0 proto kernel scope link src 10.15.12.16
37.48.74.75 via 192.168.2.1 dev eth0
128.0.0.0/1 via 10.15.12.1 dev tun0
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.222
32765: from all fwmark 0x1 lookup novpn
32766: from all lookup main
32767: from all lookup default
mit diesem befehl zb markiere ich ja ein paket das von dyndns an meinen router und von diesem an den raspi mit der x.222 als ziel geschickt wird und auf dem port 1505 ankommt mit dem mark1
iptables -t mangle -A PREROUTING -p tcp -s 0/0 -d 192.168.2.222/32 --dport 1505 -j MARK --set-mark 1
und hiermit erstelle ich nun eine regel das alles mit dem mark1 die tabelle "novpn" nehmen soll
ip rule add fwmark 1 table novpn
und hiermit die tabelle novpn die das paket dann an den virtuellen adapter weiterleiten soll
ip route add 192.168.2.222 table novpn via 192.168.2.223 dev virtual0
das ganze habe ich nun noch in die /etc/network/interfaces geschrieben, damit es beim starten geladen wird.
post-up ip rule add fwmark 1 table novpn
post-up ip route add 192.168.2.222 table novpn via 192.168.2.223 dev virtual0
post-up iptables -t mangle -A PREROUTING -p tcp -s 0/0 -d 192.168.2.222/32 --dport 1505 -j MARK --set-mark 1
trotzdem kann ich von außen nicht über den port 1505 auf den raspi zugreifen, ergo läuft noch irgendwas nicht so wie es soll.
wo ist der fehler?
hier mal das ganze setup:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWNlink/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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether b8:27:eb:f1:16:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.222/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none
inet 10.15.12.16/25 brd 10.15.12.127 scope global tun0
valid_lft forever preferred_lft forever
5: virtual0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 66:e8:81:07:b9:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.223/32 brd 192.168.2.255 scope global virtual0
valid_lft forever preferred_lft forever
$ ip route list
0.0.0.0/1 via 10.15.12.1 dev tun0default via 192.168.2.1 dev eth0
10.15.12.0/25 dev tun0 proto kernel scope link src 10.15.12.16
37.48.74.75 via 192.168.2.1 dev eth0
128.0.0.0/1 via 10.15.12.1 dev tun0
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.222
$ ip rule list
0: from all lookup local32765: from all fwmark 0x1 lookup novpn
32766: from all lookup main
32767: from all lookup default
