Hversu auðvelt er að greina VPN er notað?

Raunveruleg einkanet (VPN) leysa mikið af persónuverndarvandamálum. Þar sem VPN dulritar venjulega umferðina þína á milli tölvunnar þinnar og VPN veitunnar, gerir það mjög erfitt fyrir áhorfandann að skoða umferðina þína til að sjá hvað þú ert að gera. Hins vegar eru margir sem vilja geta leynt því að þeir nota VPN yfirleitt; svo sem fólk í löndum sem banna VPN eða aðrar aðstæður þar sem VPN notkun er almennt ekki leyfð eða lokuð með tæknilegum hætti. Í þessari grein leggjum við áherslu á þá gerð gagna sem áheyrnarfulltrúi getur safnað úr netpakkatökum og hvernig hægt er að nota þau gögn til að greina VPN notkun.


Bakgrunnur vandans

Brennandi spurningin er „af hverju“? Hverjum er sama hvort einhver uppgötvar að þú ert að keyra VPN? Ef umferðin er dulkóðuð einhvern veginn, hver er vandamálið?

Það er rétt að í mörgum aðstæðum og í mörgum löndum skiptir það engu máli hvort áheyrnarfulltrúi skynjar notkun VPN. Hins vegar eru mörg lönd sem banna notkun VPN og því er mikilvægt fyrir VPN notendur í þessum löndum að vita hvernig hægt er að uppgötva þau.

Til að ákvarða hvort VPN er í notkun þarf áheyrnarfulltrúi að hafa aðgang að leið þar sem markaumferðin liggur í gegnum. Ef um er að ræða markvænan fórnarlamb getur árásarmaður eytt miklum fjármunum til að bera kennsl á leið til að taka yfir leið sem viðkomandi fórnarlamb notar. Þegar um er að ræða eftirlit með þjóðríkjum myndi skilvirk uppgötvun krefjast stjórnunar á mörgum leiðum. Þegar þú sameinar þetta tvennt – stofnun sem er sama hvort þú ert að nota og VPN og einnig hefur getu til að stjórna miklum fjölda beina — það bendir venjulega til ógnunarleikara á þjóðinni.

Hafðu í huga að þessi grein fjallar um leiðir sem hægt er að uppgötva notkun VPN af eftirlitsmönnum. Það þýðir ekki endilega að auðveldara sé að nýta gögnin sem eru dulkóðuð í VPN göngunum.

Aðferðafræði prófa

Án aðgangs að auðlindum á vegum ríkisins er prófunarvettvangur minn og aðferðafræði aðeins minni að stærð. Ég bjó til lítið innra net með þremur sýndarvélum (VM) með VirtualBox. Grannfræði netsins er sem slík:

Uppsetning VPN prófanets

Ég setti upp pakkaþefunarhugbúnað á OpenWRT router VM og prófaði síðan ýmsar VPN stillingar á hinum tveimur sýndarvélunum. Pakkinn þefandi hugbúnaður, tcpdump, gerði mér kleift að fanga netumferðar VM til greiningar. Í raunsærri uppsetningu væri pakkatökuhugbúnaðurinn líklega settur upp í beinar á Netinu, eða að minnsta kosti innan net ISP. Stefnumótun staðsetningar greiningarhugbúnaðar krefst nokkurrar þekkingar á samleitni áhugaverðra staða á internetinu þar sem líklegt er að markaumferðin streymi. Í prófanetinu mínu veit ég með 100% vissu að öll umferðin til og frá sýndarvélarnar mínar mun fara í gegnum þessi OpenWRT leið. Það er því besti staðurinn fyrir mig að setja söfnunartólin mín.

Ótæknilegar heimildir um VPN vísa

Ekki eru allar heimildir sem benda til VPN-notkunar tæknilegar. Þó að sumar séu mjög tæknilegar, svo sem greiningar á pakka, eru sumar mjög tæknilegar, svo sem mannleg mistök og dagleg venja.

Ósjálfrátt netumferð

