DNS-profil kontra VPN-profil på iOS: hvilken har du?

Nogen sender dig en iPhone-profil med et beroligende navn, den installeres med to tryk, og interne navne begynder at blive opløst. Om trafikken også kører gennem en tunnel, er et separat spørgsmål, og det viste navn svarer ikke på det. En profil kan bære flere nyttelaster, så det eneste pålidelige træk er at åbne den og læse, hvad hver last konfigurerer. Listen er kort, lasternes navne er kedelige, og svaret er som regel indlysende, når man først har set dem. Det er gætteriet ud fra titlen, der får folk til at tro, at deres trafik kører gennem en tunnel, mens det kun er deres opslag, der gør det.

Åbn listen over nyttelaster, ikke overskriften

På iOS ligger profillisten under Indstillinger, Generelt, VPN og Enhedsstyring, og hver post åbner til en vareliste over nyttelaster i stedet for en enkelt kontakt. Læs den vareliste: en last med DNS-indstillinger, en VPN-last, en proxylast, certifikater, Wi-Fi. En profil, der kun bærer DNS-indstillinger, er ikke en tunnel, uanset hvad navnet antyder, og en der bærer begge, udfører to forskellige opgaver på én gang. Varelisten er den tekniske påstand, og overskriften er markedsføring.

Tre spørgsmål gør varelisten til en beslutning. Ændres navneopløsningen, ændres den offentlige kildeadresse, og hvilke programmer dækker hver effekt? En DNS-last svarer på det første, en VPN-last svarer som regel på det andet og tredje, og alt der hævder begge, skal vise to laster eller en dokumenteret udvidelse.

Hvad en DNS-last egentlig ændrer

En DNS-last ændrer, hvordan navne opløses inden for dens konfigurerede område, hvilket kan betyde en bestemt resolver, en krypteret transport som DNS over HTTPS eller et begrænset sæt domæner. Det, den normalt ikke ændrer, er den offentlige kildeadresse for dine forbindelser, så websteder ser stadig det netværk, du er på. Opløsning og routing er separate mekanismer, og kun én af dem flyttede sig. Derfor kan et internt navn opløses korrekt, mens siden bag det nægter at indlæse.

En DNS-last indfører også en part, der modtager dine forespørgsler, og hvis resolveroperatøren ikke er netværksoperatøren, er det en ny deltager på vejen. Notér det, fordi det ændrer, hvem der kan se, hvilke navne du spørger om. Den skjuler ikke i sig selv de destinationsadresser, du bagefter opretter forbindelse til.

Hvad en VPN-last egentlig ændrer

En VPN-last etablerer en tunnel og en routingpolitik, og afhængigt af konfigurationen kan den fange al trafik, kun de listede destinationer eller kun de listede programmer. Undtagelser betyder lige så meget som inkluderinger, fordi en fuldtunnelprofil med to undtagne domæner slet ikke opfører sig, som navnet antyder. VPN for hvert program kan lade browseren være helt uden for tunnelen, mens badge i statuslinjen siger forbundet. Læs listerne over inkluderede og undtagne, før du tror på et af de to ord.

Kildeadressen ændres faktisk her, i det mindste for den trafik tunnelen fanger, og det er den praktiske forskel, de fleste egentlig spørger om. Alt andet er detaljer om hvilken trafik.

Hvor apps med Network Extension slører etiketten

En app kan installere sin egen Network Extension, hvis adfærd profillisten ikke tydeligt beskriver, så markedsføringsnavnet og statuslinjens indikator er ikke en vareliste. Åbn appens egen konfigurationsskærm ved siden af profilens nyttelaster og sammenlign de to. En kontakt mærket beskyttelse skifter måske kun opløsning, og en kontakt mærket private DNS skifter måske kun resolveren. Hvor de to kilder er uenige, tro på listen over nyttelaster og notér forskellen.

Derfor kan en app bestå en hurtig test på ét netværk og fejle på en captive portal, hvor opløsning virker, og routing ikke gør. De to mekanismer har aldrig været det samme.

Fjern det rigtige objekt, og tjek navnene bagefter

Fjern en konfiguration via den app eller styringstjeneste, der installerede den, ved at bruge Apples dokumenterede fjernelsestrin i stedet for at slette filer, du har fundet. Sletning af en profil kan tage tilknyttede indstillinger og data med sig, og en administreret profil kan nægte at forsvinde, indtil styringssiden frigiver den. Fjernelse af én DNS-last bør aldrig kræve, at man ødelægger en urelateret VPN-identitet, som enheden stadig er afhængig af. Adskil objekterne, før du sletter noget, og fjern derefter kun det, der ejer den adfærd, du prøver at stoppe.

Tjek derefter de private navne, som dit arbejde afhænger af, fordi en organisationsapp kan være afhængig af en resolver, som offentlig DNS aldrig har hørt om. En sådan fejl viser sig normalt som en appfejl snarere end en DNS-fejl, og derfor bliver den fejldiagnosticeret. Test ét internt navn og ét offentligt navn fra den samme app, og svaret fortæller dig, hvilket objekt du faktisk fjernede.