Varför Private DNS på telefonen bryter VPN:ns namnuppslag

Appar kan inte slå upp ett namn medan tunneln förblir ansluten och alla andra indikatorer ser friska ut. På en telefon är den vanliga orsaken en resolver som väljs av enheten och inte av VPN-profilen. Två inställningar kan var för sig göra anspråk på myndighet över samma uppslag. Att ta reda på vilken som vinner, och om den ens kan svara på frågan, går snabbare än att röra tunneln.

Två inställningar avgör samma namn

Telefonens Private DNS-inställning väljer en resolver för enheten, med lägen från automatiskt val till ett namngivet värdnamn. En VPN-profil kan samtidigt trycka in sin egen resolver, och de två konfigureras på olika skärmar och av olika ägare. Ingen av dem åsidosätter nödvändigtvis den andra för varje app. Därför kan en fungerande tunnel och ett misslyckat uppslag samexistera utan motsägelse.

En webbläsare kan lägga till ett tredje lager, eftersom säker DNS inuti webbläsaren kan välja sin egen leverantör. Appen som orsakade felet är den enda pålitliga ledtråden till vem av de tre som svarade. Resolvern måste också kunna svara. Ett namn som bara finns inom företaget finns inte i en offentlig resolvers data, så uppslaget misslyckas på innehåll och inte på anslutning.

Välj läge utifrån namnen du behöver

Om enheten måste slå upp interna namn måste resolvern vara en som håller dessa zoner, vilket vanligtvis betyder tunnelns resolver eller en delad DNS-ordning som organisationen dokumenterar. Om bara offentliga namn spelar roll är en strikt krypterad resolver ett försvarbart val som också tar bort uppslag i klartext. Beslutet följer av namnen, inte av en preferens om kryptering.

Feletbeteendet varierar också beroende på läge. Ett strikt val som inte når sin resolver ger fel för varje namn, medan ett läge med tillåtet återfall kan hålla offentliga namn igång och interna namn trasiga. Den skillnaden säger vilket läge du är i innan du öppnar en inställningsskärm. På en hanterad enhet bestämmer den godkända policyn och användaren kan inte kringgå den på ett säkert sätt. I en personlig uppsättning räcker en dokumenterad jämförelse för att identifiera konflikten, och den avsedda integritetsinställningen bör återställas efteråt i stället för att lämnas avstängd.

Kontrollera vilken app som frågar

Reproducera felet i appen som rapporterade det, och notera om felet är ett namnfel eller ett anslutningsfel. Ett namnfel från en app och en lyckad sida i en annan är signaturen för två resolvrar, inte för en trasig 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

De kommandona läser enhetens nuvarande konfiguration, och tillverkarnas versioner kan byta namn på eller begränsa de underliggande värdena, så behandla utdata som en antydan och inte som en specifikation. Androids dokumentation om Private DNS beskriver lägena och formen på värdnamnet som en enhet förväntar sig.

Jämför det svaret med resolvern som VPN-profilen trycker in. Om de inte stämmer överens har du hittat konflikten, och den återstående frågan är vilken organisationen vill ska vinna.

Återställ den avsedda inställningen efter en jämförelse

Ändra en inställning, testa de två namnen igen, och sätt tillbaka inställningen. En enhet som lämnas i ett tillåtande läge slår upp interna namn och skickar tyst varje offentligt uppslag till den som svarar först, vilket är en integritetsändring som ingen har registrerat.

Skriv resultatet som en regel: interna namn slås upp via denna resolver, offentliga via den andra, och webbläsaren följer enheten eller gör det inte. En regel som namnger resolvern är testbar, medan en anteckning om att VPN:en reparerades inte är det. Kontrollera sedan om något annat på enheten beror på resolvern du ändrade. Uppdateringskontroller, identifiering av captive-portaler och e-postklienter gör egna förfrågningar, och de misslyckas på sätt som användare rapporterar som orelaterade problem.