Flestir VPN notendur eru með viðskiptavinshugbúnað sem verður að koma af stað til að VPN-kerfið verði komið á. Það er mjög erfitt að tryggja að engin umferð fari yfir netið áður en VPN er komið á þegar tölva ræsist upp. Jafnvel þessir VPN-tengingar með dreifingarrofa kunna ekki að geta gert neitt í umferðinni sem líður meðan kerfisopnun stendur.

vypr-vpn-autoconnect-mode

vypr-vpn-killswitch-mode

Til að prófa þetta, setti ég sjálfvirka tengingu og drepir valkosti VyprVPN í sýndarvél Windows. Ég lagði síðan niður Windows vélina, byrjaði að taka pakka á OpenWRT leiðinni og byrjaði Windows vélina. Það skilaði miklum pakka og áhugaverðar eru þessar tvær raðir.

Í fyrsta lagi getum við séð mikið af smellum á svipaðan fjölda IP-tækja. Ég hópaði ekki þessum pakka með ásetningi – svona voru þeir sendir lífrænt:

vypr-vpn-windows-boot-ICMP-pakka

Þetta bendir til þess að eitthvað sé að reyna að telja upp netþjóna. Mjög algeng orsök þessarar umferðar í VPN atburðarás er VPN viðskiptavinur sem reynir að ákvarða hraðasta netþjóninn. Ein aðferð til að gera þetta er að senda ICMP pakka (þekktur sem ping) til a setja af netþjónum til að sjá hver kemur fljótast til baka.

Við sjáum frá fyrsta skjámyndinni að 209.99.63.34 skilaði hraðskreiðustu á 99 millisekúndum. Lengra niður í pakkatöku, sjáum við skyndilega að mest af umferðinni frá þeim tímapunkti er dulkóðuð og er víst fyrir 209.99.63.34

vypr-vpn-windows-boot-QUIC-pakka

Næsta stykki þrautarinnar er að komast að því hvað er á þessum IP-tölum. Notkun IP WHOIS sem segir skráða eiganda IP, getum við séð að allir nema einn af þessum IP-tölum tilheyra YHC Corporation og leysa til netþjóna í Data Foundry gagnaverinu:

209.99.108.46
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.109.167
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.113.70
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209-99-115-97
209.99.117.82
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.21.36
OrgName: YHC Corporation
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209.99.22.46
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.60.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.61.42
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.62.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
OrgName: Powerhouse Management, Inc.
OrgTechEmail: [email protected]
209.99.63.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.63.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.67.41
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.72.70
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.75,70
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.93.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.94.37
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.95.40
OrgName: YHC Corporation
OrgTechEmail: [email protected]

Rökrétt næsta skref væri að skanna þessar IP-tölur til að sjá hvaða þjónustu þeir eru að keyra. Ég mun ekki láta í té upplýsingar um hvernig á að gera það, en prófanir mínar sýna að sjálfgefnu tengibannarnir sem flestir netþjónar sýna hafa verið fjarlægðir af VyprVPN netþjónum svo það er ekkert augljóst að þessi IP-tölur keyra VPN netþjón.

Það er ekki mikið sem þú getur gert í því hvernig tölvan þín virkar áður en hún er ræst. Þess vegna þarftu að keyra VPN „fyrir framan“ tölvunnar ef þú vilt fela í sér þessa uppsetningarröð. Að keyra VPN viðskiptavininn á routernum þínum í stað þess að keyra viðskiptavin á tölvunni þinni er ein leið til að gera þetta. Þú munt samt keyra í sömu ræsingarröð þegar leiðin endurræsir, en það er venjulega sjaldnar en tölvan þín.

Engin dulkóðaðar pakka

