Forum: PC Hard- und Software Hardware für VPN


von Johannes (Gast)


Lesenswert?

Hallo,
ich möchte gerne von außen in mein Heimnetz rein. Um z.b. auf ein NAS 
zugreifen zu können.
Dafür wollte ich mir ein VPN erstellen.
Was wäre denn dafür geeignete Hardware?
- ~2-3 Leute gleichzeitig (maximal)
- Eher seltener Zugriff (also nicht täglich und dauerhaft)
- Zugriff um Fotos/ Videos runterzuladen (die auf dem NAS sind)
- Zugriff auf einem Raspberry Pi

Das einzige was ich immer nur gefunden habe, wäre ein Raspberry Pi 
selber, oder ein von Router von TP-Link (vr605)

von Oliver S. (oliverso)


Lesenswert?

Was für einen Router hast du denn?

Oliver

von Mario M. (thelonging)


Lesenswert?

Softether auf dem Pi. Fertig.

von Thomas (Gast)


Lesenswert?

Alle neueren Fritz Boxen (ich meine ab 7530) sprechen seit Fritz-OS 7.50 
Wireguard.
Ansonsten, da du ohnehin einen Pi im Netz hast in wenigen Minuten 
eingerichtet:
https://hub.docker.com/r/weejewel/wg-easy

von (prx) A. K. (prx)


Lesenswert?

Johannes schrieb:
> ich möchte gerne von außen in mein Heimnetz rein.

Ausgehend von wo? Von einem bestimmten Festnetz bei jemand anders, oder 
via WLAN/Mobilfunk wo immer du gerade bist?

Wenn Handy/Laptop egal wo: Hast du eine eigene IPv4-Adresse, oder bloss 
eine IPv6-Adresse und gehst bei IPv4 über Carrier-Grade-NAT / Dual Stack 
lite? Ohne eigene IPv4-Adresse geht es nämlich nur per IPv6, was nicht 
aus jedem Fremd/Mobilnetz möglich ist, oder ums Eck per Hilfsserver im 
Internet.

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

So etwas wird als VPN Appliance immer gerne genommen.

https://www.servethehome.com/two-fanless-intel-celeron-n5105-4x-2-5gbe-options-reviewed/

Gibts inzwischen von verschiedenen Chinesen in verschiedenen Varianten, 
haben 2.5 GB Ethernet, und funktionieren ganz gut. Ich habe darauf 
Proxmox und einige Container und VMs am Laufen.

Für Dich ist das möglicherweise überdimensioniert, aber der Appetit 
kommt oft auch beim Essen.

fchk

von c-hater (Gast)


Lesenswert?

Thomas schrieb:

> Alle neueren Fritz Boxen (ich meine ab 7530) sprechen seit Fritz-OS 7.50
> Wireguard.

Und es gab auch schon (u.a. IPSEC-) VPN Jahrzehnte vor Wireguard und es 
hat all die Jahre gut funktioniert. Und die Fritzboxen können das auch 
schon seit mindestens 15 Jahren. (Bin zu faul, zu recherchieren, ob es 
nicht sogar 20 sind).

von Paul (Gast)


Lesenswert?

c-hater schrieb:
> Und es gab auch schon (u.a. IPSEC-) VPN Jahrzehnte vor Wireguard und es
> hat all die Jahre gut funktioniert.

Und mit IKEv1 auch absolut sicher und besser als alle anderen.

von c-hater (Gast)


Lesenswert?

Paul schrieb:

> Und mit IKEv1 auch absolut sicher und besser als alle anderen.

Das wohl nicht. Aber IKEv1 ist sicher genug für sehr viele Szenarien. 
Sprich: solange du die Verbindung nicht gegen Angriffe durch 
Geheimdienste schützen musst, ist es nach wie vor sicher genug.

Zumal die sich bei den üblichen, auf OSS basierenden VPNs typisch 
garnicht mit dem Content auseinander setzen. Die greifen auf OS-Ebene 
an. Denn dort befinden sich unzählige Sicherheitslücken, die sich mit 
viel weniger Aufwand ausnutzen lassen, als der Angriff auf starke 
Kryptographie erfordert.

von Reinhard S. (rezz)


Lesenswert?

Thomas schrieb:
> Alle neueren Fritz Boxen (ich meine ab 7530) sprechen seit Fritz-OS 7.50
> Wireguard.

