Hvorfor Private DNS på telefonen ødelegger VPN-navneoppslag

Apper får ikke slått opp et navn mens tunnelen forblir tilkoblet og alle andre indikatorer ser friske ut. På en telefon er den vanlige årsaken en resolver som velges av enheten og ikke av VPN-profilen. To innstillinger kan hver for seg kreve myndighet over samme oppslag. Å finne ut hvilken som vinner, og om den i det hele tatt kan svare på spørsmålet, er raskere enn å røre tunnelen.

To innstillinger avgjør samme navn

Telefonens Private DNS-innstilling velger en resolver for enheten, med moduser fra automatisk valg til et navngitt vertsnavn. En VPN-profil kan skyve sin egen resolver samtidig, og de to konfigureres på forskjellige skjermer og av forskjellige eiere. Ingen av dem overstyrer nødvendigvis den andre for hver app. Derfor kan en fungerende tunnel og et mislykket oppslag eksistere samtidig uten motsigelse.

En nettleser kan legge til et tredje lag, fordi sikker DNS inne i nettleseren kan velge sin egen leverandør. Appen som produserte feilen, er den eneste pålitelige pekepinnen på hvem av de tre som svarte. Resolveren må også kunne svare. Et navn som bare finnes i bedriften, er ikke i dataene til en offentlig resolver, så oppslaget feiler på innhold og ikke på tilkobling.

Velg modusen ut fra navnene du trenger

Hvis enheten må slå opp interne navn, må resolveren være en som holder disse sonene, noe som vanligvis betyr tunnelens resolver eller en delt DNS-ordning organisasjonen dokumenterer. Hvis bare offentlige navn betyr noe, er en streng kryptert resolver et forsvarlig valg som også fjerner oppslag i klartekst. Beslutningen følger av navnene, ikke av en preferanse om kryptering.

Feilatferden varierer også etter modus. Et strengt valg som ikke når resolveren sin, gir feil for hvert navn, mens en modus med tillatt tilbakefall kan holde offentlige navn i gang og interne navn ødelagt. Forskjellen forteller deg hvilken modus du er i før du åpner en innstillingsskjerm. På en administrert enhet bestemmer den godkjente policyen, og brukeren kan ikke overstyre den trygt. På et personlig oppsett er én dokumentert sammenligning nok til å identifisere konflikten, og den tiltenkte personverninnstillingen bør gjenopprettes etterpå i stedet for å bli stående deaktivert.

Sjekk hvilken app som spør

Gjenskape feilen i appen som rapporterte den, og noter om feilen er en navnefeil eller en tilkoblingsfeil. En navnefeil fra én app og en vellykket side i en annen er signaturen til to resolvere, ikke til en ødelagt 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 kommandoene leser enhetens nåværende konfigurasjon, og produsentversjoner kan gi de underliggende verdiene nye navn eller begrense dem, så behandle utdataene som et hint og ikke som en spesifikasjon. Androids dokumentasjon om Private DNS beskriver modusene og formen på vertsnavnet en enhet forventer.

Sammenlign svaret med resolveren VPN-profilen skyver på. Hvis de er uenige, har du funnet konflikten, og det gjenstående spørsmålet er hvilken organisasjonen vil skal vinne.

Gjenopprett den tiltenkte innstillingen etter én sammenligning

Endre én innstilling, test de to navnene på nytt, og sett innstillingen tilbake. En enhet som blir stående i en tillatende modus, slår opp interne navn og sender stille hvert offentlige oppslag til den som svarer først, noe som er en personvernsendring ingen har registrert.

Skriv resultatet som en regel: interne navn slås opp via denne resolveren, offentlige via den andre, og nettleseren følger enheten eller gjør det ikke. En regel som navngir resolveren, er testbar, mens et notat om at VPN-en ble reparert, ikke er det. Sjekk deretter om noe annet på enheten avhenger av resolveren du endret. Oppdateringssjekker, registrering av captive-portaler og e-postklienter lager sine egne forespørsler, og de feiler på måter brukere rapporterer som urelaterte problemer.