Eins og ég gat um hér að ofan, þegar pings var lokið sýnir pakkafangan dulkóðuð umferð á hraðasta IP. Ef áhorfandi sér aðeins dulkóðuð pakka og ekki einn ódulkóðaðan pakka, þá getur það verið merki um að VPN sé í notkun. Þó heimurinn gangi hratt í átt að dulkóðun eins mikils gagna og mögulegt er á vefnum, eru ennþá nokkrar beiðnir sem yfirleitt eru ekki dulkóðaðar. Meðal þeirra eru fyrirspurnir um DNS-leit, NNTP (tímamiðlara) fyrirspurnir og smattering af öðrum beiðnum um siðareglur eins og FTP og Telnet sem eru stundum í notkun í sumum forritum okkar en styðja alls ekki dulkóðun.

Leki vegna slæps mannlegs öryggisöryggis (OpSec)

Hægt er að fá mikið af þýðingarmiklum gögnum frá markmiði með því að nota að því er virðist léttvægar upplýsingar. Margir eyða miklum tíma og fyrirhöfn í að draga úr því sem þeir líta á sem „mikilvægu“ efnið aðeins til að bera kennsl á léttvægar upplýsingar sem þeim datt ekki í hug. Nokkur dæmi eru um langa minningu internetsins sem leiddi í ljós að tölvupóststjóri Hillary Clinton var líklega gaur að nafni Paul Combetta; Ótti sjóræningi Roberts, AKA Ross Ulbricht, meintur hugarheimur hinnar ólöglegu markaðstorgs Silk Road, var ákærður að miklu leyti vegna gagna um fartölvuna hans sem voru líkamlega tekin frá honum meðan hann var annars hugar á almenningsbókasafni.

Minna verulega geta áheyrnarfulltrúar oft notað hluti eins og virkni hringrásar til að festa tímabelti miða eða tilvist sérstaka stafa í skilaboðum til að bera kennsl á tungumálaskipulag sem samsvarar landi markmiðs. Það er enginn tæmandi listi yfir það sem þarf að taka tillit til þegar rekstraröryggi er íhugað því að koma með nýjar leiðir til að vísa til gagna er aðallega æfing í hugmyndaauðgi og úrræðum.

Það eru þó nokkur sérstök atriði sem lúta að pakkatöku sem geta borið kennsl á VPN notkun.

Segja má merki frá lýsigögnum um pakka

PFS endurlyklar eru fyrirsjáanlegir

Þar sem VPN-umferð er venjulega dulkóðuð er hún almennt falin fyrir hnýsinn augum. Dulkóðun virkar vegna þess að það er mjög erfitt að „brute force“ dulkóðuð gögn til að afhjúpa skýrt textainnihald þeirra. Reyndar er að brjóta dulkóðun svo erfitt að eftirlitsverkefni í stórum stíl safna stundum bara öllum gögnum sem þeir geta í von um að þeim takist að brjóta dulkóðunina á einhverjum framtíðardegi þegar tölvuafl eykst, eða þeir geta fengið lyklana sem voru notuð til að dulkóða gögnin. Perfect Forward Secrecy (PFS) er aðferð sem hægt er að nota til að koma í veg fyrir síðarnefndu atburðarás.

Perfect Forward Secrecy býr til dulkóðunarlyklana sem notaðir eru til að dulkóða VPN-umferð reglulega. Þegar nýtt lykilpöru er búið til er fyrra pari eytt. Þetta þýðir að ekki er hægt að afkóða dulkóðaða pakka sem safnað er síðar á þeim tíma vegna þess að lykillinn sem er notaður til að dulkóða þá er ekki lengur til.

OpenVPN styður PFS. Þegar ég var að safna gögnum fyrir þessa grein lækkaði ég hjólreiðatíðni niður í 10 sekúndur til að ná því ferli sem fer fram. Ég komst að því að þegar lykil endurnýjun átti sér stað, myndaðist eftirfarandi röð pakka:

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 94
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 86
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 94
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 94
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 94
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 94
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 94
09: 01: 59.062927 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, lengd 575

Það athyglisverða við þessa röð er að pakkastærðirnar eru eins í hvert skipti sem lykill endurnýjun átti sér stað. Þess vegna, þegar ég sá röð af pakka með þessum stærðum í pakkatöku mínum, vissi ég að lykilhjólreiðar væru að eiga sér stað:

