Kui lihtne on VPN-i tuvastamist?

Virtuaalsed privaatvõrgud (VPN) lahendavad palju privaatsusprobleeme. Kuna VPN krüpteerib tavaliselt teie arvuti ja VPN-i pakkuja vahelise liikluse, muudab see vaatleja jaoks teie liikluse vaatamise väga raskeks. Siiski on palju inimesi, kes tahavad, et oleks võimalik varjata asjaolu, et nad üldse kasutavad VPN-i; nagu inimesed VPN-e keelavates riikides või muud olukorrad, kus VPN-i kasutamine pole üldjuhul lubatud või tehniliste vahenditega blokeeritud. Selles artiklis keskendume andmete tüübile, mida vaatleja saab koguda võrgupakettide püüdmistest, ja kuidas neid andmeid saab kasutada VPN-i kasutamise tuvastamiseks.


Probleemi taust

Põlev küsimus on “miks”? Keda huvitab, kui keegi avastab, et teil on VPN? Kui liiklus on niikuinii tugevalt krüptitud, siis on probleem selles?

On tõsi, et paljudes olukordades ja paljudes riikides pole üldse vahet, kas vaatleja tuvastab VPN-i kasutamise. Kuid paljudes riikides keelatakse VPN-ide kasutamine ja seetõttu on nende riikide VPN-i kasutajatele oluline teada, kuidas neid saab leida.

VPN-i kasutamise tuvastamiseks peab vaatlejal olema juurdepääs ruuterile, mida sihtliiklus läbib. Sihtotstarbelise ohvri puhul võib ründaja kulutada suuri ressursse ruuteri ülevõtmise viisi leidmiseks, mida see konkreetne ohver kasutab. Rahvusriikide järelevalve korral oleks tõhusaks tuvastamiseks vaja paljude ruuterite kontrolli. Kui ühendate need kaks asja – organisatsioon, mis hoolib teie kasutatavast, ja VPN ja ka on võimeline kontrollima suurt hulka ruutereid – see viitab tavaliselt riigi tasandil ähvardajale.

Pidage meeles, et see artikkel käsitleb viise, kuidas vaatlejad saavad VPN-i kasutamise tuvastada. See ei tähenda tingimata, et VPN-tunnelis krüptitud andmeid on lihtsam kasutada.

Testimismetoodika

Ilma juurdepääsuta riigi tasemel ressurssidele on minu testimisplatvorm ja metoodika pisut väiksema ulatusega. Lõin väikese sisemise võrgu, kasutades VirtualBoxi abil kolme virtuaalset masinat (VM). Võrgu topoloogia on selline:

VPN-testvõrgu seadistamine

Paigaldasin OpenWRT ruuteri VM-i pakettide nuusutamise tarkvara ja testisin seejärel kahel teisel virtuaalsel masinal erinevaid VPN-i konfiguratsioone. Pakettide nuhkimistarkvara tcpdump võimaldas mul analüüsi jaoks VM-ide võrguliiklust hõivata. Realistlikumas seadistuses installitakse pakettaknad hõivamise tarkvara tõenäoliselt Interneti ruuteritesse või vähemalt ISP võrku. Analüüsitarkvara strateegiline paigutamine eeldaks teatavaid teadmisi huvipakkuvatest lähenemispunktidest Internetis, kus sihitud liiklus tõenäoliselt voolab. Oma testimisvõrgus tean sajaprotsendilise kindlusega, et kogu liiklus minu virtuaalsetesse masinatesse ja sealt väljub sellest OpenWRT ruuterist. Seetõttu on see minu jaoks parim koht oma kogumisriistade paigutamiseks.

VPN-indikaatorite mittetehnilised allikad

Kõik andmeallikad, mis näitavad VPN-i kasutamist, pole tehnilised. Kuigi mõned on väga tehnilised, näiteks pakettide analüüs, on mõned väga mittetehnilised, näiteks inimlikud vead ja igapäevane rutiin.

Tahtmatu võrguliiklus

Enamikul VPN-i kasutajatel on VPN-i loomiseks vajalik tarkvara, mis tuleb käivitada. On väga raske tagada, et enne VPN-i loomist arvuti käivitamisel ei kulgeks Internetis ühtegi liiklust. Isegi need tapakaitselülititega VPN-id ei pruugi olla võimelised liikluse jaoks midagi ette võtma, mis süsteemi alglaadimise ajal möödub.

vypr-vpn-autoconnect-mode

