iOS DNS-profil kontra VPN-profil: kva for ein har du?

Nokon sender deg ein iPhone-profil med eit beroligande namn, han vert installert med to trykk, og interne namn byrjar å slåast opp. Om trafikken òg går gjennom ein tunnel er eit eige spørsmål, og visingsnamnet svarar ikkje på det. Éin profil kan innehalde fleire payloadar, så det einaste pålitelege grepet er å opne han og lese kva kvar payload konfigurerer. Lista er kort, payload-namna er keisame, og svaret er som regel openbert når du har sett dei. Å gjette ut frå tittelen er korleis folk endar med å tru at trafikken deira går i tunnel når det berre er oppslaga som gjer det.

Opne payload-lista, ikkje overskrifta

På iOS ligg profillista under Innstillingar, Generelt, VPN og Einingstyring, og kvar oppføring opnar til ei payload-oversikt i staden for til éin brytar. Les den oversikta: ein payload for DNS-innstillingar, ein VPN-payload, ein proxy-payload, sertifikat, Wi-Fi. Ein profil som berre har DNS-innstillingar er ikkje ein tunnel, same kva namnet antydar, og ein som har begge gjer to ulike jobbar samstundes. Oversikta er den tekniske påstanden, og overskrifta er marknadsføring.

Tre spørsmål gjer oversikta om til ei avgjerd. Vert namneoppslaget endra, vert den offentlege kjeldeadressa endra, og kva program dekkjer kvar effekt? Ein DNS-payload svarar på det første, ein VPN-payload som regel på det andre og tredje, og noko som hevdar begge bør vise to payloadar eller ei dokumentert utviding.

Kva ein DNS-payload faktisk endrar

Ein DNS-payload endrar korleis namn vert slått opp innanfor omfanget han konfigurerer, noko som kan tyde ein bestemd resolver, ein kryptert transport som DNS over HTTPS, eller eit avgrensa sett domene. Det han normalt ikkje endrar, er den offentlege kjeldeadressa til sambanda dine, så nettstadar ser framleis nettverket du er på. Oppslag og ruting er skilde mekanismar, og berre éin av dei flytta seg. Difor kan eit internt namn slåast opp rett medan sida bak nektar å laste.

Ein DNS-payload innfører òg ein part som tek imot spørjingane dine, og viss resolver-operatøren ikkje er nettverksoperatøren, er det ein ny deltakar i banen. Noter det, for det endrar kven som kan sjå kva namn du spør etter. Han skjuler ikkje i seg sjølv måladressene du koplar til etterpå.

Kva ein VPN-payload faktisk endrar

Ein VPN-payload etablerer ein tunnel og ei rutepolitikk, og avhengig av korleis han er konfigurert kan han fange all trafikk, berre oppførte mål, eller berre oppførte program. Unntak tel like mykje som inkluderingar, sidan ein full-tunnel-profil med to utelatne domene oppfører seg heilt annleis enn namnet antydar. Per-app VPN kan la nettlesaren liggje heilt utanfor tunnelen medan merket i statuslinja seier tilkopla. Les dei inkluderte og utelatne listene før du stolar på noko av orda.

Kjeldeadressa vert endra her, i det minste for trafikken tunnelen fangar, og det er den praktiske skilnaden folk flest eigentleg spør om. Alt anna er detaljar om kva trafikk.

Der Network Extension-appar gjer etiketten uklar

Ein app kan installere si eiga Network Extension der profillista ikkje tydeleg skildrar oppførselen, så marknadsføringsnamnet og statuslinjeindikatoren er inga oversikt. Opne appen sitt eige konfigurasjonsskjermbilete ved sida av profil-payloadane og samanlikn dei to. Ein brytar merkt vern kan berre slå om oppslaget, og ein brytar merkt privat DNS kan berre endre resolveren. Der dei to kjeldene er usamde, tru på payload-lista og noter skilnaden.

Det er òg difor ein app kan klare ein rask test på eitt nettverk og feile på ein captive portal, der oppslag verkar og ruting ikkje gjer det. Dei to mekanismane var aldri same sak.

Fjern rett objekt, og sjekk namna etterpå

Fjern ein konfigurasjon gjennom appen eller administrasjonstenesta som installerte han, ved å bruke Apple sine dokumenterte fjerningstrinn i staden for å slette filer du fann. Å slette ein profil kan ta med tilhøyrande innstillingar og data, og ein styrt profil kan nekte å forlate før administrasjonssida slepp han. Å fjerne éin DNS-payload skal aldri krevje at ein urelatert VPN-identitet som eininga framleis er avhengig av, vert øydelagd. Skil objekta før du slettar noko, og fjern deretter berre det som eig oppførselen du prøver å stoppe.

Etterpå bør du sjekke dei private namna arbeidet ditt er avhengig av, for ein organisasjonsapp kan vere avhengig av ein resolver som offentleg DNS aldri har høyrt om. Den feilen viser seg vanlegvis som ein programfeil i staden for ein DNS-feil, og difor vert han feildiagnostisert. Test eitt internt namn og eitt offentleg namn frå same app, og svaret fortel deg kva objekt du faktisk fjerna.