94
65
86
94
259
94
94
94
94
256. mál
575. mál

Sannarlega myndi öll endurtekningaferli fræðilega búa til endurtekna röð af pakka sem þessum, en það er samt hægt að nota sem vísbendingu um að PFS gæti verið í leik. Í tengslum við önnur gögn gætu þessar upplýsingar verið nóg til að staðfesta VPN tengingu.

Allir pakkar sem eru ætlaðir á sama IP

Við venjulega notkun internetsins óskar fólk og tölvur eftir gögnum frá mörgum mismunandi stöðum. Hver þessara vefsvæða hefur mismunandi IP-tölu. Þegar VPN er notað er hvert einasta pakki víst á VPN netþjóninn. VPN netþjónninn flettir upp VPN dulkóðunarlaginu af hverjum pakka til að afhjúpa raunverulegan pakka og sendir hann síðan á leið á raunverulegan ákvörðunarstað. VPN netþjónninn gerir það sama með svörum. Það fær svarpakka, umbúðir í dulkóðunarlagi og sendir síðan pakkann í tölvu notandans.

Pakkaupptaka sem sýnir tölvu sem sendir 100% af umferð sinni á eina IP er góð vísbending um að VPN eða umboð séu í notkun.

Psiphon er sniðmát á Internet ritskoðun. Það hefur áhugaverða aðgerð sem getur barist gegn þessu að einhverju leyti. Það hefur skipt göngin háttur sem í raun notar aðeins Psiphon göngin fyrir umferð sem fer frá þínu eigin landi.

samanburðar-psiphon-splittunnel-ham

Til að sjá hvernig þetta lítur út á pakkastiginu setti ég af stað Psiphon og prófaði tvö vefsvæði. Ég er í Kanada og hér er sýnishorn af umferð sem er ætluð eigin .CA lénsritara. Í þessu tilfelli er ákvörðunarstaður minn greinilega sýnilegur í pakkatöku.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Fánar [.], ack 1026833, vinna 64240, lengd 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Fánar [.], Seq 1026833: 1028293, ack 715, win 5094, lengd 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Fánar [.], Seq 1028293: 1031213, ack 715, vinna 5094, lengd 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Fánar [.], ack 1031213, vinna 64240, lengd 0

Ég heimsótti síðan Comparitech vefsíðu sem hýst er í Bandaríkjunum:

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Fánar [P.], seq 107809: 108277, ack 19080, vinna 1392, lengd 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Fánar [.], ack 108277, vinna 856, lengd 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flags [P.], seq 19080: 19132, ack 108277, win 856, 52 lengd
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Fánar [.], Ack 19132, vinna 1392, lengd 0

Athugaðu hvernig umferðin sem er ætluð Bandaríkjunum er send til Linode netþjóns í staðinn til að comparitech.com. Linode er mjög stórt netþjónustufyrirtæki og það er alls ekki óeðlilegt að sjá umferð sem er ætluð Linode netþjóni. Psiphon skyggir enn frekar á þá umferð með því að nota SSH göng til að fela öll ummerki um VPN. Eins og hið gagnstæða DNS (rDNS) fyrir Psiphon netþjóninn á Linode svíkur ekki tengsl sín við Psiphon; rDNS sýnir bara að Linode á IP, sem búist er við. Það er meira um rDNS í niðurdregnum kafla síðar í þessari grein.

Ósamræmi í gögnum um stýrikerfi og fingrafarapakka

Þrátt fyrir að TCP net sé stýrikerfi agnostic skapa mismunandi stýrikerfi pakka með nokkrum mismunandi gildum. Til dæmis er sjálfgefið TTL-gildi pakkans mismunandi í pakka sem eru búin til á mismunandi kerfum. Flest Windows kerfið mun stilla pakkann TTL sjálfgefið á 128 en flest Linux kerfin stilla það á 64. Þar sem TTL er sýnilegur hluti af handtaka pakkanum er mögulegt að ákvarða hvaða stýrikerfi hefur líklega búið til þann pakka. Það eru einnig önnur segamerki í pakkagerð eins og lengd og hámarksstærð (MSS) sem eru einnig breytileg frá stýrikerfi til stýrikerfis.

