Ačkoliv jsem práci jenom proletěl a nehodlám ji studovat, je celkem na první pohled zřejmé, že porovnáním časů dopředné (ping, traceroute, ...) a zpětné (aplikace běžící v browseru) latence lze poměrně jednoduše určit významný rozdíl, ke kterému v případě VPN dojde.
A protože v browseru vám běží netflix klient, lze měřit poměrně jednoduše. Výsledky pak můžete prohnat nějakou neuronovou sítí (netflix má dost uživatelů) a významné odchylky začnete sledovat. Pokud se neobjeví nějaká fatální chyba návrhu, po odladění dosáhnete přesnosti přes 99.9%. Po zbylé desetině procenta budete chtít ověření země původu (třeba přihlášením se přes mobilní telefon).
V článku jsem zahlédl zmínku o možnostech mid boxů, které by mohly falšovat časové značky, umím si představit nástroje, které tomu zabrání (šifrovaný zpětný kanál).
..ano chytraku tu je vazne dost, hlavne tech co jen "letaji"..
u vpn zadny rozdil latence mezi pingem a aplikaci nebude (vse bezi pres vpn) ;) rozdil bude u asynchronnich linek protoze ping nezjisti rozdil mezi cestou tam a zpatky kdezto ten jejich protokol ano
takze jestli jsem pripojenej k nejakemu johnovi novakovi z texasu vpnkou z evropy nebo nejakou pomalou potrubni postou lokalne, to nezjisti, ale u nekoho kdo je pripojenej pres saturovane xDSL, to oproti pingu vrati rychlejsi odezvu a tim ho spolehliveji lokalizuje bliz arbitrum nez ping (kde se RTT pocita jako pulka casu odezvy)
> u vpn zadny rozdil latence mezi pingem a aplikaci nebude (vse bezi pres vpn)
Bude.
VPN: Když server pingne uživatele, odpoví mu u VPN endpoint, který u Netflixu je nejspíš v USA. Když uživatel pingne server, počítá se cesta i od uživatele k endpointu. Tj. USA-USA, vs. USA-Evropa.
NeVPN: Když server pingne uživatele, odpoví mu uživatelův NAT nebo v nejhorším CG NAT. Pokud mezi CG NATem a uživatelem není zalagovaná mikrovlnka, bude tato latence skoro stejná, jako při měření celé cesty.