vypr-vpn-killswitch-mode

Selle testimiseks seadsin Windowsi virtuaalmasinas VyprVPN automaatse ühenduse ja tapmise lüliti võimalused. Seejärel lülitasin Windowsi masina välja, alustasin pakettide püüdmist OpenWRT ruuteril ja käivitasin Windowsi masina. Need kaks paketti genereerisid palju pakette ja huvipakkuvad.

Esiteks võime sarnase IP-vahemiku korral näha palju pingeid. Ma ei rühmitanud neid pakke tahtlikult – nii saadeti need orgaaniliselt:

vypr-vpn-windows-boot-ICMP-paketid

See viitab sellele, et midagi proovib loetleda servereid. VPN-stsenaariumi sellist tüüpi liikluse väga levinud põhjus on VPN-klient, kes üritab kindlaks teha kiireimat serverit. Üks meetod selleks on ICMP-paketi (tuntud kui ping) saatmine serverite komplekti, et näha, millised neist tulevad kiiremini tagasi.

Esimesest ekraanipildist näeme, et 209.99.63.34 jõudis kõige kiiremini 99 millisekundi jooksul. Pakkumiste kogumisel veelgi enam näeme äkki, et suurem osa liiklusest on sellest hetkest krüptitud ja on mõeldud 209.99.63.34

vypr-vpn-windows-boot-QUIC-paketid

Järgmine mõistatuse tükk on välja selgitada, mis neil IP-del on. Kasutades IP WHOIS-i, mis teatab IP-i registreeritud omaniku, näeme, et kõik need IP-d, välja arvatud üks, kuulub YHC Corporationile ja otsustatakse Data Foundry andmekeskuse serveritele:

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]

Järgmine loogiline samm oleks nende IP-de skannimine, et näha, milliseid teenuseid nad töötavad. Ma ei edasta üksikasju selle kohta, kuidas seda teha, kuid minu testimine näitab, et vaikimisi ühenduse loomise ribareklaamid, mida enamus servereid kuvatakse, on VyprVPN-serveritest eemaldatud, nii et pole mingit selget märku, et need IP-d käitavad VPN-serverit.

Enne arvuti käivitamist ei saa teie arvuti toimimises palju ära teha. Seega, kui soovite seda tüüpi häälestusjärjestust hägustada, peate VPN-i käivitama oma arvuti ees. Selle üks viis on VPN-kliendi käitamine ruuteril, mitte arvutis kliendi käitamine. Ruuteri taaskäivitamisel käivad sa ikka samad käivitusjärjestused, kuid tavaliselt on see harvem kui teie arvutis.

Krüpteerimata pakette pole

Nagu ma eespool mainisin, näitab pakettpüük kui pingid olid valmis, krüptitud liiklust kiireima IP-ni. Kui vaatleja näeb ainult krüptitud pakette, mitte ühtegi krüptimata paketti, võib see olla märk sellest, et VPN on kasutusel. Ehkki maailm liigub kiiresti veebis võimalikult palju andmete krüptimist, on siiski mõned taotlused, mida tavaliselt ei krüpteerita. Nende hulgas on DNS-i päringupäringud, NNTP (ajaserveri) päringud ja muude protokollitaotluste (nt FTP ja Telnet) skrammimine, mida mõnikord kasutatakse mõnes meie rakenduses, kuid mis ei toeta üldse krüptimist.

Lekked inimese lohakast operatiivturvalisusest (OpSec)

Pealtnäha triviaalset teavet kasutades saab sihtmärgist palju olulist teavet. Paljud inimesed kulutavad palju aega ja vaeva selleks, et leevendada seda, mida nad peavad oluliseks, ainult selleks, et tuvastada triviaalne teave, mida nad ei mõelnud. Mõned näited hõlmavad pikka mälu Internetist, millest selgus, et Hillary Clintoni e-posti administraator oli tõenäoliselt mees nimega Paul Combetta; Kardetud piraat Roberts, AKA ebaseadusliku Siiditee Interneti-turu väidetav pealik Ross Ulbricht sai süüdistuse suuresti tänu tema sülearvuti andmetele, mis olid temalt füüsiliselt võetud, samal ajal kui nad olid avalikus raamatukogus häiritud..

Vähem dramaatiliselt saavad vaatlejad sihtkoha ajavööndi täpsustamiseks või sõnumis erimärkide olemasolu abil näiteks tegevuste tsüklit kasutada eesmärgi riigile vastava keele paigutuse tuvastamiseks. Puudub täielik loetelu asjadest, mida operatiivse turvalisuse kaalumisel arvestada, sest uute andmete ristviitamise võimaluste väljatoomine on enamasti kujutlusvõime ja ressursside kasutamine.

