Mennyire könnyű észlelni a VPN-t?

A virtuális magánhálózatok (VPN-k) sok adatvédelmi problémát oldnak meg. Mivel a VPN általában a számítógép és a VPN szolgáltató közötti forgalmat titkosítja, ezért egy megfigyelő számára nagyon nehéz megnézni az Ön forgalmát, hogy megnézze, mit készít. Sok ember azonban akarja elrejteni azt a tényt, hogy egyáltalán használ VPN-t; például a VPN-t tiltó országokban élő emberek, vagy más helyzetek, ahol a VPN használatát általában nem engedélyezik, vagy technikai eszközökkel blokkolják. Ebben a cikkben arra összpontosítunk, hogy milyen típusú adatokkal állhat megfigyelő a hálózati csomagok rögzítéséből összegyűjthető adatok, és hogy ezek az adatok hogyan lehet felismerni a VPN használatát.

A probléma háttere

Az égő kérdés a „miért”? Ki érdekel, ha valaki felfedezi, hogy VPN-t futtat? Ha a forgalmat egyébként erősen titkosítja, akkor mi a probléma??

Igaz, hogy sok helyzetben és sok országban egyáltalán nem számít, ha egy megfigyelő észlel egy VPN-t. Sok országban azonban tiltják a VPN-ek használatát, ezért fontos, hogy ezekben az országokban a VPN-felhasználók tudják, hogyan lehet felfedezni őket..

Annak meghatározásához, hogy VPN van-e használatban, a megfigyelőnek hozzáféréssel kell rendelkeznie egy útválasztón, amelyen a célforgalom áthalad. Célzott áldozat esetén a támadó nagy erőforrásokat fordíthat arra, hogy azonosítsa az útját, amelyet az adott áldozat használ. Nemzetállami megfigyelés esetén a hatékony felderítés sok útválasztó irányítását igényli. Amikor összekapcsolja ezt a két dolgot – egy szervezet, amely érdekli, ha Ön használ, és a VPN és még képes nagyszámú útválasztót irányítani – ez általában országos szintű fenyegető szereplőt jelez.

Ne feledje, hogy ez a cikk a VPN használatának a megfigyelők általi felfedezésének módjairól szól. Ez nem feltétlenül jelenti azt, hogy a VPN-alagútban titkosított adatok könnyebben kihasználhatók.

Tesztelési módszer

Az állami szintű erőforrásokhoz való hozzáférés nélkül a tesztelési platformom és a módszertan kissé kisebb méretű. Három virtuális gépet (VM) használva létrehoztam egy kis belső hálózatot a VirtualBox segítségével. A hálózati topológia mint ilyen:

Telepítettem a csomagszippantási szoftvert az OpenWRT router virtuális gépére, majd teszteltem a VPN-konfigurációkat a másik két virtuális gépen. A tcpdump csomagszippantó szoftver lehetővé tette számomra a virtuális gépek hálózati forgalmának elemzésére. Reálisabban beállítva, hogy a csomagrögzítő szoftvert valószínűleg az Internet útválasztóin telepítik, vagy legalábbis az internetszolgáltató hálózatán belül. Az elemző szoftver stratégiai elhelyezéséhez szükség lenne bizonyos ismeretekre azon internetes érdeklődési pontokról, ahol a célforgalom valószínűleg áramlik. A tesztelési hálózatomban 100% -os biztonsággal tudom, hogy a virtuális gépekbe és onnan érkező összes forgalom áthalad az OpenWRT útválasztón. Ezért ez a legjobb hely számomra a gyűjtőeszközeim elhelyezésére.

A VPN-mutatók nem technikai forrásai

A VPN használatát jelző összes adatforrás nem technikai. Míg egyesek nagyon technikai jellegűek, például a csomagok elemzése, mások nagyon nem technikai jellegűek, például az emberi hibák és a napi rutin.

Nem kívánt hálózati forgalom

