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)
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
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
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
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).
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.
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.
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
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
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.
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?
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
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
(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.
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
(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
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. ;-)
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. :)
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
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.
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
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
(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?
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
(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.
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
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.
(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.
(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.
Nano schrieb: > Er sieht dann nur die von Router 1. Je nachdem, wie man die VM netzwerkseitig anbindet. Bridging, NAT, ...
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.
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.
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?
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
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.