Thralas schreef op woensdag 7 december 2016 @ 19:35:
[...]
Met alles eens, behalve dit stuk.
Je wilt helemaal niet bridgen; er is ook geen enkele use case voor VPN providers om dat te ondersteunen.
Wat je wel zult moeten doen is een aparte routetabel hanteren voor de SSIDs in kwestie. Dat gaat inderdaad niet lukken zonder 'geavanceerde router' (OpenWRT, MikroTik..)
[...]
Belangrijkere vraag: waarom? Want volgens mij snap je niet wat een 'scrambling' patch inhoudt. Nu ben ik niet in detail bekend met de desbetreffende provider, maar die term wordt in de Tor-wereld gebruikt voor obfuscatie van je VPN-tunnel.
Dat is handig als je in China zit en men OpenVPN (het protocol) actief probeert te blokkeren, in jouw geval heeft het geen énkel nut. Wat het bovenal niet doet is je verkeer voor Netflix 'verstoppen'; zij zien uberhaupt enkel verkeer pas vanaf het eindpunt van je tunnel, en in het geval van een commerciële VPN-provider is er een redelijke kans dat zij het IP-adres ook kennen als VPN-dienst.
[...]
Ik kan me voorstellen dat Netflix OVH ook op de blacklist heeft staan. Veel te goedkope hosting, no brainer voor al die VPN-providers om daar ook een node neer te zetten.
Het beste is om een VPS'je te nemen in een kleine onbekende IP-reeks, dan weet je zeker dat hij niet geblacklist is.
Het ging ook niet zozeer om het 'waarom' van de scrambling patch, maar meer om het feit dat Vypr VPN dat gebruikt en je aan beide kanten zal moeten matchen, wil je een verbinding tot stand kunnen brengen.
Probleem is dat er meerdere verschillende methodes zijn en dus ook verschillende patches die je kan toepassen op een OpenVPN build. En dan moet je maar hopen dat dat de correcte is om te connecten met Vypr.
Voor hetzelfde geld hebben ze hun eigen versie van zo'n patch gemaakt. En dan kan je het wel schudden.
Eitherway, in geen van beide gevallen krijg je dat in de gemiddelde router gepropt, zonder flink werk te verzetten. DDWRT/OpenWRT en dergelijke opensource firmwares zijn uiteraard prima te verbouwen, maar de vraag is of je dat wil gezien de hoeveelheid werk en kennis die daar in gaat zitten.
Anderzeids is het voor de OP voldoende om een doodsimpel, totaal unencrypted PPTP tunneltje neer te leggen.
Het is niet alsof Netflix tussen NL en USA monitort wat er over de lijn vliegt, en dus hebben ze ook geen weet van het feit dat hij een tussenstop maakt via een VPN server. Zolang het maar lijkt alsof hij in de USA zit, dan is het al lang prima. Scrambling en zware encryptie zijn absoluut zinloos voor deze use-case.
En dat is dan ook meteen wat de OP totaal lijkt te hebben gemist. Als een VPN server niet in het land van bestemming staat, dan heb je er gewoon niets aan. Het gaat niet om het anonimiseren, maar om het verplaatsen van de plek waar jouw traffic het web op gaat.
Dát is, for all intents and purposes, jouw GeoIP lokatie en daarop baseert een dienst als Netflix (of de BBC iPlayer, of wat dan ook voor geoblocked videodienst) wat jouw lokatie is.
Wat betreft het bridgen ben ik het niet volledig met je eens.
Als je meerdere clients aan 1 verbinding hangt, waarbij je een accesspoint direct aan een VPN connectie knoopt, zullen die meerdere clients ook allemaal een eigen IP willen opvragen en zullen allen een eigen MAC-adres hebben. Dat wordt vaak geblokkeerd, maar is wel handig om te kunnen.
En ja, je kan natuurlijk nog weer een laagje NAT er tussen drukken. Dan heb je dat probleem waarschijnlijk al niet meer, maar voegt wel weer een extra laag complexiteit toe.
Het is al veel gevraagd voor de meeste apparaten om uberhaupt VPN aan een apparte LAN poort te knopen, laat staan dat daar dan ook meteen weer even een laagje NAT aan vast zit.
Niet dat een eigen VPN server ergens neer dumpen ook maar op enige wijze simpeler is, maar dat terzeide
:fill(white):strip_exif()/i/1381324421.jpeg?f=thumbmini)
:strip_icc():strip_exif()/u/50085/reaperavatar.jpg?f=community){kind=avatar}