A legtöbb VPN-felhasználó rendelkezik kliensszoftverrel, amelyet el kell indítani a VPN létrehozásához. Nagyon nehéz biztosítani, hogy a VPN létrehozása előtt a számítógép indításakor ne kerüljön forgalom az interneten keresztül. Lehet, hogy még azok a VPN-k sem, amelyek kill kapcsolóval rendelkeznek, nem tudnak semmit tenni a forgalomról, amely a rendszer indításakor áthalad.

Ennek teszteléséhez beállítottam a VyprVPN automatikus csatlakozási és megszakítási kapcsolóit a Windows virtuális gépen. Ezután leállítottam a Windows gépet, elkezdtem a csomagmegfogást az OpenWRT útválasztón, és elindítottam a Windows gépet. Ez nagyon sok csomagot generált és érdekes ez a két szekvencia.

Először is sok pongot láthatunk egy hasonló IP tartományban. Nem szándékosan csoportosítottam ezeket a csomagokat – így küldték őket organikusan:

Ez arra utal, hogy valami megpróbálja felsorolni a szervereket. Az ilyen típusú forgalom nagyon gyakori oka a VPN-forgatókönyvben egy VPN-ügyfél, amely megpróbálja meghatározni a leggyorsabb kiszolgálót. Ennek egyik módja az, hogy egy ICMP csomagot (ping néven) küldünk egy kiszolgálókészletre, hogy megnézze, melyik jön vissza a leggyorsabban..

Az első képernyőképről láthatjuk, hogy a 209.99.63.34 a leggyorsabb 99 milliszekundumban. A csomaggyűjtésben tovább látva hirtelen meglátjuk, hogy az ettől a ponttól származó forgalom nagy része titkosítva van, és 209.99.63.34-re irányul.

A puzzle következő darabja, hogy megtudja, mi van ezekben az IP-kben. Az IP WHOIS használatával, amely megadja az IP regisztrált tulajdonosát, láthatjuk, hogy ezeknek az IP-knek kivételével mindegyik a YHC Corporation-hez tartozik, és a Data Foundry adatközpontban lévő kiszolgálókra megoldódik:

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]

A következő logikus lépés az lenne, ha átvizsgálná ezeket az IP-ket, hogy megtudja, milyen szolgáltatásokat működtetnek. Nem fogok részletezni, hogyan kell ezt megtenni, de a tesztelésem azt mutatja, hogy a legtöbb szerver által megjelenített alapértelmezett csatlakozási szalagok eltávolítottak a VyprVPN szerverektől, tehát nincs egyértelmű jelzőtábla, hogy ezek az IP-k VPN szervert futtatnak..

Nem sok a teendő, hogy a számítógép hogyan működik, mielőtt elindulna. Ezért ha el akarja tönkretenni az ilyen típusú telepítési sorrendet, akkor a VPN-t a számítógép előtt kell futtatnia. Ennek egyik módja a VPN-ügyfél futtatása az útválasztón, ahelyett, hogy a számítógépen egy klienst futtatna. A router újraindulásakor továbbra is ugyanazok az indítási szekvenciák futnak, de ez általában ritkábban történik, mint a számítógépén.

Nincsenek titkosítatlan csomagok

Mint fentebb említettem, miután a ping-ek befejeződtek, a csomag elfog titkosított forgalmat mutat a leggyorsabb IP-re. Ha egy megfigyelő csak titkosított csomagokat lát, és nem egyetlen titkosítatlan csomagot, akkor ez jele lehet, hogy VPN van használatban. Miközben a világ gyorsan mozog a lehető legtöbb adat titkosítása felé az interneten, vannak még olyan kérések, amelyek általában nem vannak titkosítva. Ezek között vannak a DNS keresési lekérdezések, az NNTP (időkiszolgáló) lekérdezések és az egyéb protokollkérések, például az FTP és a Telnet igénybe vételének szétosztása, amelyek néha használatban vannak néhány alkalmazásunkban, de egyáltalán nem támogatják a titkosítást..