Siiski on VPN-i kasutamise tuvastamiseks mõned konkreetsed pakettide hõivamisega seotud asjad.

Märgulampide märgid paketi metaandmetest

PFS-i uuesti võtmed on etteaimatavad

Kuna VPN-liiklus on tavaliselt krüptitud, on see tavaliselt utelite eest varjatud. Krüptimine toimib, kuna selle selge teksti sisu paljastamiseks on väga raske krüptitud andmeid sundida. Krüptimise murdmine on tegelikult nii raske, et suuremahulised seireprojektid koguvad mõnikord lihtsalt kõik võimalikud andmed, lootes, et kui arvuti võimsus suureneb või kui nad on võimelised võtmeid hankima, suudavad nad krüptimise mingil tulevikus rikkuda. mida kasutati andmete krüptimiseks. Täiuslik edasisaladus (PFS) on meetod, mida saab kasutada viimase stsenaariumi ärahoidmiseks.

Perfect Forward Secrecy genereerib VPN-liikluse perioodiliseks krüptimiseks kasutatavad krüptimisvõtmed uuesti. Uue võtmepaari genereerimisel eelmine paar hävitatakse. See tähendab, et kõiki kogutud krüptitud pakette ei saa hiljem dekrüpteerida, kuna nende krüptimiseks kasutatud võtit pole enam olemas.

OpenVPN toetab PFS-i. Selle artikli kohta andmeid kogudes langetasin võtme jalgrattasõidu kiiruse 10 sekundini, et toimuvat protsessi jäädvustada. Leidsin, et kui võtme taastamine toimus, genereeriti järgmine pakettide jada:

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

Selle jada puhul on tähelepanuväärne see, et paketi suurused on iga kord, kui võtme taastamine toimus, ühesugused. Seetõttu teadsin iga kord, kui nägin oma pakettide püüdmisel nende suurustega pakettide jada, võtmetsüklid toimuvad:

94
65
86
94
259
94
94
94
94
256
575

Vaieldamatult tekitaks iga korduv protsess teoreetiliselt sellise pakettide korduva jada, kuid seda saab siiski kasutada näitajana, et PFS võib olla mängus. Koos teiste andmetega võib sellest teabest VPN-ühenduse kinnitamiseks piisata.

Kõik sama IP-le suunatud paketid

Interneti tavapärase kasutamise ajal taotlevad inimesed ja arvutid andmeid paljudelt erinevatelt saitidelt. Kõigil neil saitidel on erinev IP-aadress. VPN-i kasutamisel on iga pakett määratud VPN-serverile. VPN-server koorib VPN-i krüptimiskihi iga paketi küljest lahti, et paljastada tegelik pakett, ja saadab selle siis teel oma tegelikku sihtkohta. VPN-server teeb sama ka vastustega. Ta võtab vastu vastusepaketid, mähistab need krüptimiskihti ja saadab seejärel paketi kasutaja arvutisse.

Pakettpüük, mis näitab, et arvuti saadab 100% oma liiklusest ühele IP-le, on hea indikaator, et VPN või puhverserver on kasutusel.

Psiphon on Interneti-tsensuurist kõrvalehoidmise tööriist. Sellel on huvitav funktsioon, mis suudab sellega teatud määral võidelda. Sellel on jagatud tunnelirežiim, mis kasutab Psiphoni tunneli sisuliselt ainult teie koduriigist väljuva liikluse jaoks.

võrdlus-psifoon-splittunnel-režiim

Et näha, kuidas see paketttasandil välja näeb, käivitasin Psiphoni ja testisin kaht saiti. Olen Kanadas ja siin on näide liiklusest, mis on suunatud meie enda .CA domeeni registripidajale. Sel juhul on minu sihtkoht paketipüügil selgelt nähtav.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Lipud [.], ack 1026833, võit 64240, pikkus 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Lipud [.], Seq 1026833: 1028293, ack 715, win 5094, pikkus 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Lipud [.], Seq 1028293: 1031213, ack 715, win 5094, pikkus 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Lipud [.], ack 1031213, võit 64240, pikkus 0