Die 7.50 ist aber bis jetzt nur für die 7590 (ohne AX) offiziell 
erschienen, andere Boxen folgen noch irgendwann.

: Bearbeitet durch User
von Hugo (Gast)


Lesenswert?

Hallo,

Ist schon interessant, dass man sich über die "Auto-"Ausstattung 
unterhält aber bis auf prx keiner fragt, ob die Straße vorhanden ist.

TO: hast du eine feste IP (erstmal egal ob via v4 oder v6), oder einen 
Zugriff auf den Router via dynamic DNS resolver?
Dann wäre die Frage von welchen Geräten soll zugegriffen werden, da 
nicht jeder von Haus aus ipsec, wie vorher erwähnt,  direkt abkann.

Hugo

von Jürgen (Gast)


Lesenswert?

Reinhard S. schrieb:
> Die 7.50 ist aber bis jetzt nur für die 7590 (ohne AX) offiziell
> erschienen, andere Boxen folgen noch irgendwann.

Zug Glück gibt es Wireguard ab der schon ab der 7.39 Beta und die ist 
schon für mehrere verfügbar. Hab vor Kurzem meine 6690 umgestellt.

von Nano (Gast)


Lesenswert?

Welche Heim VPN  Lösung bietet sich denn für Streaminganbieter an, wenn 
man für diese nur von einer IP kommend, gesehen werden will?
Und funktioniert das in der Praxis zuverlässig oder stören da so Sachen 
wie Lag und Pingzeiten?

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Und funktioniert das in der Praxis zuverlässig oder stören da so Sachen
> wie Lag und Pingzeiten?

VPN über IP/UDP, also nicht über TCP, ändert das Verhalten der Strecke 
nicht nennenswert, sofern eine angepasste MTU genutzt wird. Es geht also 
mit VPN ebenso gut oder schlecht wie ohne.

Wer allerdings OpenVPN über TCP statt UDP erzwingt (wie etwa Mikrotik), 
der kann mit etwas Pech feststellen, dass dies keine gute Idee ist. Ganz 
besonders nicht bei Streaming.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Etwas hässlich kann es allerdings werden, wenn der Kram über CG-NAT 
läuft, weil der IPsec VPN-Client über Dual Stack lite muss. Was immer 
genau der Grund dafür ist: Diese Konfiguration kann(*) Homeoffice 
versauern, auch ohne Streaming. In dem Fall war es umgekehrt. Die 
Variante über SSL(TCP) funktionierte besser als die über IPsec.

*: Lies: Kann sein es geht einwandfrei, kann sein es macht Ärger.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Nano schrieb:
>> Und funktioniert das in der Praxis zuverlässig oder stören da so Sachen
>> wie Lag und Pingzeiten?
>
> VPN über IP/UDP, also nicht über TCP, ändert das Verhalten der Strecke
> nicht nennenswert, sofern eine angepasste MTU genutzt wird. Es geht also
> mit VPN ebenso gut oder schlecht wie ohne.

Und wie sieht es mit verlorenen Paketen bei VPN über IP/UDP aus?
Macht VPN dann eigenständige Rückfragen? Müsste es ja im Prinzip, wenn 
man bspw. auch Dateien darüber übertragen wollte, oder?

> Wer allerdings OpenVPN über TCP statt UDP erzwingt (wie etwa Mikrotik),
> der kann mit etwas Pech feststellen, dass dies keine gute Idee ist. Ganz
> besonders nicht bei Streaming.

Habe auf beiden Seiten eine relativ moderne FritzBox. Eine für Kabel, 
die andere für DSL.
Die für Kabel ist die, die mit dem Streaminganbieter verbunden sein 
soll. Die auf DSL Seite soll also VPN nutzen um in die Kabelbox zu 
kommen.

Bezüglich VPN und der FritzBox habe ich mich auch noch nicht 
beschäftigt, da ich bisher lieber keine Serverdienste nach außen 
angeboten habe.
Momentan denke ich darüber nach, den nach außen exponierten VPN Dienst 
per FW Regeln abzuschotten. Dazu könnte sich der Rechner mit dem VPN 
Server bspw. die IP Adresse des DSL Routers via DynDNS abholen und dann 
den VPN Zugriff auf dessen IP Adresse einschränken bis diese geändert 
wird und dann neu abgefragt werden muss.
Mit der FritzBox alleine wird das allerdings nicht gehen, weswegen der 
VPN Server besser in einer DMZ auf eigener HW laufen soll. dann kann ich 
auf dem via IPtable entsprechende FW Einstellungen vornehmen und alles 
zum VPN Server bis auf diese IP blocken.