Szivárgások a hanyag emberi működési biztonságból (OpSec)

A látszólag triviális információk felhasználásával nagyszámú értelmes adat szerezhető be egy céltól. Sok ember sok időt és erőfeszítést költ azért, hogy enyhítse azt, amit „fontosnak” tartanak, és amelyet csak olyan triviális információk alapján lehet azonosítani, amelyekre nem gondoltak. Néhány példa az internet hosszú emlékezete, amelyből kiderült, hogy Hillary Clinton e-mail adminisztrátora valószínűleg Paul Combetta nevű fickó volt; A szörnyű kalóz Roberts, az AKA Ross Ulbricht, az illegális Selyemút internetes piac állítólagos vezetõjének ellen nagyrészt a laptopjában lévõ adatok miatt került sor, amelyeket fizikailag elvették tőle, miközben elvonultak egy nyilvános könyvtárban..

Kevésbé drámai módon a megfigyelők gyakran használnak olyan tevékenységeket, mint például tevékenységi ciklusok, hogy rögzítsék a cél időzónáját, vagy speciális karakterek jelenlétét az üzenetben, hogy azonosítsák a cél országának megfelelő nyelvi elrendezést. Nincs teljes lista azokról a dolgokról, amelyeket figyelembe kell venni az operatív biztonság mérlegelésekor, mivel az adatok keresztreferenciájának új módszereinek kidolgozása leginkább a képzelet és az erőforrások gyakorlata.

Vannak azonban bizonyos, a VPN használatát azonosító csomagok rögzítésére vonatkozó dolgok.

A visszajelző táblák a csomag metaadataiból

A PFS újrabillentyűk kiszámíthatók

Mivel a VPN-forgalom általában titkosítva van, általában el van rejtve a kíváncsiskodó szemektől. A titkosítás azért működik, mert nagyon nehéz a titkosított adatokat „kényszeríteni” a tiszta szövegtartalom feltárására. Valójában a titkosítás megszakítása olyan nehéz, hogy a nagyszabású megfigyelési projektek néha csak összegyűjtik az összes lehetséges adatot, abban a reményben, hogy valamilyen jövőbeli időpontban képesek lesznek megtörni a titkosítást, amikor a számítógép teljesítménye megnő, vagy meg tudják szerezni a kulcsokat. amelyeket az adatok titkosításához használtak. A tökéletes előrejutási titok (PFS) egy olyan módszer, amely felhasználható az utóbbi forgatókönyv megakadályozására.

A Perfect Forward Secrecy újra generálja a VPN-forgalom időszakos titkosításához használt titkosítási kulcsokat. Egy új kulcspár létrehozásakor az előző pár megsemmisül. Ez azt jelenti, hogy az összes összegyűjtött titkosított csomagot később nem lehet visszafejteni, mivel a titkosításhoz használt kulcs már nem létezik.

Az OpenVPN támogatja a PFS-t. A cikk adatainak rögzítése közben 10 másodpercre csökkenttem a kulcsfontosságú kerékpározási sebességet annak érdekében, hogy rögzítsem a folyamatot. Megállapítottam, hogy amikor a kulcs regenerálása megtörtént, a következő csomagok sorozata jött létre:

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 94 hosszúság
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104,254.92.61.openvpn: UDP, hosszúság 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 86 hosszúság
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 94 hosszúság
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, hosszúság 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 94 hosszúság
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 94 hosszúság
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 94 hosszúság
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, 94 hosszúság
09: 01: 59.062927 IP 192.168.1.204.openvpn > 104,254.92.61.openvpn: UDP, hosszúság 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, hossz 575

Figyelemre méltó dolog ebben a sorrendben az, hogy a csomagméret azonosak minden alkalommal, amikor a kulcs regenerálása megtörtént. Ezért minden alkalommal, amikor ilyen méretű csomagok sorozatát láttam a csomagmegfogásban, tudtam, hogy a kulcskerékpározás zajlik:

94
65
86
94
259
94
94
94
94
256
575

Valószínű, hogy bármilyen ismétlődő folyamat elméletileg létrehozná az ilyen csomagok ismétlődő sorozatát, de továbbra is használható annak jelzésére, hogy a PFS játékban lehet. Más adatokkal együtt ez az információ elegendő lehet a VPN-kapcsolat megerősítéséhez.

Minden csomag ugyanarra az IP-re irányul

Az internet szokásos használata során az emberek és a számítógépek sok különböző oldalról kérnek adatokat. A webhelyek mindegyikének eltérő IP-címe van. VPN használatakor minden egyes csomagot a VPN szerverre irányítanak. A VPN-kiszolgáló lebontja a VPN-titkosítási réteget az egyes csomagokról, hogy felfedje a valódi csomagot, majd elküldi azt a tényleges rendeltetési helyére. A VPN-kiszolgáló ugyanezt teszi a válaszokkal. Válaszcsomagokat fogad, becsomagolja őket egy titkosítási rétegbe, majd elküldi a csomagot a felhasználó számítógépére..

A csomagmegfogás, amely azt mutatja, hogy a számítógép a forgalmának 100% -át egyetlen IP-re továbbítja, jó jelzés arra, hogy VPN vagy proxy van használatban.

A Psiphon egy internetes cenzúraelkerülési eszköz. Érdekes funkcióval rendelkezik, amely bizonyos mértékig képes legyőzni ezt. Megosztott alagút üzemmóddal rendelkezik, amely lényegében csak a Pszifon alagutat használja a saját országát elhagyó forgalom számára.

Látni, hogy ez hogyan néz ki a csomagszinten, elindítottam a Psiphon-ot, és két helyet teszteltem. Kanadában vagyok, és itt van egy minta a forgalomról, amelyet a .CA domain regisztrátorunk számára irányítunk. Ebben az esetben a rendeltetési helyem jól látható a csomagmegfogásban.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Zászlók [.], ack 1026833, win 64240, hossz 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Zászlók [.], 1026833 .: 1028293, ack 715, win 5094, 1460 hosszú
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Zászlók [.], 1028293 szám: 1031213, ack 715, win 5094, hosszúság 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Zászlók [.], ack 1031213, win 64240, hossz 0

Ezután meglátogattam a Comparitech webhelyet, amely az Egyesült Államokban található:

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Flags [P.], sz .: 107809: 108277, ack 19080, win 1392, 468 hosszú
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Zászlók [.], ack 108277, nyerj 856, hosszúság 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flags [P.], sorrend: 19080: 19132, ack 108277, win 856, 52 hosszú
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Zászlók [.], Ack 19132, győzelem 1392, hossz 0

Vegye figyelembe, hogy az egyesült államokbeli forgalom miként kerül eljuttatásra a Linode kiszolgálóra, ahelyett, hogy összehasonlítsuk az összehasonlító webhelyet. A Linode egy nagyon nagy szervervállalat, és egyáltalán nem szokatlan, hogy a Linode szerver számára irányított forgalmat látják. A Psiphon ezt a forgalmat egy SSH-alagút használatával eltakarítja, hogy elrejtse a VPN minden nyomát. Ugyancsak a Linode Psiphon szerverének fordított DNS (rDNS) nem árulja el a Psiphonhoz való társulását; Az rDNS csak azt mutatja, hogy a Linode rendelkezik az IP-vel, ami várható. További részletek találhatók az rDNS-ről az obfuszkálás szakaszában, a cikk későbbi részében.

Ellentmondások az operációs rendszerben és a csomagos ujjlenyomatadatokban