Útdrátturinn hér að neðan er hluti af pakka sem er búinn til úr Windows kerfinu. Athugaðu ttl 127 gildi í síðustu línu er stillt á 127. Þetta er vegna þess að TTL er gefið upp í fjölda „humla“. Í hvert skipti sem pakki fer yfir tæki eins og leið er TTL þess valið af einum. Í þessu tilfelli byrjaði TTL á 128 en þar sem ég náði honum á leiðina – eftir eitt hopp – er það nú 127. Ég get samt sagt að það var aldrei 64 svo þetta er líklega pakki búinn til í Windows kerfi.

08: 08: 51,67495 IP (tos 0x0, ttl 64, id 32150, offset 0, fánar [DF], frumgerð UDP (17), lengd 177)
google-public-dns-a.google.com.domain > 192.168.2.139.59414: 40501 3/0/0 cdn-3.convertexperiments.com. CNAME cdn-3.convertexperiments.com.edgekey.net., Cdn-3.convertexperiments.com.edgekey.net. CNAME e5289.g.akamaiedge.net., E5289.g.akamaiedge.net. A 104.94.35.212 (149)
08: 08: 51,659278 IP (tos 0x0, ttl 127, id 3890, offset 0, fánar [DF], frumgerð TCP (6), lengd 52)

Pakki sem tekinn er úr Linux vél er með TTL 63 eftir fyrsta hoppið. Þetta er vegna þess að flestar Linux vélar stilla upphafsgildi pakkans TTL á 64.

08: 15: 55.913493 IP (tos 0x0, ttl 63, id 41443, offset 0, fánar [DF], frumgerð UDP (17), lengd 56)
192.168.2.139.48635 > resolver1.ihgip.net.domain: 47200+ A? google.com. (28)

En hvað svo? Af hverju getur verið mikilvægt að vita hvaða stýrikerfi bjó til pakka?

Ef áhorfandi hefur sérþekkingu á markmiði getur það skipt miklu. Ef vitað er að markmiðið notar Windows – kannski sem aðili að stórum samtökum sem notar Windows í gegn – en pakki sem teknir eru af því markmiði sýna að þeir voru líklega búnir til á Linux vél, þá er það góð vísbending um að VPN eða umboð einhverra góður er í notkun. Þess má geta að nánast allir VPN netþjónar eru keyrðir á Linux eða Unix-líkum netþjónum.

Það er hægt að aðlaga pakkagildin í flestum kerfum en mjög fáir fara í þessa lengd.

Ófullnægjandi aðdráttaraðferðir frá VPN veitendum

Það er meira til netgreiningar en bara að safna pakka. Aukaferli eins og DNS geta gegnt hlutverki. Margir VPN notendur eru meðvitaðir um DNS því að senda fyrirspurnir á skýran hátt er ein leið fyrir áheyrnarfulltrúa að ákvarða hvar þú ert að heimsækja eða er að fara að heimsækja. Hins vegar eru færri notendur meðvitaðir um Reverse DNS (rDNS). Svona eins og DNS tengir lén við IP tölu, rDNS tengir IP tölu við hýsingarheiti og hýsingarheitið auðkennir venjulega eiganda IP. Að auki eru flest forritunarbókasöfn og stýrikerfi með einhverja útgáfu af stöðluðu gethostnameby * () aðgerðum sem víkka möguleika kerfisins til að tengja IP og hostnames.