Die Frage wäre dann noch, wie es auch der TS schon gefragt hat, welche 
Hardware sich dafür gut eignet. Da der VPN Server rund um die Uhr 
erreichbar sein soll, sollten die Stromkosten natürlich möglichst 
minimal sein. Also darf der Rechner nicht viel Leistung im IDLE 
schlucken.
Ein PC braucht eigentlich zu viel, ein Raspi wäre besser, aber eine noch 
viel größere Priorität als der Stromverbrauch hat das Einspielen von 
Sicherheitspatches, weshalb auf der HW eine gescheite Distri laufen 
sollte bei der Sicherheitspatches zeitnah verfügbar sind und das Thema 
ernst genommen wird. Das wiederum spricht dann wieder für einen PC und 
gegen einen Raspi.
Bezüglich der erforderlichen CPU Leistung und VPN habe ich keine 
Vorstellungen. Im werden die Pakete ja nur durch VPN getunnelt und 
weitergeleitet und VPN selbst hat eine verschlüsselte Verbindung. Das 
sollte jetzt nicht so viel Leistung kosten, oder?

(prx) A. K. schrieb:
> Etwas hässlich kann es allerdings werden, wenn der Kram über CG-NAT
> läuft, weil der IPsec VPN-Client über Dual Stack lite muss.

Sollte das das Problem sein, werde ich auf beiden Seiten IPv6 Adressen 
für VPN verwenden. Das sollte das Problem zumindest auf VPN Seite lösen, 
oder?

Problematisch stelle ich mir auf Clientseite noch vor zu garantieren, 
das der Client auch wirklich durch das VPN tunnelt und nicht als Bypass 
sich mit der IP des DSL Routers beim Streamingdienstanbieter meldet. Das 
letzteres nicht passiert, muss also sichergestellt werden.
Für normale Surfangelegenheiten, also ohne Nutzung des 
Streaminganbieter, will ich aber weiterhin die normale IP des DSL 
Routers verwenden, also muss das irgendwie beim Browser berücksichtigt 
werden.
Am einfachsten wäre es wohl, wenn ich den Streamingclient in eine VM 
packe und die VM sich nur mit dem VPN verbinden darf. Ob das Streaming 
in einer VM Umgebung aber noch vernünftig läuft, wäre die nächste Frage.

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Und wie sieht es mit verlorenen Paketen bei VPN über IP/UDP aus?

Weg ist weg.

> Macht VPN dann eigenständige Rückfragen? Müsste es ja im Prinzip, wenn
> man bspw. auch Dateien darüber übertragen wollte, oder?

Eine VPN-Verbindung wie IPsec ersetzt nicht TCP/IP, sondern tunnelt es 
durch die VPN-Verbindung. Wird also TCP verwendet, ist es ebendieses TCP 
auf IP auf VPN, was die fehlenden Pakete nachfordert.

Wird die VPN über TCP implementiert, beispielsweise das erwähnte OpenVPN 
im TCP Modus, hat man dann 2 Retransmission-Layer übereinander. Und das 
kann ein Rezept für Ärger sein, weil es bei Paketverlusten die 
Retransmissions vervielfacht. Sie kann sich dadurch völlig zustopfen und 
wird in bestimmten eigentlich harmlosen Fällen instabil.

Bei bidirektionalem Audio/Video-Streaming von Telefonie und 
Videokonferenzen sind Retransmissions ohnehin zweifelhaft, deshalb 
unüblich. Fehlenden Daten zu ignorieren oder zu interpolieren ist i.d.R. 
sinnvoller, als sie mit deutlicher Verzögerung zu erhalten.

> Die für Kabel ist die, die mit dem Streaminganbieter verbunden sein
> soll. Die auf DSL Seite soll also VPN nutzen um in die Kabelbox zu
> kommen.

Klingt so, als ob 3 Nodes beteiligt sind. Der Streaming-Anbieter, die 
Kabelbox und die DSL-Box. Eine VPN-Verbindung hat aber nur 2 Enden. 
Klärung nötig.