Noha a TCP hálózatépítés az operációs rendszer diagnosztikája, a különböző operációs rendszerek néhány eltérő értékkel rendelkező csomagokat hoznak létre. Például az alapértelmezett CSL-értékű időcsomag-érték változhat a különböző rendszerekben létrehozott csomagok esetében. A legtöbb Windows rendszer alapértelmezés szerint a TTL csomagot 128-ra állítja, míg a legtöbb Linux rendszer 64-re állítja. Mivel a TTL a rögzített csomag látható része, meghatározható, mely operációs rendszer valószínűleg készítette a csomagot. A csomag készítésében vannak más visszajelző táblák is, például a hosszúság és a maximális szegmensméret (MSS), amelyek operációs rendszerekenként is eltérőek.

Az alábbi részlet egy Windows rendszerből létrehozott csomag része. Vegye figyelembe a ttl 127 Az utolsó sor értéke 127-re van állítva. Ennek oka az, hogy a TTL-t „komló” számában fejezik ki. Minden alkalommal, amikor egy csomag áthalad egy eszközön, például egy útválasztón, a TTL-jét egyvel csökkenti. Ebben az esetben a TTL 128-nál kezdődött, de mivel az útválasztón rögzítettem – egy ugrás után – most 127-re esik. Mégis elmondhatom, hogy soha nem volt 64, tehát valószínűleg egy Windows rendszeren létrehozott csomag..

08: 08: 51.657495 IP (0x0, ttl 64, id 32150, eltolás 0, zászlók [DF], UDP proto (17), 177 hossz)
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 (0x0, ttl 127, id 3890, eltolás 0, zászlók [DF], proto TCP (6), 52 hosszúság)

Egy Linux gépről elfoglalt csomag TTL értéke 63 az első ugrása után. Ennek oka az, hogy a legtöbb Linux gép a TTL csomag kezdeti értékét 64-re állítja.

08: 15: 55.913493 IP (0x0, ttl 63, id 41443, eltolás 0, zászlók [DF], UDP proto (17), 56 hosszúság)
192.168.2.139.48635 > resolver1.ihgip.net.domain: 47200+ A? google.com. (28)

De hát mi van? Miért lehet fontos tudni, hogy az operációs rendszer milyen csomagot hozott létre?

Ha egy megfigyelőnek speciális ismerete van a célról, akkor nagyon fontos lehet. Ha a célról ismert, hogy a Windows használja – talán egy olyan nagy szervezet tagjaként, amely az egész Windows rendszert használja -, de ebből a célból elfoglalt csomagok azt mutatják, hogy valószínűleg egy Linux gépen készültek, ez jó jelzés arra, hogy néhány VPN vagy proxy a fajta használatban van. Érdemes megjegyezni, hogy gyakorlatilag az összes VPN-kiszolgáló Linuxon vagy Unix-szerű szerveren fut.

A legtöbb rendszeren beállítható a csomagparaméterek, de nagyon kevés ember veszi ezt a hosszúságot.

Nem elegendő obfuzációs technika a VPN szolgáltatóktól

A hálózati elemzésnek nem csak a csomagok gyűjtéséről kell gondoskodnia. A kiegészítő folyamatok, például a DNS, szerepet játszhatnak. Számos VPN-felhasználó tisztában van a DNS-sel, mivel a DNS-lekérdezések egyértelmű küldése a megfigyelő számára az egyik módja annak, hogy meghatározzák, hol látogatnak vagy készülnek. Kevesebb felhasználó ismeri azonban a fordított DNS-t (rDNS). Hasonlóan a DNS-hez egy domain nevet társít egy IP-címhez, az rDNS IP-címet társít a gazdagépnévhez, és a gazdagépnév általában azonosítja az IP tulajdonosát. Ezenkívül a legtöbb programozó könyvtár és operációs rendszer rendelkezik a szokásos gethostnameby * () funkciók bizonyos verzióival, amelyek kiterjesztik a rendszer azon képességét, hogy IP-ket és gazdaneveket társítson.

