Nakikita ba ng operator ng VPN ang mga site na binibisita mo?
Ang default na OpenVPN server ay nagtatala ng mga session, hindi ng URL. Ihambing ang mga log ng koneksyon, pagkuha ng tunnel at pagsusuri ng DNS leak bago sabihin kung ano ang nakikita ng operator.
Itanong kung ano ang nakikita ng VPN, at ang sagot ay depende sa kung saan ka nakatayo sa landas. Sa antas ng session, may mga kaganapan ng pagpapatotoo at bilang ng byte ang operator. Sa antas ng packet, may mga patutunguhang address at oras. Sa antas ng DNS, maaaring may mga pangalan mismo. Bawat antas ay sumasagot sa ibang tanong, at walang isang switch na naglilipat sa iyo sa pagitan nila.
Tukuyin ang antas bago magpahayag
Ang parehong koneksyon ay gumagawa ng iba't ibang tala sa bawat punto, at ang pahayag tungkol sa privacy ay may kahulugan lamang kapag pinangalanan ang puntong iyon. Basahin ang talahanayan hanay sa hanay: ano ang umiiral sa antas na iyon, ano ang nakikita ng operator doon, at ano ang hindi pa masasabi ng parehong mga tala.
| 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 |
Ang pagbasa ng isang antas bilang buong larawan ang simula ng parehong labis na pahayag at maling katiyakan. Ang provider na nagsasabing hindi nagtatala ng pag-browse ay maaaring tama tungkol sa pagtatala ng URL habang nagtatago pa rin ng mga tala ng session, at ang pagkuha ng packet na nagpapakita lamang ng mga address ay hindi nagiging kasaysayan ng pag-browse nang walang paurong na paghahanap at haka-haka.
Kapag tinatasa ang isang patakaran, hanapin ang pangungusap na naglalarawan sa bawat antas. Kung hindi sila hinihiwalay ng patakaran, itanong kung anong mga tala ang umiiral sa halip na tanggapin ang pangkalahatang pahayag tungkol sa encryption.
Imbentaryo ng session: ano ang itinatago ng karaniwang OpenVPN server
Bilang default, ang OpenVPN server ay hindi kumukuha ng trapiko. Ang karaniwang output ay isang imbentaryo ng session: ang account na nagpatotoo, ang pinagmulang address na pinanggalingan, mga timestamp ng simula at wakas, ang ibinigay na tunnel address at ang kabuuang byte sa bawat direksyon. Iyon ay imbentaryo ng mga session, hindi listahan ng mga patutunguhan.
Ang mga opsyon sa pag-log ay makakadagdag ng detalye. Ang mas mataas na antas ng verbosity ay nagsusulat ng higit tungkol sa handshake, at ang file ng status ay maaaring maglista ng mga konektadong kliyente, ngunit wala sa dalawa ang gumagawa sa server na transparent na proxy. Ang paggawa ng URL ay nangangailangan ng pagtatapos ng TLS o pagpapatakbo ng tahasang proxy, at parehong binabago ang kaayusan ng pagtitiwala sa halip na i-on ang nakatagong tampok.
Kaya't ang tumpak na bersyon ng pahayag na walang log ng pag-browse ay mas makitid kaysa sa tunog nito. Hindi alam ng server ang pahina, ngunit alam nitong may session at humigit-kumulang gaano karaming data ang dumaan dito. Kung ang tala ng session na iyon ay itinatago, at gaano katagal, ay hiwalay na tanong ng patakaran.
Magkaibang ebidensya ang panloob at panlabas na packet
Ang pagkuha ng packet ay ang paraan upang makita kung ano talaga ang dumadaan sa tunnel. Sa server, pangalanan ang interface ng tunnel at isulat sa file na maaaring suriin offline:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headAng file na iyon ay naglalaman ng na-decrypt na panloob na trapiko: ang tunnel address ng kliyente bilang pinagmulan, ang patutunguhang address at port, mga sukat ng packet at oras. Wala itong landas ng HTTP o katawan ng tugon maliban kung tinapos ang TLS sa isang lugar, at ito ay sensitibong data na ang pagtatago ay desisyon ng patakaran at hindi kaginhawahan sa pag-debug.
Ang pagkuha sa pisikal na interface ay nagpapakita ng iba. Doon makikita ang mga panlabas na packet na patungo sa endpoint ng VPN, na may naka-encrypt na payload sa loob. Ang mga walang kaugnayang address sa file na iyon ay normal kapag may virtual adapter, dahil ang device ng tunnel ay nagdadala ng panloob na daloy habang ang naka-encrypt na transportasyon ay nagdadala ng panlabas.
Itanong kung anong tanong ang dapat sagutin ng pagkuha. Ang paggamit ng tunnel ng isang application ay nakikita sa virtual adapter; ang pag-abot ng tunnel sa endpoint ay nakikita sa pisikal. Ang paggamit ng alinman sa mga file bilang buong larawan ay nagbibigay ng mga konklusyong hindi kayang suportahan ng data.
Ang DNS ang lugar kung saan nagiging nakikita ang mga pangalan
Ang DNS ay nananatiling praktikal na eksepsiyon. Nakikita ng resolver ang mga pangalang hinihiling na lutasin, kaya ang sinumang nagpapatakbo nito ay natututo kung aling mga site ang hinahanap ng kliyente kahit naka-encrypt ang mga susunod na koneksyon. Ang pagkuha ng tunnel ay nagpapakita ng mga address; ang resolver ay nagpapakita ng mga pangalan.
Suriin kung aling address ang ginamit ng resolver upang maabot ang panlabas na serbisyo. Ang sagot ay ang exit address ng resolver, at ang paghahambing nito sa exit ng VPN ay nagsasabi kung dumaan ang query sa tunnel:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53Kung ang address na iyon ay tumutugma sa lokal na koneksyon at hindi sa exit ng tunnel, nilampasan ng paghahanap ang VPN at nakita ang pangalan sa lokal na landas. Ulitin ang pagsusuri pagkatapos ng update ng kliyente, dahil maaaring baguhin ng bagong bersyon kung aling resolver ang ini-install ng profile.
Ang naka-encrypt na DNS ay naglilipat ng visibility sa halip na alisin ito. Hindi na nakikita ng network ang query, ngunit nakikita pa rin ito ng resolver, at ang tanong ng pagtitiwala ay nagpapalit lamang ng kamay. Ang pangalan ng TLS server sa handshake ng koneksyon ay isa pang bahagyang senyales: madalas itong nananatili kahit malabo ang payload, kaya ang mga patutunguhang address ay hindi lamang ang metadata na maaaring obserbahan ng server na nagpapasa.
Tatlong uri ng tala at sino ang makakabasa
Ang accounting ng session, mga tala ayon sa pangalan at ebidensya ng leak ay tatlong magkaibang produkto na may tatlong magkaibang obligasyon. Ang mga log ng session ay mura at mababa ang sensitivity, at sinasagot nito kung sino ang kumonekta at kailan. Ang mga tala ayon sa pangalan ay nangangailangan ng resolver na nagtatala o tahasang proxy, at lumilikha ng obligasyon sa pagbubunyag sa mga apektadong tao. Ang ebidensya ng leak ay isang pagsubok sa panig ng kliyente na naghahambing sa ibinubunyag ng resolver sa exit ng tunnel.
Itala kung alin sa tatlo ang pinapatakbo mo, sino ang makakabasa at gaano katagal itong nananatili. Ang mga pahayag na walang log ang isang serbisyo ay naglalarawan ng isang antas, at nananatiling totoo lamang sa saklaw na iyon. Ang parehong provider ay maaaring tama tungkol sa mga session at mali tungkol sa DNS.
Panatilihing maaaring ulitin ang pagsubok: parehong query sa resolver, parehong interface ng pagkuha at parehong paghahambing. Ang pahayag ng privacy na hindi masusubok sa pinangalanang antas ay isang slogan, hindi isang katotohanang pang-operasyon.