> Sollte das das Problem sein, werde ich auf beiden Seiten IPv6 Adressen
> für VPN verwenden. Das sollte das Problem zumindest auf VPN Seite lösen,
> oder?

Ja.

: Bearbeitet durch User
von Thomas (kosmos)


Lesenswert?

seit ein paar Tagen gibts auch für die 7490 die 7.51 als Laborversion.

von Nano (Gast)


Lesenswert?

(prx) A. K. schrieb:
>> Macht VPN dann eigenständige Rückfragen? Müsste es ja im Prinzip, wenn
>> man bspw. auch Dateien darüber übertragen wollte, oder?
>
> Eine VPN-Verbindung wie IPsec ersetzt nicht TCP/IP, sondern tunnelt es
> durch die VPN-Verbindung. Wird also TCP verwendet, ist es ebendieses TCP
> auf IP auf VPN, was die fehlenden Pakete nachfordert.

Hast natürlich recht. Habe gerade nicht richtig nachgedacht, dass bei 
VPN ja nichts anderes als wieder ein eigenes "inneres" UDP/TCP/IP Netz 
aufspannt wird bzw. dieses Netz getunnelt wird.

So gesehen sollte "außen" für VPN UDP reichen.

> Wird die VPN über TCP implementiert, beispielsweise das erwähnte OpenVPN
> im TCP Modus, hat man dann 2 Retransmission-Layer übereinander. Und das
> kann ein Rezept für Ärger sein, weil es bei Paketverlusten die
> Retransmissions vervielfacht. Sie kann sich dadurch völlig zustopfen und
> wird in bestimmten eigentlich harmlosen Fällen instabil.

Zustimmung.

>
>> Die für Kabel ist die, die mit dem Streaminganbieter verbunden sein
>> soll. Die auf DSL Seite soll also VPN nutzen um in die Kabelbox zu
>> kommen.
>
> Klingt so, als ob 3 Nodes beteiligt sind. Der Streaming-Anbieter, die
> Kabelbox und die DSL-Box. Eine VPN-Verbindung hat aber nur 2 Enden.
> Klärung nötig.

Der Streaminganbieter liegt im öffentlichen Internet.
Es soll also nur über die Kabelbox und die DSL-Box ein VPN Tunnel 
aufgebaut werden und der Streaminganbieter soll ausschließlich nur die 
IP der Kabelbox sehen.
Das gilt insbesondere auch dann, wenn man auf einem Client auf Seiten 
der DSL Box durch den VPN Tunnel den Dienst des Streaminganbieter nutzt.

Allerdings soll der Client, wenn der Streamingdienst nicht genutzt wird, 
also für den Rest des Internets nicht durch den VPN Tunnel 
kommunizieren, sondern hier dann direkt mit der IP der DSL Box nach 
außen kommunizieren.

Es gibt also folgende zwei Konstellationen:

S = Streamingdienst
R = restliche Internet
K = Kabelbox
D = DSL-Box
C = Client (hier hinter der DSL Box)
'=' = getunnelte VPN Verbindung
'-' = normale Internetverbindung bzw. Lanverbindung

1. Konstellation zum Streamingdienst
S---K===D---C

2. Konstellation zum Rest des Internet für einen Client, der örtlich bei 
der DSL-Box steht.
R---D---C

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Der Streaminganbieter liegt im öffentlichen Internet.
> Es soll also nur über die Kabelbox und die DSL-Box ein VPN Tunnel
> aufgebaut werden und der Streaminganbieter soll ausschließlich nur die
> IP der Kabelbox sehen.

M.a.W: Du willst Anbieter wie Netflix verarschen. ;-)

von Nano (Gast)


Lesenswert?

Ich habe ja keinen Streaminganbieter genannt.

Ich will ja eigentlich nur, dass mir der Streamingdienstanbieter immer 
das gleiche Angebot zeigt und da auch nichts gesperrt ist, ganz egal wo 
auf der Welt ich mich gerade befinde. :)

von Michael W. (dbru61)


Lesenswert?

Johannes schrieb:
> ...
> Was wäre denn dafür geeignete Hardware?
> - ~2-3 Leute gleichzeitig (maximal)
> - Eher seltener Zugriff (also nicht täglich und dauerhaft)
> - Zugriff um Fotos/ Videos runterzuladen (die auf dem NAS sind)
> - Zugriff auf einem Raspberry Pi
>
Um mal auf Deine Frage zu antworten:

