Privata DNS kontraŭ VPN: kion ĉiu tavolo vere kovras

Via telefono havas privatan DNS agorditan al gastigantnomo de provizanto kaj samtempe ruliĝantan VPN-aplikon. Estas racie supozi, ke unu el ili nun regas la nomserĉojn. Nek faras, en la senco, kiun tiu frazo implicas, kaj la plej rapida maniero vidi kial estas sekvi unu peton de la momento, kiam vi frapetas ligilon.

Ĉi tiuj du funkcioj situas en malsamaj punktoj de la sama vojaĝo. Privata DNS ĉifras la demandon, kiun vi faras al solvilo. VPN ŝanĝas la itineron, kiun prenas la konekto de la respondo.

Do trairu ĝin laŭorde sur aparato, kie ambaŭ estas ŝaltitaj, kaj notu, kion ĉiu tavolo ankoraŭ povas vidi.

Paŝo unu: la serĉo forlasas la aplikaĵon

Vi frapetas ligilon. Antaŭ ol io konektiĝas, la aplikaĵo bezonas adreson por tiu gastigantnomo. En Android la koncerna ekrano estas Agordoj, Reto kaj interreto, Privata DNS. Elekti Gastigantnomon de privata DNS-provizanto metas la aparaton en striktan reĝimon: ĝi faras DNS super TLS al tiu gastigantnomo sur pordo 853, kaj se la ĉifrita interŝanĝo malsukcesas, la serĉo malsukcesas anstataŭ silente reiri al simpla teksto sur pordo 53.

Tio estas signifa diferenco disde Aŭtomata, kiu uzas oportunisman ĉifradon kaj volonte uzos neĉifritan solvilon, kiam la reto interferas. Se via celo estas, ke serĉoj neniam okazu en klara teksto, la strikta reĝimo kun provizanta gastigantnomo estas la agordo, kiu kongruas.

Jen la unua afero, kiun la trairo malkaŝas: la serĉo estas protektita kontraŭ la loka reto, kaj la solvilo tamen ekscias la nomon. Ĉifrado kovras la salton. La operatoro de tiu solvilo vidas la peton, ĉar respondi ĝin estas lia tasko.

Paŝo du: la konekto prenas alian itineron

La solvilo redonas adreson kaj la aplikaĵo konektiĝas al ĝi. Ĉi tiu paŝo ne estas influita de tio, kiel la serĉo estis ĉifrita. Sen tunelo la konekto forlasas vian normalan publikan adreson, kaj la celloka IP kaj la TLS-manpremo kutime igas la gastigantnomon videbla al la reto ĉiuokaze, ĉu kun ĉifrita DNS aŭ ne.

Ŝaltu la VPN-on, kaj ĉi tio estas la paŝo, kiu ŝanĝiĝas. Trafiko kongruanta kun la enkursiga politiko de la kliento iras tra la tunelo, la loka reto vidas konekton al la VPN-finpunkto, kaj la retejo kutime vidas la eliran adreson. Nomresolvado ankaŭ povas vojaĝi interne de la tunelo, depende de tio, kion la kliento sendas.

Tiu disiĝo estas la tuta komparo en unu frazo. DNS-ĉifrado respondas, kiu povas legi la demandon. VPN respondas, kien iras la konversacio.

Paŝo tri: ene de la tunelo DNS fariĝas politika demando

Nun la du funkcioj interagas, kaj la retumilo estas la kutima fonto de surprizoj. Retumilo kun propra agordo pri sekura DNS povas sendi serĉojn al sia elektita solvilo per HTTPS anstataŭ demandi la operaciumon. La agordo de Android pri privata DNS ne atingas tiun decidon.

En Firefox la ŝaltilo estas sub Agordoj, Privateco kaj sekureco, Ŝalti sekuran DNS. En Chrome ĝi estas sub Agordoj, Privateco kaj sekureco, Uzi sekuran DNS. Ambaŭ povas esti agorditaj al specifa provizanto aŭ lasitaj malŝaltitaj, kaj kiam ili estas ŝaltitaj, la DNS-agordo de la tunelo estas preterpasata por tiuj serĉoj, kvankam la paĝa trafiko ankoraŭ uzas la tunelon.

Se la VPN sendas sian propran solvilon kaj la retumilo insistas pri sia, vi ricevas dividon: nomoj solviĝas, paĝoj ŝargiĝas, kaj la serĉoj, kiuj devis iri tra la tunelo, iris rekte eksteren. Solvila adreso malsama de la VPN-finpunkto ne estas per si mem pruvo de liko, sed serĉvojo, kiu kontraŭdiras vian deklaran intencon, indas esti riparita.

Paŝo kvar: internaj nomoj estas la loko, kie ĝi rompiĝas

Konektiĝu al labortema VPN kaj malfermu intranetajn gastiganton. Se la sekura DNS de la retumilo estas ŝaltita kaj montras al publika solvilo, tiu nomo ne ekzistas por la retumilo. La tunelo staras, ĉio alia funkcias, kaj unu gastigantnomo malsukcesas kun eraro, kiu aspektas kvazaŭ la retejo estus mallevita.

La sama paneo aperas inverse en Android. Strikta privata DNS kun publika provizanto ne solvos nomojn, kiujn konas nur la interna solvilo, kaj la strikta reĝimo havas neniun retropaŝon. Dividi la DNS de telefono inter publika ĉifrita solvilo kaj kompania solvilo ne estas agordo; ĝi estas enkursiga politika demando, kiun devas respondi tiu, kiu funkciigas la VPN-on.

Kontrolu tion antaŭ ol kulpi la tunnelon: demandu la internan nomon, poste la saman nomon kun la sekura DNS de la retumilo malŝaltita. Se ĝi solviĝas, la solvila elekto estis la problemo, ne la konekto.

Kion la trairo diras al vi ŝanĝi

Kvar ekranoj portas preskaŭ ĉion. Rigardu ilin en ĉi tiu ordo kaj skribu, kion diras ĉiu, ĉar la respondo kutime videblas en la kombinaĵo:

1. Android-agordoj, Reto kaj interreto, Privata DNS: Aŭtomata aŭ provizanta gastigantnomo, kaj kiu gastigantnomo.
2. La agordo pri sekura DNS de la retumilo: malŝaltita aŭ fiksita al specifa solvilo.
3. La DNS-politiko de la VPN-kliento: ĉu ĝi sendas solvilon, kaj ĉu dividita tunelo ekskludas ion, kio ankoraŭ bezonas nomojn?
4. Testo de interna gastigantnomo kun la tunelo staranta, farita dufoje, unufoje kun la retumila DNS ŝaltita kaj unufoje malŝaltita.

Poste adaptu la riparon al la postulo, ne inverse. Se la postulo estas, ke serĉoj eliru ĉifritaj kaj iru al solvilo, kiun vi elektis, agordu striktan privatan DNS kaj igi la retumilon konsenti. Se la postulo estas, ke trafiko eliru aliloke, agordu la tunnelon kaj ĉesu atendi, ke DNS-agordo movos vian adreson.

Kaj tenu la limojn en vidado. Neniu el la funkcioj igas malamikan cellokon sekura, kaj neniu forigas identecon, per kiu vi ensalutis. Ĉifrado ŝanĝas, kiu povas legi la demandon; la tunelo ŝanĝas, kien iras la konekto; nenio el tio anonimigas la konton.