A fordított DNS nem annyira kritikus, mint a „normál” DNS, mivel az rDNS nem játszik szerepet a forgalom irányításában. Ehelyett elsősorban az IP tulajdonjogának azonosítására szolgáló eszközként használják. Csak egy IP-cím tulajdonosa rendelheti hozzá az rDNS-rekordot. Ezért az IP-cím rDNS-rekordjának ellenőrzése ésszerű bizonyosságot nyújt arra, hogy ki a tulajdonos, vagy legalábbis ki akarja azt a tulajdonosot, aki azt gondolja, hogy birtokolja. Vegye figyelembe, hogy az rDNS-re nincs szükség, és sok IP-címben egyáltalán nincs rDNS-bejegyzés.

Nézzük meg a facebook.com domain példáját. A DNS A szabványos DNS-lekérdezés által biztosított rekord megjeleníti ezt az IP-címet:

$ dig + rövid facebook.com
31.13.67.35

Most használjunk egy fordított DNS-lekérdezést vagy a gethostnamebyaddr () függvényt, hogy megtudjuk, ki rendelkezik az adott IP-vel:

$ host -n 31.13.67.35
35.67.13.31.in-addr.arpa domain név mutató edge-star-mini-shv-01-mia3.facebook.com

Ebből láthatjuk, hogy a Facebook tulajdonában van az IP-cím. A legtöbb webhely azonban nem rendelkezik saját IP-vel; bérelt és önkényes szervezetekhez tartoznak, vagy esetleg kevésbé nyilvánvaló szervezetek tulajdonában vannak. Az Amazon egy nagy számítástechnikai szolgáltató példája, amelyet sok vállalat használ. Az rDNS-lekérdezés sok internetszolgáltatás IP-címére egyszerűen azt mutatja, hogy az Amazon tulajdonában van az IP, ezért az információnak kevés a haszna annak meghatározására, hogy ki üzemelteti az IP-t. Egy másik példa a Google. A Google kissé finomabb az rDNS bejegyzéseiben, ám továbbra is fenntartja a tulajdonjogi információkat. Így néz ki a fordított DNS egy Google IP-hez:

$ dig + rövid google.com
216.58.207.46

$ host -n 216.58.207.46
46.207.58.216.in-addr.arpa domain név mutató fra16s24-in-f14.1e100.net.

A Google tulajdonában van az 1e100.net domain, tehát láthatjuk, hogy ez az IP valójában a Google tulajdonában van.

A VPN-k világában a címfeloldó eszközöket potenciálisan lehet használni annak ellenőrzésére, hogy a forgalomnak szánt IP tartozik-e a VPN-hez. Például egy alapértelmezett tcpdump parancs az OpenWRT útválasztón megpróbálja megoldani a TCP-csomagokban látott IP-ket. Úgy tűnik, hogy elsősorban a gethostbyaddress () címet használja erre a célra, és ezért néha látni lehet, hogy hova irányulnak a csomagok. Az IPVanish munkamenet alapértelmezett tcpdump rögzítése ezt szemlélteti:

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

Az IPVanish Windows kliens három konfigurációt biztosít: egy standard OpenVPN kapcsolatot, egy HTTPS-t használó OpenVPN kapcsolatot és egy eltakarott kapcsolatot.

A fenti csomagokat egy munkamenet során elfogták az elmosódott OpenVPN-kapcsolat beállításával, a WireShark azonban továbbra is képes rendeltetési hely-információkkal szolgálni..

összefoglalva

A VPN használatának meghatározásakor nagyon kevés „ezüst golyó” található. Általában számos technikát vagy megfigyelést igényel ahhoz, hogy elegendő mutatót állítson össze, amelyek jelzik a VPN használatát, és még akkor is nehéz lehet 100% -ban biztos lenni. Azok a vállalatok, amelyeknek érdeke a VPN használatának megtiltása, például a Netflix és más streaming szolgáltatások, teljes munkaidőben foglalkoznak csapatokkal, amelyek erre a problémára szólnak. Más esetekben sok kelet-európai és közel-keleti ország) tiltja a VPN használatát, és hasonló csapatokkal rendelkezik a VPN-felhasználók kiküszöbölésére.