Seejärel külastasin Comparitechi veebisaiti, mida majutatakse Ameerika Ühendriikides:

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Lipud [P.], seq 107809: 108277, ack 19080, võit 1392, pikkus 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Lipud [.], ack 108277, võit 856, pikkus 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Lipud [P.], seq 19080: 19132, ack 108277, võit 856, pikkus 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Lipud [.], Ack 19132, võit 1392, pikkus 0

Pange tähele, kuidas USA-sse suunduv liiklus saadetakse võrdlusvõrgu.com asemel Linode serverisse. Linode on väga suur serveriettevõte ja Linode serverile mõeldud liikluse nägemine pole sugugi ebatavaline. Lisaks hägustab Psiphon seda liiklust, kasutades VPN-i jälgede peitmiseks SSH-tunnelit. Ka Linode Psifooni serveri pöörd DNS (rDNS) ei kinnita selle seotust Psifooniga; rDNS näitab lihtsalt, et Linode omab eeldatavat IP-d. Selles artiklis on hiljem hägususe jaotises rDNS-i kohta rohkem teavet.

Vastuolud opsüsteemi ja paketi sõrmejälgede andmetes

Ehkki TCP võrgundus on opsüsteemi agnostiline, loovad erinevad opsüsteemid mõnede erinevate väärtustega pakette. Näiteks varieerub pakettide eri süsteemides loodud vaikimisi väärtus TTL (Time-To-Live). Enamik Windowsi süsteemi seab paketi TTL vaikeseadeks 128, samas kui enamiku Linuxi süsteemide puhul 64. Kuna TTL on hõivatud paketi nähtav osa, on võimalik kindlaks teha, milline OS selle paketi kõige tõenäolisemalt lõi. Pakettkonstruktsioonis on ka muid märguande märke, näiteks pikkus ja maksimaalne segmendi suurus (MSS), mis erinevad ka operatsioonisüsteemide lõikes.

Allpool olev fragment on osa paketist, mis on loodud Windowsi süsteemist. Pange tähele ttl 127 viimase rea väärtus on seatud 127. Selle põhjuseks on see, et TTL on väljendatud “humala” arvuna. Iga kord, kui pakett läbib mõnda seadet, näiteks ruuterit, vähendatakse selle TTL-i ühe võrra. Sel juhul algas TTL 128-st, kuid kuna ma salvestasin selle ruuteril – pärast ühte hüpet -, on see nüüd 127. Siiski võin siiski öelda, et see polnud kunagi 64, seega on see tõenäoliselt Windowsi süsteemis loodud pakett.

08: 08: 51.657495 IP (tos 0x0, ttl 64, id 32150, ofset 0, lipud [DF], proto UDP (17), pikkus 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, ofset 0, lipud [DF], proto TCP (6), pikkus 52)

Linuxi masinalt püütud paketi TTL on pärast esimest hüpet 63. Selle põhjuseks on asjaolu, et enamik Linuxi masinaid seab paketi TTL algväärtuseks 64.

08: 15: 55.913493 IP (tos 0x0, ttl 63, id 41443, ofset 0, lipud [DF], proto UDP (17), pikkus 56)
192.168.2.139.48635 > resolver1.ihgip.net.domeen: 47200+ A? google.com. (28)

Aga mis siis? Miks võib olla oluline teada, milline opsüsteem lõi paketi?

Kui vaatlejal on sihtkoha kohta eriteadmised, võib see olla palju oluline. Kui teada, et sihtmärk kasutab Windowsi – võib-olla suure organisatsiooni liikmena, mis kasutab Windowsi kogu ulatuses -, kuid sellest sihtmärgist püütud paketid näitavad, et need on tõenäoliselt loodud Linuxi arvutis, on see hea indikaator, et mõne VPN või puhverserver selline on kasutuses. Väärib märkimist, et praktiliselt kõiki VPN-servereid kasutatakse Linuxi või Unixi laadsetes serverites.

Enamikus süsteemides on võimalik pakettide parameetreid reguleerida, kuid väga vähesed inimesed kasutavad seda pikkust.

Ebapiisavad VPN-i pakkujate häiringutehnikad

Võrguanalüüs on midagi enamat kui lihtsalt pakettide kogumine. Täiendavat rolli võivad mängida kõrvalprotsessid, näiteks DNS. Paljud VPN-i kasutajad on DNS-ist teadlikud, kuna DNS-i päringute selge saatmine on vaatleja jaoks üks võimalus kindlaks teha, kus külastate või mida kavatsete külastada. Kuid tagurpidi DNS-ist (rDNS) on teadlik vähem kasutajaid. Sarnaselt DNS-ga seob domeeninimi IP-aadressiga, seob rDNS IP-aadressi hostinimega ja hostinimi identifitseerib tavaliselt IP-aadressi omaniku. Lisaks on enamikul programmeerimisraamatukogudes ja opsüsteemides standardse gethostnameby * () funktsioonide versioon, mis laiendab süsteemi võimet seostada IP-sid ja hostinimesid.

