Kvifor Private DNS på telefonen øydelegg VPN-namneoppslag

Appar får ikkje slått opp eit namn medan tunnelen er tilkopla og alle andre indikatorar ser friske ut. På ein telefon er den vanlege årsaka ein resolver som blir vald av eininga og ikkje av VPN-profilen. To innstillingar kan kvar for seg krevje myndigheit over same oppslag. Å finne ut kven som vinn, og om han i det heile kan svare på spørsmålet, er raskare enn å røre tunnelen.

To innstillingar avgjer same namn

Private DNS-innstillinga på telefonen vel ein resolver for eininga, med modus frå automatisk val til eit namngitt vertsnamn. Ein VPN-profil kan skyve sin eigen resolver samtidig, og dei to blir konfigurerte på ulike skjermar og av ulike eigarar. Ingen av dei overstyrer nødvendigvis den andre for kvar app. Difor kan ein fungerande tunnel og eit mislukka oppslag eksistere samtidig utan motseling.

Ein nettlesar kan leggje til eit tredje lag, fordi sikker DNS inne i nettlesaren kan velje sin eigen leverandør. Appen som skapte feilen, er den einaste pålitelege peikepinnen på kven av dei tre som svara. Resolveren må også kunne svare. Eit namn som berre finst i verksemda, er ikkje i dataa til ein offentleg resolver, så oppslaget feilar på innhald og ikkje på tilkopling.

Vel modusen ut frå namna du treng

Viss eininga må slå opp interne namn, må resolveren vere ein som held desse sonene, noko som vanlegvis betyr resolveren til tunnelen eller ei delt DNS-ordning som organisasjonen dokumenterer. Viss berre offentlege namn tel, er ein streng kryptert resolver eit forsvarleg val som også fjernar oppslag i klartekst. Avgjerda følgjer av namna, ikkje av ei preferanse om kryptering.

Feilåtferda varierer også etter modus. Eit strengt val som ikkje når resolveren sin, gir feil for kvart namn, medan ein modus med tillaten tilbakefall kan halde offentlege namn i gang og interne namn øydelagde. Skilnaden fortel deg kva for modus du er i før du opnar ein innstillingsskjerm. På ei styrt eining avgjer den godkjende politikken, og brukaren kan ikkje overstyre han trygt. I eit personleg oppsett er éin dokumentert samanlikning nok til å identifisere konflikten, og den tiltenkte personverninnstillinga bør gjenopprettast etterpå i staden for å bli ståande avslegen.

Sjekk kva app som spør

Gjenskap feilen i appen som rapporterte han, og noter om feilen er ein namnefeil eller ein tilkoplingsfeil. Ein namnefeil frå éin app og ei vellukka side i ein annan er signaturen til to resolverar, ikkje til ein øydelagd 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

Desse kommandoane les den noverande konfigurasjonen til eininga, og produsentversjonar kan gje dei underliggjande verdiane nye namn eller avgrense dei, så handsam utdataa som eit hint og ikkje som ein spesifikasjon. Android-dokumentasjonen om Private DNS skildrar modusane og forma på vertsnamnet som ei eining ventar.

Samanlikn svaret med resolveren som VPN-profilen skyv på. Viss dei er usamde, har du funne konflikten, og det attverande spørsmålet er kven organisasjonen vil skal vinne.

Gjenopprett den tiltenkte innstillinga etter éi samanlikning

Endre éi innstilling, test dei to namna på nytt, og set innstillinga tilbake. Ei eining som blir ståande i ein tillatande modus, slår opp interne namn og sender stille kvart offentleg oppslag til den som svarar først, noko som er ei personvernsendring ingen har registrert.

Skriv resultatet som ein regel: interne namn blir slått opp via denne resolveren, offentlege via den andre, og nettlesaren følgjer eininga eller gjer det ikkje. Ein regel som namngir resolveren, er testbar, medan eit notat om at VPN-en vart reparert, ikkje er det. Sjekk deretter om noko anna på eininga er avhengig av resolveren du endra. Oppdateringssjekkar, registrering av captive-portalar og e-postklientar lagar sine eigne førespurnader, og dei feilar på måtar brukarar rapporterer som urelaterte problem.