DNS de VPN kontraŭ DoH en la retumilo: kion sekureca testo ne povas diri al vi

La paĝo de la lika testo diras, ke via DNS estas bona, la insigno de la retumilo diras sekura, kaj la interna vikio ankoraŭ ne ŝargiĝas. Ĉiuj tri povas esti veraj samtempe, ĉar la adreso de solvilo ne estas la sama afero kiel la politiko, kiu elektis ĝin, aŭ la vojo, kiun iris la demando. Tio, kion homoj nomas DNS-liko, fakte estas unu demando: kiu solvilo ricevis la nomon, kaj ĉu tiu elekto estis intenca? Ordigo de tio postulas tri kontrolojn, kaj nur la lasta implikas ŝanĝi agordon.

Mito unu: la insigno nomas vian solvilon

Lika testo solvas provan nomon kaj raportas la adreson, kiu respondis. Ĝi ne raportas la politikon, kiu elektis tiun solvilon, kaj kiam la demando estas envolvita en DNS super HTTPS, meza skatolo sur la vojo tute ne povas vidi la nomon. Du tre malsamaj maŝinoj produktas la saman trankviligan insignon: unu, kie la VPN puŝis 10.8.0.1 kaj la retumilo uzas ĝin, kaj unu, kie la retumilo ignoris la sisteman liston kaj sendis la nomon tra la tunelo al sia propra ĉifrita provizanto.

La distingo gravas en la momento, kiam privata nomo malsukcesas. En la unua agordo la solvilo de la VPN respondas por la entreprena zono; en la dua la retumilo neniam demandis ĝin, do la mallonga gastigantnomo ne solviĝas kaj la paneo aspektas kiel rompita VPN. La kontrolo ne estas plia lika testo, ĝi estas serĉo pri nomo, kiun nur unu solvilo konas.

Mito du: la retumilo forlasas la tunelon

DNS elektas adreson, enkursigado portas la konekton, kaj tiuj estas du apartaj tavoloj. Demando sendita al publika DoH-provizanto ankoraŭ estas TCP pordo 443 al enkursigebla adreso. Se via enkursiga tabelo sendas la defaŭltan vojon en la tunelon, tiu demando ankaŭ iras tra la tunelo. La marko de la solvilo ne decidas la vojon.

Tio, kion retumila DoH ŝanĝas, estas la ricevanto de la nomoj. Tio estas vera privateca decido kaj vera politika decido, sed ĝi ne estas ĉirkaŭiro de enkursigado. Se via postulo estas, ke nomoj restu ĉe la VPN-operatoro, ĉifrita demando al iu alia malsukcesas tiun postulon dum ĝi ankoraŭ uzas la tunelon por la efektiva konekto.

Mito tri: ĉiu VPN superregas ĉiun retumilon

Sekura DNS en retumilo havas reĝimojn, ne ŝaltilon: malŝalta, defaŭlta provizanto kun rezerva, propra ŝablono, aŭ politiko devigita de la operaciumo aŭ la organizo. La rezerva kazo estas tiu, kiu produktas intermitajn raportojn. Kiam la ĉifrita finpunkto neatingeblas, la retumilo povas reiri al la sistema solvilo, do la sama tekkomputilo solvas privatan nomon ĝuste lunde kaj ne marde.

Samtempe, plej multaj VPN-klientoj agordas la sisteman solvilon kiam la konekto leviĝas kaj restarigas la antaŭan kiam ĝi falas. Retumilo tenanta propran ĉifritan solvilon tute ne rimarkas tiun restarigon. Tial la sama profilo kondutas malsame sur du tekkomputiloj kaj tial resolv.conf aspektas ĝuste dum la retumilo ankoraŭ demandas iun alian.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Rulu tiujn dum vi estas konektita, notu, kiujn domajnojn ĉiu solvilo postulas, kaj komparu kun tio, kion la retumilo raportas pri sia propra reĝimo. La DoH-dokumentaro de Mozilla estas racia priskribo de tio, kiel la defaŭlta kaj rezerva konduto de retumilo devus funkcii.

La decido havas tri enigojn, ne unu

Privataj nomoj, fido al la operatoro kaj atingeblo decidas la ĝustan aranĝon. Nomoj, kiujn nur la VPN-solvilo konas, devigas dividitan DNS: la privata sufikso iras al la puŝita solvilo, ĉio alia sekvas la politikon, kiun vi elektis por publikaj nomoj. Fido al la operatoro decidas, ĉu publikaj nomoj ankaŭ iru al tiu solvilo aŭ al aparta servo. Atingeblo decidas, ĉu via elektita ĉifrita solvilo entute estas uzebla en ĉi tiu reto.

Neniu el tiuj linioj estas universala rekomendo. Solvilo funkciigata de la VPN koncentras observojn ĉe tiu operatoro; aparta servo aldonas alian ricevanton de la demanditaj nomoj. Neniu el la aranĝoj pruvas ion pri retenado, se vi ne legas la politikon.

Skribu la decidon por ĉiu profilo, ĉar tiuj agordoj drivas. Profilo, kiu puŝis solvilon pasintmonate, eble hodiaŭ puŝas nenion, kaj la retumilo volonte konservos malnovan propran finpunkton, kiu ankoraŭ respondas. En la noto apartenas la adreso de la solvilo, la sufiksoj, kiujn ĝi posedas, kaj la retumila reĝimo, ne la marko de la servo.

Testu la politikon, kiun vi pensas, ke vi agordis

Testu laŭ nomo, ne laŭ insigno. Solvu publikan nomon kaj privatan nomon per la sistema solvilo, poste ripetu ene de la retumilo kun ĝia propra sekura DNS-agordo en la reĝimo, kiun vi intencas uzi. Se la privata nomo malsukcesas nur en la retumilo, vi trovis la miskongruon de ricevanto sen tuŝi eĉ unu VPN-agordon.

Poste rekonektu kaj kontrolu la restarigon, ĉar ĝuste tie loĝas la transdonaj cimoj: malkonektu, konfirmu, ke la antaŭa solvilo revenis, rekonektu, konfirmu, ke la puŝita revenis. Fine, testu retumilon kun administrata politiko, se vi havas unu, ĉar tiu reĝimo povas tute rifuzi vian ŝanĝon kaj silente teni la antaŭan solvilon.

Komencu per la demando pri nomspaco kaj vi evitos la plej grandan parton de ĉi tio. Se la maŝino devas atingi internajn nomojn, la ĉifrita solvilo de la retumilo estas decido nur pri la publika duono, kaj la privata duono restas ĉe tio, kion ajn la VPN puŝis.