Mis on VPN-tunnel ja kus kaitse lõpeb
Tunnel mässib valitud paketid teise ümbrikusse üle ühenduse, mis teil juba oli. Jälgige üht päringut ja vaadake, millise aadressi sait tegelikult salvestab.
Klient ütleb, et on ühendatud, lukk on kinni ja sait logib ikkagi teie korteri aadressi. Midagi ei ole ebaõnnestunud. Tunnel ei asenda teie Wi-Fi ega mobiilsideühendust; see paneb valitud paketid teise ümbrikusse ja saadab selle ümbriku võrku, mis teil juba oli. Nipi mõistmine tähendab peamiselt ühe päringu jälgimist ja märkamist, kus ümbrik avaneb, sest peaaegu iga segane sümptom, koduaadressi lekkimisest kuni takerdunud suure allalaadimiseni, tuleb just sellest piirist.
Kaks ümbrikku, üks füüsiline ühendus
Teie sülearvuti hoiab tavalist ühendust ruuteriga ja ruuter hoiab tavalist ühendust teenusepakkujaga. Sellel teel ei muutu miski, kui tunnel püsti tõuseb. Muutub see, et valitud paketid antakse virtuaalsele liidesele, mässitakse uude, VPN-partnerile adresseeritud paketti ja saadetakse tavalise liiklusena üle füüsilise ühenduse.
Vastuvõttev pool on seade, mis ümbriku lahti pakib ja algse paketi sihtkohta edasi saadab. Kahe otsa vahel näeb vaatleja välist päist ja mitte midagi sisemisest, kui protokoll seda ei krüpteeri, mida enamik tarbijaprotokolle teeb ja üldine tehnika ei nõua.
Seetõttu on virtuaalne liides korraga tõeline ja eksitav. See eksisteerib kerneli objektina, millel on aadress ja maksimaalne edastusühik, ning operatsioonisüsteem suunab liiklust sinna nagu igasse teise liidesesse. See ei ole kaabel ja selle olemasolu tõestab ainult seda, et komponent on paigaldatud. Seda, kas teie brauser seda kasutab, otsustavad marsruudid, mitte see, kas liides on üleval.
Jälgige üht päringut teekonnal
Valige sihtkoht ja küsige kernelilt, millist liidest see kasutab. See üks käsk lahendab enamiku vaidlusi selle üle, kas tunnel üldse midagi teeb:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0
Kui marsruudi väljund nimetab tunneli liidest, mässitakse pakett. Kui see nimetab füüsilist liidest, siis ei mässita, ja kliendi taaskäivitamine ei muuda seda. Teine käsk näitab mõlemat liidest kõrvuti ja nii märkate tunnelit, mis tõusis püsti ilma aadressita või vale perekonna aadressiga.
Seejärel vaadake ümbriku seest esimest hüpet ja võrrelge seda väljaspool oleva esimese hüppega:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5
Tunneli sees on esimene hüpe partneri sisemine aadress, mitte teie ruuter. Tunneli liidesel tehtud püüdmine näitab sisemisi pakette, see on liiklus, mida rakendus arvab end saatvat. Samaaegne püüdmine füüsilisel liidesel näitab väliseid pakette ja need kaks koos on kõige selgem tõestus sellest, mida tunnel tegelikult teeb.
Kolm aadressi ja sait näeb ainult ühte
Inimesed ajavad neid pidevalt segi ja segadus tekitab valesid lekkearuandeid. Need on erinevad väljad erinevates päistes erineva elueaga.
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
Virtuaalse adapteri kõrval olev number on teine rida. See ei ole aadress, mille sait salvestab, ja selle esitamine teie avaliku IP-na on lihtsalt vale. Aadressi, mida sait näeb, määrab väljapääs, ja privaatvõrgu tunnelis ei pruugi avalikku väljapääsu üldse olla, sest sihtkoht asub organisatsiooni sees, mitte internetis.
Kahe saidi vaheline tunnel on sama mehhanism teiste otspunktidega. Kaks ruuterit mässivad liiklust võrkude vahel ja ühelgi üksikul seadmel ei ole klienti paigaldatud. Ümbrik on põhimõtteliselt identne, halduspiir aga mitte.
Kus ümbrik avaneb ja mis sellest alles jääb
Tunnel lõpeb oma partneri juures. Kui rakenduse enda krüpteering ulatub kaugemale, jääb see sellest piirist alles, mis on HTTPS-i tavaline juhtum: brauseri sessioon lõpeb saidil, seega väljapääs edastab šifreeritud teksti, mida see lugeda ei suuda.
Muu ei jää vaikimisi alles. Krüpteerimata päring on väljapääsul loetav täpselt nii, nagu see oli loetav kohviku Wi-Fi võrgus, ja tunnel ei lisa kaitset, mida rakendusel kunagi ei olnud. Samamoodi otsustavad väljapääsu tulemüürireeglid ja edastuspoliitika, mis juhtub järgmisena; edukas käepigistus on fakt partneriühenduse kohta, mitte ülejäänud teekonna kohta.
Ülekulu on teine nähtav tagajärg. Iga pakett kannab lisapäist ja väline transport võib lisada oma, seega kasutatav kasulik koormus paketi kohta kahaneb. Fikseeritud maksimaalse edastusühikuga teel on see täpselt põhjus, miks tunnel laseb pingi läbi ja jätab suure üleslaadimise seisma.
Kontrollige teed, mille rakendus tegelikult läbis
Viimane samm on kinnitada konkreetne rakendus, mitte masin üldiselt. Lahendage sihtkoht, vaadake selle aadressi marsruuti ja jälgige seejärel ühendust, kuni see on avatud:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'
Kui marsruut nimetab tunnelit, kuid soklite loend näitab ühendust füüsilise liidese lähteaadressiga, on rakendus seotud millegi konkreetsega, või konkureerib teine tunnel vaikemarsruudi pärast. See on marsruutimise küsimus ja sellele saab vastata nendest kolmest väljundist, mitte kliendi olekuekraanilt.
RFC 4301 turbearhitektuur kirjeldab selle mässimise IP-kihi versiooni IPseci jaoks ja sama kihiloogika kehtib WireGuardi ja OpenVPN puhul. Kui suudate osutada sisemisele paketile ja välisele paketile eraldi objektidena, lakkab enamik tunneli käitumist olemast mõistatuslik ja muutub marsruutimistabeliks, mida saate lugeda.