Hvorfor Private DNS på telefonen ødelægger VPN-navneopslag

Apps kan ikke slå et navn op, mens tunnelen forbliver forbundet, og alle andre indikatorer ser sunde ud. På en telefon er den sædvanlige årsag en resolver, der vælges af enheden i stedet for af VPN-profilen. To indstillinger kan hver især gøre krav på myndighed over det samme opslag. At finde ud af, hvilken der vinder, og om den overhovedet kan svare på spørgsmålet, er hurtigere end at røre ved tunnelen.

To indstillinger afgør det samme navn

Telefonens Private DNS-indstilling vælger en resolver til enheden, med tilstande fra automatisk valg til et navngivet værtsnavn. En VPN-profil kan samtidig skubbe sin egen resolver frem, og de to konfigureres på forskellige skærme og af forskellige ejere. Ingen af dem tilsidesætter nødvendigvis den anden for hver app. Derfor kan en fungerende tunnel og et fejlende opslag eksistere samtidig uden modsigelse.

En browser kan tilføje et tredje lag, fordi sikker DNS i browseren kan vælge sin egen udbyder. Det program, der frembragte fejlen, er den eneste pålidelige vejledning til, hvem af de tre der svarede. Resolveren skal også kunne svare. Et navn, der kun findes i virksomheden, findes ikke i en offentlig resolvers data, så opslaget fejler på indhold i stedet for på forbindelse.

Vælg tilstanden ud fra de navne, du har brug for

Hvis enheden skal slå interne navne op, skal resolveren være en, der rummer disse zoner, hvilket normalt betyder tunnelens resolver eller en opdelt DNS-ordning, som organisationen dokumenterer. Hvis kun offentlige navne betyder noget, er en streng krypteret resolver et forsvarligt valg, som også fjerner opslag i klartekst. Beslutningen følger af navnene, ikke af en præference om kryptering.

Fejladfærden varierer også efter tilstand. Et strengt valg, der ikke kan nå sin resolver, giver fejl for hvert navn, mens en tilstand med tilladt tilbagefald kan holde offentlige navne kørende og interne navne brudt. Forskellen fortæller dig, hvilken tilstand du er i, før du åbner en indstillingsskærm. På en administreret enhed bestemmer den godkendte politik, og brugeren kan ikke tilsidesætte den sikkert. På en personlig opsætning er én dokumenteret sammenligning nok til at identificere konflikten, og den tilsigtede privatlivsindstilling bør gendannes bagefter i stedet for at forblive deaktiveret.

Tjek, hvilken app der spørger

Genskab fejlen i det program, der rapporterede den, og noter, om fejlen er en navnefejl eller en forbindelsesfejl. En navnefejl fra en app og en vellykket side i en anden er signaturen på to resolvere, ikke på en brudt tunnel.

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

Disse kommandoer læser enhedens aktuelle konfiguration, og producenternes builds kan omdøbe eller begrænse de underliggende værdier, så betragt output som et hint, ikke som en specifikation. Androids dokumentation om Private DNS beskriver tilstandene og den værtsnavnform, en enhed forventer.

Sammenlign det svar med den resolver, VPN-profilen skubber frem. Hvis de er uenige, har du fundet konflikten, og det resterende spørgsmål er, hvilken af dem organisationen vil have til at vinde.

Gendan den tilsigtede indstilling efter én sammenligning

Ændr én indstilling, test de to navne igen, og sæt indstillingen tilbage. En enhed, der efterlades i en tilladende tilstand, slår interne navne op og sender stille hvert offentligt opslag til den, der svarer først, hvilket er en privatlivsændring, som ingen har registreret.

Skriv resultatet som en regel: interne navne slås op via denne resolver, offentlige via den anden, og browseren følger enheden eller gør ikke. En regel, der navngiver resolveren, kan testes, mens en note om, at VPN'en blev rettet, ikke kan. Tjek derefter, om noget andet på enheden afhænger af den resolver, du ændrede. Opdateringstjek, registrering af captive-portaler og mailklienter laver alle deres egne anmodninger, og de fejler på måder, som brugerne rapporterer som urelaterede problemer.