Raspberry PI, einfach, billig, im Augenblick schwierig zu bekommen und 
nur eine Netzwerkschnittstelle. Ausgemusterten PC mit 2 
Netzwerkschnittstellen, billig, braucht aber u.U. mehr Strom. Mini-PC 
Barebone z.B. Gigabyte Brix oder ähnlich, gibts bei Ebay-Kleinanzeigen 
en Masse, evtl. auch mit 2 x LAN.
Als OS Opnsense, kann alle VPN-Arten und auch sonst eigentlich alles was 
man sonst noch so braucht, läuft stabil und wird weiterentwickelt.

viel Erfolg

von Peter M. (Gast)


Lesenswert?

Nano schrieb:
> Ich habe ja keinen Streaminganbieter genannt.
>
> Ich will ja eigentlich nur, dass mir der Streamingdienstanbieter immer
> das gleiche Angebot zeigt und da auch nichts gesperrt ist, ganz egal wo
> auf der Welt ich mich gerade befinde. :)

Genau das ist die Krux bei Netflu. Trotz valider Daten, bekommt man im 
Ausland nicht die Auswahl angezeigt wie im Heimatland (Vertragsland).
Ich kenne diese Problematik von einem videosüchtigen Bekannten. Der 
bekommt jedes Mal die Krise, dass er in Südamerika nur die 
spanischen/portugiesischen Kanäle angezeigt bekommt.
Für manche ist Netflu wie eine Droge.

von Rene K. (xdraconix)


Lesenswert?

Nano schrieb:
> Ich will ja eigentlich nur, dass mir der Streamingdienstanbieter immer
> das gleiche Angebot zeigt und da auch nichts gesperrt ist, ganz egal wo
> auf der Welt ich mich gerade befinde. :)

Sagt er in Zeiten, in denen Netflix nun Accountsharing aussperrt. :-D

Ich gehe mal von folgendem Bild aus:

Router1 - Netflix Hauptaccount in München
Router2 - Netflix Gucker in Hamburg
Router3 - Netflix Gucker in Frankfurt


Du kannst selbstverständlich eine VPN, und da ist es erstmal egal ob 
IPSec, oVPN oder WG. So einstellen (und das müsstest du in diesem Fall) 
das sämtlicher Traffic von Router2 und 3 über Router1 ins Netz läuft - 
damit Netflix die öffentliche IP des Router1 sieht. Problem ist: Es 
läuft dann natürlich wirklich jeder Verkehr (nicht nur Netflix) über 
Router1.

Ich z.b. habe zu Hause eine 25MBit Leitung, Netflix reizt diese 
eigentlich schon gut aus bei FullHD - Wenn aber nun auch nun noch der 
Internetverkehr meines Onkels aus Frankfurt und meiner Nicht aus Hamburg 
über meine 25Mbit läuft... Dann würde mir spätestens dann wenn meine 
Frau nebenbei in Instagram surfen will, eben diese den Kopf umdrehen 
weil MEINE Leitungskapazität an Router1 (Upstream zu Router2 und 
Router3) völlig in die Knie geht.

Ganz ehrlich: Tut euch (du, dein Onkel, deine Nichte) den Gefallen und 
zahlt halt eben die 3,50€ mehr im Monat damit alle, von ihrem Standort 
aus über einen Account schauen können ohne deine ganze Leitung zu 
blockieren.

Netflix macht dies eben nicht ganz ohne Grund.


EDIT:
Peter M. schrieb:
> Ich kenne diese Problematik von einem videosüchtigen Bekannten.

Kann ich nicht bestätigen, und ich bin beruflich sehr viel im Ausland 
unterwegs - Netflix bleibt immer auf deutsch und ich habe immer meine 
"Vorschläge".

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Problem ist: Es
> läuft dann natürlich wirklich jeder Verkehr (nicht nur Netflix) über
> Router1.

Das liesse sich über selektives Routing in den Griff kriegen. Aber wie 
er schon feststellte, vielleicht nicht per Fritz-VPN.

Der Haken ist, dass der Netflix-Client mehr von Gerät und Netz zur 
Analyse nutzen könnte, als die IP-Adresse des letzten Routers ins 
Internet. Beispielsweise die lokale IP-Adresse des Clients vor allem 
NAT/VPN-Gesumse. Würde ich jedenfalls in deren Situation so machen, weil 
in der gängigsten VPN Konfiguration alle solchen Clients in 
verschiedenen IP-Netzen liegen.

