Tatlong tagamasid ang nagiging isang tanong tuwing may nagtatanong kung itinatago ng VPN ang trapiko niya: ang network na konektado siya, ang makina sa mga kamay niya at ang operator ng tunnel. Bawat isa ay may natututuhang iba, at binabago ng tunnel ang bawat pananaw na iyon sa ibang paraan. Nakakatulong ang pagtrabaho sa kabilang direksyon at pagsisimula sa pahayag na ginagawa, dahil ang pahayag ang kailangang makatagal sa pagsusuri. Magpasya kung aling pahayag ang kailangan mo, pagkatapos ihambing ang mga kasangkapan dito.

Unang pahayag: walang makakabasa ng trapiko

Magsimula sa pinakamakitid na pahayag: nananatiling hindi mabasa ang payload. Ang pasibong tagamasid sa ruta ay hindi makakatingin sa loob ng sesyong TLS, kaya kakaunti ang naidaragdag ng tunnel sa site na gumagamit na ng HTTPS at wala itong naidaragdag laban sa dalawang dulo. Ang bumabasag sa pahayag na ito ay ang may kontrol sa device, dahil tinatapos ng inspection proxy ang koneksyon at muling pinipirmahan ito ng root na pinagkakatiwalaan na ng makina. Iyon ang dahilan kung bakit lumalabas pa rin ang kandado habang dala ng certificate chain ang pangalan ng organisasyong naglagay ng root.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

Sa macOS naglilimbag ang pipeline na iyon ng isang subject line para sa bawat certificate sa keychain ng makina, nang hindi nagbubukas ng window, at sa Windows ang certutil -store Root ay naglilista ng parehong store na ipinapakita ng certlm.msc nang grapiko. Ang root na pag-aari ng paaralan, employer o produktong pangseguridad ng network ang entry na dapat hanapin. Ang makahanap ng isa ay nagpapatunay lamang na posible ang interception, hindi na nangyayari ito.

Ang magagawa mo tungkol dito ay isang usapin ng patakaran at hindi ng teknikalidad. Ang pagtanggal ng profile o inspection root mula sa hardware na hindi mo pag-aari ay karaniwang lumalabag sa kasunduan sa katanggap-tanggap na paggamit, at ang management system ay may tendensiyang mapansin at muling ilapat ito, kaya ang pangangailangan na hindi mabasa ng may-ari ng device ang trapiko mo ay nangangailangan ng ibang device, hindi ibang setting.

Ikalawang pahayag: walang nakakakita kung saan ka pupunta

Ang destinasyon ang mas mahirap na pahayag, dahil may dalawang pagbubunyag bago mag-load ang isang pahina. Ang query ay pumupunta sa resolver na naka-configure sa system, at ang sagot ay nakikita ng network na nagdadala nito. Pagkatapos ay dinadala ng TLS handshake ang hiniling na pangalan ng server nang hayagan, maliban kung suportado ang Encrypted Client Hello sa magkabilang dulo. Wala sa dalawang pagbubunyag ang nagsasangkot ng decryption, kaya walang epekto ang tunnel sa alinman.

resolvectl status | grep -A2 "Link"
nslookup example.com

Kung aling resolver ang aktuwal na ginagamit ang tumutukoy sa pagkakalantad, at ito ay masusukat sa halip na pagtalunan. Sa Linux naglilimbag ang resolvectl status ng mga DNS server bawat link, at sinasabi ng output nito kung ang resolver ng site o ang itinulak ang sumasagot. Sinasagot ng Windows ang parehong tanong sa nslookup example.com, na ang unang bloke ng output ay ang DNS server na sumagot.

Kapag nagtanong ang laptop sa resolver ng site bago umangat ang tunnel, o dumating ang profile na walang kapalit na server kaya nananatiling gamit ang luma, nag-iipon pa rin ang administrator ng mga hostname nang walang anumang decryption. Ang naka-encrypt na DNS sa browser ay lumilihis sa itinulak na resolver o ganap na hinaharangan at nabibigo nang sarado. Nakikita ng exit operator ang parehong mga pangalan mula sa kanyang panig. Kaya ang pagpapalit ng resolver ay hindi naglalayo sa pagbubunyag na iyon mula sa provider ng tunnel.

Ikatlong pahayag: walang nakakaalam na kumonekta ka

Ang ikatlong pahayag ay ang hindi kayang suportahan ng tunnel, dahil tumatawid pa rin ang mga packet sa lokal na network. Natututuhan ng network na iyon ang address ng endpoint, ang tinatayang volume, ang oras at ang pagkakaroon ng isang pangmatagalang naka-encrypt na sesyon, na sapat para harangan, limitahan o mapansin lamang. Ang firewall na hindi makabasa ng packet ay maaari pa ring tumangging ipasa ito. Ang mabantayan ay hindi katulad ng walang bantay: inilipat mo ang tagamasid, hindi mo ito binura.

Ang split tunnelling, at anumang application na hindi pinapansin ang itinulak na ruta, ay gumagawa ng mga daloy sa labas ng tunnel na eksaktong kamukha ng dati. Iyon ang mga daloy na unang napapansin ng maingat na tagamasid, at ipinapakita ng route table ng client kung aling mga destinasyon ang hindi kasama.

Ang operator sa kabilang dulo ay may salamin ng pananaw na iyon: exit address, oras, volume at karaniwang mga pangalan ng site. Ang provider mo ang nagiging parteng may vantage point, na ibang kasunduan kaysa kawalan ng nakikita. Ang pumili ng provider na pinagkakatiwalaan mo ay tunay na desisyon; ang tawagin ang resulta na hindi namamataan ay hindi.

Magpasya kung aling pahayag ang kailangan mo

Isulat ang pangangailangan sa isang linya bago hawakan ang isang client: itago ang nilalaman, itago ang mga destinasyon o itago kung kumonekta ka man. Ang nilalaman ay pinangangasiwaan na ng HTTPS kasama ng tunnel, habang ang mga destinasyon ay nangangailangan ng resolver at landas na ganap na lumilihis sa kagamitan ng site.

Ang ikatlong pangangailangan ang nakakailang, dahil may isang bagay na nakakabit pa nang nakikita sa isang lugar, naka-encrypt man o hindi. Walang setting ng client ang nagbabago niyon. Kung maghiwalay ang pangangailangan at ang patakaran, ang agwat na iyon ay para sa usapan sa may-ari ng patakaran, hindi sa opsyon sa client. Ang taong makakasagot nito ay ang taong sumulat ng patakaran.

Kaugnay na mga artikulo