Kas VPN-operaator näeb, milliseid saite te külastate?
Vaikimisi OpenVPN-server salvestab sessioone, mitte URL-e. Enne kui väidate, mida operaator näeb, võrrelge ühenduselogisid, tunnelipüüdmist ja DNS-lekke testi.
Küsige, mida VPN näeb, ja vastus sõltub sellest, kus te teel seisate. Sessioonikihis on operaatoril autentimissündmused ja baidid. Paketikihis on sihtkoha aadressid ja ajastus. DNS-kihis võivad olla nimed ise. Iga kiht vastab eri küsimusele ja ükski lüliti ei liiguta teid nende vahel.
Kaardistage kiht enne väite esitamist
Sama ühendus tekitab igas punktis erinevad kirjed ja privaatsusväide on mõttekas ainult siis, kui see punkti nimetab. Lugege tabelit veergude kaupa: mis sellel kihil olemas on, mida operaator seal näha võib ja mida needsamad kirjed talle ikka veel öelda ei suuda.
| Layer | Visible there | Not visible there |
|---|---|---|
| Session and authentication | Account, client address, start and stop times, assigned address, byte counts | URLs, page content, search terms |
| Forwarded packets | Destination address and port, sizes, timing, often the TLS server name | HTTP path, headers, response body |
| DNS resolver | Queried names and the client that asked | Page content and later requests |
| TLS-terminating proxy | Full request line, headers and body | Nothing, by design |
Ühe kihi lugemine kogu pildina on nii liialduste kui ka vale turvatunde algus. Pakkuja, kes ütleb, et ei logi sirvimist, võib olla URL-ide logimise osas täpne, hoides samal ajal sessioonikirjeid, ja paketipüüdmine, mis näitab ainult aadresse, ei muutu ilma pöördotsingute ja oletusteta sirvimisajalooks.
Poliitikat hinnates leidke lause, mis kirjeldab iga kihti. Kui poliitika neid ei erista, küsige, millised kirjed olemas on, selle asemel et nõustuda üldise väitega krüpteerimise kohta.
Sessioonide loend: mida tavaline OpenVPN-server hoiab
Kohe pärast paigaldust ei püüa OpenVPN server liiklust kinni. Tavaline väljund on sessioonide loend: konto, mis autentis, allikaaadress, kust see tuli, alguse ja lõpu ajatemplid, väljastatud tunneliaadress ja baidisummad mõlemas suunas. See on sessioonide loend, mitte sihtkohtade nimekiri.
Logimisvalikud võivad detaile lisada. Kõrgem detailsusaste kirjutab rohkem kätlemisest ja olekufail võib loetleda ühendatud kliente, kuid kumbki ei muuda serverit läbipaistvaks puhverserveriks. URL-ide saamiseks tuleb TLS lõpetada või käivitada selgesõnaline puhverserver, ja mõlemad muudavad usalduskorraldust, selle asemel et peidetud funktsiooni lubada.
Seepärast on sirvimislogi puudumise väite täpne versioon kitsam, kui see kõlab. Server ei tea lehte, kuid teab, et sessioon oli olemas, ja umbes kui palju andmeid sellest läbi läks. Kas seda sessioonikirjet hoitakse ja kui kaua, on eraldi poliitikaküsimus.
Sisemised ja välised paketid on erinevad tõendid
Paketipüüdmine näitab, mis tunnelist tegelikult läbi läheb. Serveris nimetage tunneliliides ja kirjutage faili, mida saab võrguühenduseta analüüsida:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headSee fail sisaldab dekrüpteeritud sisemist liiklust: kliendi tunneliaadress allikana, sihtkoha aadress ja port, paketi suurused ja ajastus. See ei sisalda HTTP-teed ega vastuse keha, kui TLS pole kuskil lõpetatud, ja need on tundlikud andmed, mille hoidmine on poliitikaotsus, mitte silumise mugavus.
Püüdmine füüsilisel liidesel näitab midagi muud. Seal näete väliseid pakette, mis on adresseeritud VPN-i lõpp-punktile, sees krüpteeritud kandev sisu. Kõrvalised aadressid selles failis on normaalsed, kui virtuaalne adapter on olemas, sest tunneliseade kannab sisemisi vooge, krüpteeritud transport aga väliseid.
Küsige, millele peaks püüdmine vastama. Rakenduse tunnelikasutus on nähtav virtuaalsel adapteril; tunneli jõudmine lõpp-punktini on nähtav füüsilisel. Mõlema faili kasutamine nii, nagu oleks see täielik pilt, annab järeldused, mida andmed ei toeta.
DNS on koht, kus nimed muutuvad nähtavaks
DNS jääb praktiliseks erandiks. Resolver näeb nimesid, mida tal palutakse lahendada, nii et selle käitaja saab teada, milliseid saite klient otsib, isegi kui hilisemad ühendused on krüpteeritud. Tunnelipüüdmine näitab aadresse; resolver näitab nimesid.
Kontrollige, millist aadressi resolver välise teenuse jõudmiseks kasutas. Vastus on resolveri väljundaadress, ja selle võrdlemine VPN-i väljundiga ütleb teile, kas päring läbis tunnelit:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53Kui see aadress vastab pigem kohalikule ühendusele kui tunneli väljundile, möödus otsing VPN-ist ja nimi oli kohalikul teel nähtav. Korrake kontrolli pärast kliendi uuendust, sest uus versioon võib muuta, millise resolveri profiil paigaldab.
Krüpteeritud DNS liigutab nähtavust, mitte ei eemalda seda. Võrk ei näe päringut enam, aga resolver näeb ikka, ja usaldusküsimus lihtsalt vahetab omanikku. TLS-serveri nimi ühenduse kätlemises on veel üks osaline signaal: see püsib sageli ka siis, kui kandev sisu on läbipaistmatu, nii et sihtaadressid pole ainus metaandmed, mida edastav server jälgida võib.
Kolm kirjetüüpi ja kes neid lugeda saab
Sessiooniarvestus, nimede kaupa kirjed ja lekke tõendid on kolm eri toodet kolme eri kohustusega. Sessioonilogid on odavad ja vähese tundlikkusega ning vastavad, kes millal ühendus. Nimede kaupa kirjed nõuavad logivat resolverit või selgesõnalist puhverserverit ja loovad avalikustamiskohustuse mõjutatud inimeste ees. Lekke tõend on kliendipoolne test, mis võrdleb, mida resolver paljastab, tunneli väljundiga.
Kirjutage üles, millist neist kolmest te käitate, kes seda lugeda saab ja kui kaua see püsib. Väited, et teenus ei pea logisid, kirjeldavad ühte kihti ja jäävad tõeseks ainult selles ulatuses. Sama pakkuja võib olla sessioonide osas täpne ja DNS-i osas eksida.
Hoidke test korratav: sama resolveripäring, sama püüdmisliides ja sama võrdlus. Privaatsusväide, mida ei saa nimetatud kihil testida, on loosung, mitte talitlusfakt.