Ausserdem ist gerade seine angepeilte Situation, in der der normale 
Traffic in Hamburg ins Netz geht, aber der Netflix-Traffic in München, 
leicht rauszufinden.

: Bearbeitet durch User
von Jürgen (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Beispielsweise die lokale IP-Adresse des Clients vor allem
> NAT/VPN-Gesumse
Bei meinem Wireguard-Setup bekommt der Client eine IP aus meinem lokalem 
Netz auf dem genutzten Interface.

(prx) A. K. schrieb:
> Würde ich jedenfalls in deren Situation so machen, weil
> in der gängigsten VPN Konfiguration alle solchen Clients in
> verschiedenen IP-Netzen liegen.
Nein, die liegen alle in meinem Netz. Daß sie zusätzlich noch andere IPs 
auf anderen Interfaces haben ist egal

(prx) A. K. schrieb:
> Ausserdem ist gerade seine angepeilte Situation, in der der normale
> Traffic in Hamburg ins Netz geht, aber der Netflix-Traffic in München,
> leicht rauszufinden.

Wie?

von (prx) A. K. (prx)


Lesenswert?

Jürgen schrieb:
> Bei meinem Wireguard-Setup bekommt der Client eine IP aus meinem lokalem
> Netz auf dem genutzten Interface.

Eben. Und bei VPNs ohne NAT-Gewürge handelt es sich in München, Hamburg 
und Frankfurt um verschiedene IP-Netze (L3-VPN zwischen gleichen Netzen 
geht nicht), die dank des Routings über München alle über die gleiche 
Internet-IP aufschlagen. In Privathaushalten ist das unüblich, mithin 
verdächtig.

> Nein, die liegen alle in meinem Netz. Daß sie zusätzlich noch andere IPs
> auf anderen Interfaces haben ist egal

Wenn der Client die lokale IP als Teil einer nicht für die Kommunikation 
genutzten Kundenidentifikation mitschickt, ist es nicht mehr egal.

> Wie?

Mittendrin im Vergnügen einen unverdächtigen Kontrollzugriff mit 
Session-ID auf einen anderen Server durchführen, vorzugsweise über einen 
DNS-Eintrag, der verschiedene Adressen auswirft. Der kommt entsprechend 
der Vorgabe dann nicht aus dem München zur Session-ID, sondern aus 
Frankfurt oder Hamburg. Klares Indiz für Beschiss.

: Bearbeitet durch User
von Jürgen (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Wenn der Client die lokale IP als Teil einer nicht für die Kommunikation
> genutzten Kundenidentifikation mitschickt, ist es nicht mehr egal.

Welche? Mein Notebook für unterwegs hat  2x Lan, WLan, diverse VM-Net 
...

Aber egal, ich hatte überlesen, daß Du nur den Stream über das VPN 
schicken willst.

von (prx) A. K. (prx)


Lesenswert?

Jürgen schrieb:
> Welche? Mein Notebook für unterwegs hat  2x Lan, WLan, diverse VM-Net

Eben. Lauter verschiedene lokale IP-Netze, aber dank VPN haben alle User 
mit oder ohne Laptop immer die gleiche Internet-Adresse. Gleichzeitig.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

Rene K. schrieb:
> Problem ist: Es
> läuft dann natürlich wirklich jeder Verkehr (nicht nur Netflix) über
> Router1.

Deswegen dachte ich an eine Virtual Maschine für den Clienten, der sich 
mit dem Streaminganbieter über VPN verbinden soll.
Dann kann ich die VM von LAN des Router 2 abschotten und den kompletten 
Traffic der VM über das VPN direkt zu Router 1 leiten. Innerhalb des 
Gastsystem läuft dann alles über VPN und auf dem Hostsystem kann man 
dann normal surfen.

Ob man aber innerhalb einer VM problemlos Streamingvideos angucken kann, 
das wäre die andere Frage. Eventuell ist eine dedizierte GPU notwendig.


> Wenn aber nun auch nun noch der
> Internetverkehr meines Onkels aus Frankfurt und meiner Nicht aus Hamburg
> über meine 25Mbit läuft...

Sowohl der Anschluss von Router 1, als auch 2 ist meiner.
Lediglich bei Router 1 nutzen ihn auch noch andere, das kann ich aber 
notfalls auch über Quotas regeln.
Upload ist allerdings, wenn ich mich richtig erinnere mit 10 MBit/s 
recht eingeschränkt.
Aber ist es nicht so, dass neuere Videocodes wie AV1 drastisch weniger 
Bandbreite benötigen. Das ist ja heutzutage meist nicht mehr H.264.


> EDIT:
> Peter M. schrieb:
>> Ich kenne diese Problematik von einem videosüchtigen Bekannten.
>
> Kann ich nicht bestätigen, und ich bin beruflich sehr viel im Ausland
> unterwegs - Netflix bleibt immer auf deutsch und ich habe immer meine
> "Vorschläge".

Also zumindest in Russland kannst du seit den Sanktionen kein Netflix 
mehr empfangen. Das hat mir zumindest ein Russe auf Youtube erzählt.

von Nano (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Der Haken ist, dass der Netflix-Client mehr von Gerät und Netz zur
> Analyse nutzen könnte, als die IP-Adresse des letzten Routers ins
> Internet. Beispielsweise die lokale IP-Adresse des Clients vor allem
> NAT/VPN-Gesumse. Würde ich jedenfalls in deren Situation so machen, weil
> in der gängigsten VPN Konfiguration alle solchen Clients in
> verschiedenen IP-Netzen liegen.

Ich könnte auch alle lokalen Streaming Clients über den VPN schicken.
Dann sieht's für jeden Streamingclient gleich aus.


> Ausserdem ist gerade seine angepeilte Situation, in der der normale
> Traffic in Hamburg ins Netz geht, aber der Netflix-Traffic in München,
> leicht rauszufinden.

Das sieht der ISP, aber der Streamingdienstanbieter dürfte hier blind 
sein.

von Nano (Gast)


Lesenswert?

(prx) A. K. schrieb:
>> Nein, die liegen alle in meinem Netz. Daß sie zusätzlich noch andere IPs
>> auf anderen Interfaces haben ist egal
>
> Wenn der Client die lokale IP als Teil einer nicht für die Kommunikation
> genutzten Kundenidentifikation mitschickt, ist es nicht mehr egal.

Wenn man den Client in eine VM packt, dann hat er keine IP von Router 2 
oder 3, weil er die dann nicht sieht. Er sieht dann nur die von Router 
1.

Verdächtiger sind da meiner Meinung nach eher die Laufzeiten.
Wenn es bei einem lokalen Client von Router 1 weniger als 10 ms für eine 
Rückmeldung dauert und bei dem Client im Netz von Router 2 60 ms sind, 
dann ist das schon eher verdächtig.


>> Wie?
>
> Mittendrin im Vergnügen einen unverdächtigen Kontrollzugriff mit
> Session-ID auf einen anderen Server durchführen, vorzugsweise über einen
> DNS-Eintrag, der verschiedene Adressen auswirft. Der kommt entsprechend
> der Vorgabe dann nicht aus dem München zur Session-ID, sondern aus
> Frankfurt oder Hamburg. Klares Indiz für Beschiss.

Dann muss der Client zwingen in die VM gepackt werden.

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Er sieht dann nur die von Router 1.

Je nachdem, wie man die VM netzwerkseitig anbindet. Bridging, NAT, ...

von Rene K. (xdraconix)


Lesenswert?

Nano schrieb:
> Upload ist allerdings, wenn ich mich richtig erinnere mit 10 MBit/s
> recht eingeschränkt.

Richtig, Netflix braucht bei HD ca. 5MBit an reiner Datenrate. Mit Req, 
FC in einer VPN wird ein Client bei HD ca. 8Mbit über dein Router1 
ziehen.

Ganz ehrlich, wenn man sich den Umstand anschaut den du da vor hast, 
welches eh nur halbherzig funktioniert. (Netflix über ne VM - ich schau 
Netflix auf'n TV!) Ganz ehrlich... Investiert die 3€ in einen 
offiziellen Sharing-Account - alles funktioniert wie bisher, jeder hat 
seinen User, alles legal und Netflix kann keine Hintertürchen zu machen.

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Dann muss der Client zwingen in die VM gepackt werden.

Wobei man einen geeigneten VPN-Client gleich mit in die VM tun kann.

von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Ganz ehrlich, wenn man sich den Umstand anschaut den du da vor hast

Ob das unter "Um jeden Preis Geld sparen" fällt? Oder um die 
Befriedigung, dem Anbieter ein Schippchen zu schlagen, koste es was es 
wolle?

von Nano (Gast)


Lesenswert?

Rene K. schrieb:
> Ganz ehrlich, wenn man sich den Umstand anschaut den du da vor hast,
> welches eh nur halbherzig funktioniert. (Netflix über ne VM - ich schau
> Netflix auf'n TV!)

Der PC hängt am TV. :)
Das ist für mich viel bequemer als mit bspw. einem Amazon Firestick, 
weil man dann gleich mit Wireless Maus und Tastatur im Internet mal 
schnell was suchen kann, wenn man etwas wissen will. Der TV ist somit 
der Bildschirm.

> Ganz ehrlich... Investiert die 3€ in einen
> offiziellen Sharing-Account - alles funktioniert wie bisher, jeder hat
> seinen User, alles legal und Netflix kann keine Hintertürchen zu machen.

Mir ist nicht bekannt, dass es so ein offiziellen Sharing Account gibt.
Und auf der Webseite steht dazu auch nichts:

https://help.netflix.com/de/node/24926
https://help.netflix.com/de/node/123277

von Rene K. (xdraconix)


Lesenswert?

Nano schrieb:
> Mir ist nicht bekannt, dass es so ein offiziellen Sharing Account gibt.
> Und auf der Webseite steht dazu auch nichts:

Die neuen Tarife kommen ja auch erst im neuen Jahr.

Nano schrieb:
> Das ist für mich viel bequemer als mit bspw. einem Amazon Firestick,
> weil man dann gleich mit Wireless Maus und Tastatur im Internet mal
> schnell was suchen kann, wenn man etwas wissen will. Der TV ist somit
> der Bildschirm.

Okay, unsereins schaut TV noch wirklich am TV. Es gibt ja mittlerweile 
seit gut 12 Jahren SmartTVs - da ist das alles dabei: Netflix, FireTV, 
Waipu... Was halt so kreucht und fleucht. In unserem Haus gibt es 
überhaupt kein Antennen- oder Sat- oder WasAuchImmer-Anschluss.

von Nano (Gast)


Lesenswert?

Rene K. schrieb:
> Okay, unsereins schaut TV noch wirklich am TV.

Ich eigentlich nicht mehr. Da muss schon das Internet ausfallen, damit 
ich das tue. Der TV ist nur noch ein großer Bildschirm.

> Es gibt ja mittlerweile
> seit gut 12 Jahren SmartTVs - da ist das alles dabei: Netflix, FireTV,
> Waipu... Was halt so kreucht und fleucht.

Ich weiß, einen FireTV Stick habe ich für meine Mutter, der ist einfach 
zu bedienen und hat mehr Leistung als der SmartTV und kriegt auch noch 
Updates, aber ich nutze nichtmal die SmartTV Funktion meines TV, weil 
ein PC schlichtweg viel flexibler ist.

Das einzige störende am PC ist eigentlich nur, dass ich zum Netflix 
gucken in FullHD Windows booten und den Edge Browser nutzen muss.
Denn unter Linux gibt's nur 720p.
Ja, man kann da mit irgendwelchen dubiosen Plugins doch noch FullHD 
bekommen, aber das ist mir zu viel Gefummel und wegen dem Fingerprinting 
nicht gut genug, da boote ich lieber einfach neu und Dualbooter bin ich 
ohnehin. Unter Windows sind die Games installiert.

von Nano (Gast)


Lesenswert?

Rene K. schrieb:
> Nano schrieb:
>> Mir ist nicht bekannt, dass es so ein offiziellen Sharing Account gibt.
>> Und auf der Webseite steht dazu auch nichts:
>
> Die neuen Tarife kommen ja auch erst im neuen Jahr.

Gut zu wissen. Ich werde mir das dann mal ansehen.
Eventuell Premium Account kündigen und den Standardtarif + Sharing 
Account verwenden, sofern das angeboten wird. FullHD reicht.

von Uwe B. (uwebre)


Lesenswert?

Michael W. schrieb:
> Raspberry PI, einfach, billig, im Augenblick schwierig zu bekommen und
> nur eine Netzwerkschnittstelle

Die ideale Plattform:
Beitrag "[V] Banana Pi R1 Router mit Alugehäuse und Antennen"

Uwe

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.