Tagurpidi DNS ei ole nii kriitiline kui “tavaline” DNS, kuna rDNS ei mängi liikluse suunamises mingit rolli. Pigem kasutatakse seda peamiselt intellektuaalomandi omandiõiguse tuvastamise vahendina. Ainult IP-aadressi omanik saab sellega rDNS-kirje seostada. Seetõttu annab IP-aadressi rDNS-kirje kontrollimine mõistliku kinnituse selle kohta, kellele see kuulub, või vähemalt sellele, kes soovib, et omanik arvaks, et see kuulub teile. Pange tähele, et rDNS pole vajalik ja paljudel IP-aadressidel pole rDNS-i sisestusi üldse.

Vaatame domeeni facebook.com näidet. DNS Tavalise DNS-i päringuga loodud kirje näitab seda IP-aadressi:

$ dig + lühike facebook.com
31.13.67.35

Kasutame nüüd pöördvõrdelist DNS-päringut või funktsiooni gethostnamebyaddr (), et näha, kellele see IP kuulub:

$ host – n 31.13.67.35
35.67.13.31.in-addr.arpa domeeninime osuti edge-star-mini-shv-01-mia3.facebook.com

Sellest näeme, et Facebook omab seda IP-aadressi tegelikult. Kuid enamik saite ei oma oma IP-sid; nad on renditud ja kuuluvad suvalistesse organisatsioonidesse või kuuluvad vähem silmnähtavatele üksustele. Amazon on näide suurest arvutiteenuse pakkujast, mida kasutavad paljud ettevõtted. Paljude Interneti-teenuste IP-aadressi rDNS-päring näitab lihtsalt, et IP kuulub IP-le ja seetõttu on sellest teabest vähe kasu IP-aadressi haldaja määramisel. Teine näide on Google. Google on oma rDNS-i sissekannetes pisut peenem, kuid hoiab siiski omanditeavet. DNS-i vastupidine Google’i IP-aadress otsib järgmist:

$ dig + lühike google.com
216.58.207.46

$ host – n 216.58.207.46
46.207.58.216.in-addr.arpa domeeninime osuti fra16s24-in-f14.1e100.net.

Google omab domeeni 1e100.net, nii et näeme, et see IP kuulub tegelikult Google’ile.

VPN-ide maailmas saab aadresside eraldamise tööriistu kasutada selleks, et kontrollida, kas IP, millele teie liiklus on mõeldud, kuulub VPN-i. Näiteks proovib OpenWRT-ruuteri vaikekäsklus tcpdump lahendada TCP-pakettides nähtavaid IP-sid. Tundub, et selleks kasutatakse peamiselt gethostbyaddress () ja seetõttu on mõnikord võimalik näha, kuhu paketid on suunatud. IPVanishi seansi vaikimisi tcpdump-jäädvustus illustreerib seda:

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

IPVanishi Windowsi klient pakub kolme konfiguratsiooni: tavaline OpenVPN-ühendus, OpenVPN-ühendus HTTPS-i abil ja hävinud ühendus.

ipvanish-vpn-openvpn-mode

Ülaltoodud paketid hõivati ​​seansi ajal, kasutades hävinud OpenVPN-ühenduse seadet, kuid siiski suudab WireShark pakkuda sihtkoha teavet.

Kokkuvõttes

VPN-i kasutamise määramisel on väga vähe hõbedaseid täppe. Piisava arvu indikaatorite koostamiseks, mis viitavad VPN-i kasutamisele, on vaja võtta mitmeid tehnikaid või tähelepanekuid. Isegi siis võib olla 100% kindel, kas see on kindel. Ettevõtted, kes on huvitatud VPN-i kasutamise keelamisest, näiteks Netflix ja muud voogedastusteenused, on täiskohaga meeskonnad pühendunud just sellele probleemile. Muudel juhtudel keelavad paljud Ida-Euroopa ja Lähis-Ida riigid VPN-i kasutamise ja neil on sarnased meeskonnad VPN-i kasutajate tuhkrutamiseks.

Kim Martin Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map