Mikä VPN-tunneli on ja mihin suojaus päättyy
Tunneli käärii valitut paketit toiseen kirjekuoreen sen yhteyden yli, joka sinulla jo oli. Seuraa yhtä pyyntöä ja katso, minkä osoitteen sivusto todella tallentaa.
Asiakas ilmoittaa olevansa yhteydessä, lukko on kiinni, ja sivusto kirjaa silti asuntonne osoitteen. Mikään ei ole epäonnistunut. Tunneli ei korvaa Wi-Fi- tai matkapuhelinliittymääsi; se käärii valitut paketit toiseen kirjekuoreen ja lähettää sen kuoren verkossa, joka sinulla jo oli. Tempun ymmärtäminen on lähinnä yhden pyynnön seuraamista ja sen huomaamista, missä kuori avataan, koska lähes jokainen hämmentävä oire, kotiosoitteen vuotamisesta jumiutuneeseen suureen lataukseen, tulee juuri siltä rajalta.
Kaksi kirjekuorta, yksi fyysinen yhteys
Kannettavasi säilyttää normaalin yhteyden reitittimeen, ja reititin säilyttää normaalin yhteyden palveluntarjoajaan. Sillä polulla ei mikään muutu, kun tunneli nousee. Muuttuu se, että valitut paketit annetaan virtuaaliselle rajapinnalle, kääritään uuteen VPN-kumppanille osoitettuun pakettiin ja lähetetään tavallisena liikenteenä fyysisen yhteyden yli.
Vastaanottava pää on laite, joka avaa kuoren ja välittää alkuperäisen paketin kohti sen määränpäätä. Kahden pään välissä tarkkailija näkee ulomman otsikon eikä mitään sisemmästä, ellei protokolla salaa sitä, minkä useimmat kuluttajaprotokollat tekevät ja mitä yleinen tekniikka ei vaadi.
Siksi virtuaalinen rajapinta on yhtä aikaa todellinen ja harhaanjohtava. Se on olemassa ytimen objektina, jolla on osoite ja suurin siirtoyksikkö, ja käyttöjärjestelmä reitittää liikennettä siihen kuin mihin tahansa muuhun rajapintaan. Se ei ole kaapeli, ja sen olemassaolo todistaa vain, että komponentti on asennettu. Sen, käyttääkö selaimesi sitä, ratkaisevat reitit, ei se, että rajapinta on ylhäällä.
Seuraa yhden pyynnön matkaa
Valitse määränpää ja kysy ytimeltä, mitä rajapintaa se käyttää. Tämä yksi komento ratkaisee useimmat väittelyt siitä, tekeekö tunneli mitään:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0Jos reitin tuloste nimeää tunnelin rajapinnan, paketti kääritään. Jos se nimeää fyysisen rajapinnan, sitä ei kääritä, eikä asiakkaan uudelleenkäynnistys muuta sitä. Toinen komento näyttää molemmat rajapinnat vierekkäin, ja juuri niin huomaat tunnelin, joka nousi ilman osoitetta tai väärän perheen osoitteella.
Katso sitten ensimmäistä hyppyä kuoren sisältä ja vertaa sitä ensimmäiseen hyppyyn ulkopuolella:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5Tunnelin sisällä ensimmäinen hyppy on kumppanin sisäinen osoite, ei reitittimesi. Tunnelin rajapinnalla tehty kaappaus näyttää sisemmät paketit, eli liikenteen, jonka sovellus uskoo lähettävänsä. Samanaikainen kaappaus fyysisellä rajapinnalla näyttää ulommat paketit, ja yhdessä ne ovat selvin osoitus siitä, mitä tunneli todella tekee.
Kolme osoitetta, ja sivusto näkee vain yhden
Ihmiset sekoittavat nämä jatkuvasti, ja sekaannus synnyttää vääriä vuotoraportteja. Ne ovat eri kenttiä eri otsikoissa eri elinikineen.
| 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 |
Virtuaalisen sovittimen vieressä oleva numero on toinen rivi. Se ei ole osoite, jonka sivusto tallentaa, ja sen esittäminen julkisena IP-osoitteenasi on yksinkertaisesti väärin. Osoitteen, jonka sivusto näkee, määrittää ulostulo, ja yksityisverkon tunnelissa julkista ulostuloa ei ehkä ole lainkaan, koska määränpää on organisaation sisällä eikä internetissä.
Sivustojen välinen tunneli on sama mekanismi eri päätepisteillä. Kaksi reititintä käärii liikennettä verkkojen välillä, eikä yhdelläkään yksittäisellä laitteella ole asiakasta asennettuna. Kuori on periaatteessa sama, hallinnollinen raja ei.
Missä kuori avataan ja mikä säilyy sen yli
Tunneli päättyy kumppaniinsa. Jos sovelluksen oma salaus ulottuu pidemmälle, se säilyy sen rajan yli, mikä on HTTPS:n normaali tapaus: selaimen istunto päättyy sivustolle, joten ulostulo välittää salattua tekstiä, jota se ei voi lukea.
Mikään muu ei säily oletuksena. Salaamaton pyyntö on ulostulossa luettavissa täsmälleen niin kuin se oli luettavissa kahvilan Wi-Fi-verkossa, eikä tunneli lisää suojausta, jota sovelluksella ei koskaan ollut. Samoin ulostulon palomuurisäännöt ja välityskäytäntö päättävät, mitä seuraavaksi tapahtuu; onnistunut kättely on tosiasia kumppaniyhteydestä, ei matkan loppuosasta.
Ylikuormitus on toinen näkyvä seuraus. Jokainen paketti kantaa ylimääräistä otsikkoa, ja ulompi kuljetus voi lisätä omansa, joten käyttökelpoinen hyötykuorma pakettia kohden pienenee. Polulla, jolla on kiinteä suurin siirtoyksikkö, juuri siksi tunneli voi päästää pingin läpi ja pysäyttää suuren latauksen.
Tarkista polku, jonka sovellus todella kulki
Viimeinen vaihe on vahvistaa tietty sovellus, ei kone yleisesti. Selvitä määränpää, katso kyseisen osoitteen reittiä ja tarkkaile sitten yhteyttä, kunnes se on auki:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'Jos reitti nimeää tunnelin mutta socket-luettelo näyttää yhteyden, jonka lähdeosoite on fyysiseltä rajapinnalta, sovellus on sidottu johonkin tiettyyn, tai toinen tunneli kilpailee oletusreitistä. Se on reitityskysymys, ja siihen voi vastata näistä kolmesta tulosteesta eikä asiakkaan tilanäytöltä.
RFC 4301 -tietoturva-arkkitehtuuri kuvaa tämän käärimisen IP-kerroksen version IPsecille, ja sama kerroslogiikka pätee WireGuardiin ja OpenVPN -protokollaan. Kun voit osoittaa sisemmän paketin ja ulomman paketin erillisinä objekteina, suurin osa tunnelin käyttäytymisestä lakkaa olemasta arvoituksellista ja muuttuu reititystaulukoksi, jota voit lukea.