Reverse DNS er ekki eins mikilvægt og „venjulegt“ DNS vegna þess að rDNS á engan þátt í að beina umferðinni. Öllu heldur er það aðallega notað sem leið til að bera kennsl á eignarhald á IP. Aðeins eigandi IP-tölu getur tengt rDNS-skrá við það. Þess vegna, með því að haka við rDNS-skrá yfir IP-tölu, er sanngjarnt fullviss um hverjir eiga það, eða að minnsta kosti, hver eigandinn vill að þú haldir að hann eigi það. Athugaðu að rDNS er ekki krafist og mörg IP netföng hafa alls ekki rDNS færslur.

Við skulum líta á dæmið um lénið facebook.com. DNS-skráin sem gefin er upp með venjulegri DNS-fyrirspurn sýnir þetta IP-tölu:

$ dig + stutt facebook.com
31.13.67.35

Við skulum nota öfugan DNS-fyrirspurn eða gethostnamebyaddr () aðgerðina til að sjá hver á þann IP:

$ gestgjafi -n 31.13.67.35
35.67.13.31.in-addr.arpa lénsheiti bendill edge-star-mini-shv-01-mia3.facebook.com

Við getum séð af þessu að Facebook á í raun það IP-tölu. Hins vegar eiga flestar síður ekki eigin IP-tölu; þau eru leigð og tilheyra handahófskenndum samtökum eða kannski í eigu minna augljósra aðila. Amazon er dæmi um stóran tölvuaðila sem er notaður af mörgum fyrirtækjum. RDNS fyrirspurn um IP-tölu margra internetþjónustna sýnir einfaldlega að Amazon á IP og þess vegna eru upplýsingarnar lítið gagn við að ákvarða hver rekur IP. Annað dæmi er Google. Google er aðeins lúmskur í rDNS færslum sínum en það heldur samt upplýsingum um eignarhaldið. Svona lítur andstæða DNS út fyrir Google IP:

$ grafa + stutt google.com
216.58.207.46

$ gestgjafi -n 216.58.207.46
46.207.58.216.in-addr.arpa lénsmerki fra16s24-in-f14.1e100.net.

Google á 1e100.net lénið, þannig að við getum séð að þessi IP tilheyrir í raun Google.

Í heimi VPN, er mögulega hægt að nota tól til að leysa heimilisfang til að sjá hvort IP sem umferðinni er ætlað tilheyrir VPN. Til dæmis, sjálfgefin tcpdump skipun á OpenWRT leið mun reyna að leysa IP-tölurnar sem það sér í TCP-pökkunum. Það virðist fyrst og fremst nota gethostbydress () til að gera þetta og því er stundum hægt að sjá hvar pakkar eru ætlaðir. Sjálfgefin tcpdump handtaka IPVanish lotu sýnir þetta:

08: 23: 14.485768 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lengd 1441
08: 23: 14.485847 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lengd 1441
08: 23: 14.486144 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lengd 1441
08: 23: 14.486186 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, lengd 385

IPVanish viðskiptavinurinn fyrir Windows býður upp á þrjár stillingar: venjuleg OpenVPN tenging, OpenVPN tenging sem notar HTTPS og ruddaleg tenging.

ipvanish-vpn-openvpn-mode

Pakkarnir hér að ofan voru teknir á meðan á lotu stóð með því að nota huldu OpenVPN tengingarstillingu en samt er WireShark ennþá fær um að veita upplýsingar um ákvörðunarstað.

Í stuttu máli

Þegar VPN notkun er ákvörðuð eru mjög fáir „silfurskotar“. Það þarf venjulega nokkrar aðferðir eða athuganir til að safna saman nægum vísum sem benda til þess að VPN sé í notkun og jafnvel þá getur verið erfitt að vera 100% viss. Fyrirtæki sem hafa hagsmuni af því að ógilda notkun VPN eins og Netflix og önnur streymisþjónusta hafa teymi í fullu starfi sem einbeitt er að þessu vandamáli. Í öðrum tilvikum banna mörg Austur-Evrópu og Miðausturlanda VPN notkun og hafa svipuð lið til að fretta VPN notendur.

Kim Martin
Kim Martin Administrator
Sorry! The Author has not filled his profile.
follow me