Kial Private DNS en telefono rompas la nomserĉadon de VPN

Aplikaĵoj malsukcesas solvi nomon, dum la tunelo restas konektita kaj ĉiuj aliaj indikiloj ŝajnas sanaj. En telefono la kutima kaŭzo estas solvilo elektita de la aparato kaj ne de la VPN-profila. Du agordoj povas ĉiu postuli aŭtoritaton super la sama serĉo. Eltrovi, kiu venkas, kaj ĉu ĝi eĉ povas respondi la demandon, estas pli rapide ol tuŝi la tunelon.

Du agordoj decidas la saman nomon

La agordo Private DNS de telefono elektas solvilon por la aparato, kun reĝimoj de aŭtomata elekto ĝis nomita gastigantnomo. VPN-profila povas samtempe puŝi sian propran solvilon, kaj la du estas agordataj per malsamaj ekranoj kaj de malsamaj posedantoj. Neniu nepre superregas la alian por ĉiu aplikaĵo. Tial funkcianta tunelo kaj malsukcesinta serĉo kunekzistas sen kontraŭdiro.

Retumilo povas aldoni trian tavolon, ĉar sekura DNS ene de la retumilo povas elekti sian propran provizanton. La aplikaĵo, kiu produktis la eraron, estas la sola fidinda gvidilo pri tio, kiu el la tri respondis. La solvilo ankaŭ devas povi respondi. Nomo nur por la firmao ne troviĝas en la datumoj de publika solvilo, do la serĉo malsukcesas pro enhavo kaj ne pro konekto.

Elektu la reĝimon laŭ la nomoj, kiujn vi bezonas

Se la aparato devas solvi internajn nomojn, la solvilo devas esti tiu, kiu tenas tiujn zonojn, kio kutime signifas la solvilon de la tunelo aŭ disigitan DNS-aranĝon, kiun la organizo dokumentas. Se nur publikaj nomoj gravas, severa ĉifrita solvilo estas defendebla elekto, kiu ankaŭ forigas serĉojn en klara teksto. La decido sekvas el la nomoj, ne el prefero pri ĉifrado.

La konduto ĉe fiasko ankaŭ varias laŭ reĝimo. Severa elekto, kiu ne povas atingi sian solvilon, produktas fiaskon por ĉiu nomo, dum reĝimo kun permesita retrofalo povas teni publikajn nomojn funkciantaj kaj internajn rompitaj. Tiu diferenco diras al vi, en kiu reĝimo vi estas, antaŭ ol vi malfermi agordan ekranon. En administrata aparato decidas la aprobita politiko, kaj la uzanto ne povas sekure superregi ĝin. En persona agordo unu dokumentita komparo sufiĉas por identigi la konflikton, kaj la celata privateca agordo estu restarigita poste anstataŭ lasita malŝaltita.

Kontrolu, kiu aplikaĵo demandas

Ripetu la fiaskon en la aplikaĵo, kiu raportis ĝin, kaj notu, ĉu la eraro estas nomera aŭ konekta. Nomeraro en unu aplikaĵo kaj sukcesa paĝo en alia estas la signo de du solviloj, ne de rompita tunelo.

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

Tiuj komandoj legas la nunan agordon de la aparato, kaj fabrikaj versioj povas alinomi aŭ limigi la subajn valorojn, do traktu la eligon kiel indikon kaj ne kiel specifon. La dokumentaro de Android pri Private DNS priskribas la reĝimojn kaj la formon de gastigantnomo, kiun aparato atendas.

Komparu tiun respondon kun la solvilo, kiun la VPN-profila puŝas. Se ili malkongruas, vi trovis la konflikton, kaj restas la demando, kiun la organizo intencas venkigi.

Restarigu la celatan agordon post unu komparo

Ŝanĝu unu agordon, retestu la du nomojn kaj remetu la agordon. Aparato lasita en permesa reĝimo solvas internajn nomojn kaj silente sendas ĉiun publikan serĉon al tiu, kiu respondos unue, kio estas privateca ŝanĝo, kiun neniu registris.

Skribu la rezulton kiel regulon: internaj nomoj solviĝas per ĉi tiu solvilo, publikaj per tiu, kaj la retumilo sekvas aŭ ne sekvas la aparaton. Regulo, kiu nomas la solvilon, estas testebla, dum noto, ke la VPN estis riparita, ne estas. Poste kontrolu, ĉu io alia en la aparato dependas de la solvilo, kiun vi ŝanĝis. Ĝisdatigaj kontroloj, detekto de kaptitaj portaloj kaj retpoŝtaj klientoj faras siajn proprajn petojn, kaj ili malsukcesas tiel, ke uzantoj raportas ilin kiel ne rilatajn problemojn.