VPN-DNS på iPhone: kven som eig innstillinga avgjer kvar ho gjeld

Skriv inn ei privat resolveradresse i Wi-Fi-innstillingane på ein iPhone, og ho verkar til telefonen forlèt nettverket – som er nøyaktig når ein VPN skal ta over. Det er den første fella i mobil DNS: staden der du la inn innstillinga, definerer omfanget hennar, og omfanget er smalare enn dei fleste reknar med. Før du redigerer noko, svar på tre spørsmål om utrullinga, fordi svara avgjer kva kontroll du bør røre. Handsame rekkjefølgja som ein designgjennomgang og ikkje som ein jakt på innstillingar.

Tre spørsmål før du skriv ei resolveradresse

For det første, kva namn treng eigentleg særskild handsaming? Ei privat sone som corp.example er eit namnerom, ikkje éin vert, og svaret bør vere eit domene og ikkje éi oppføring. For det andre, kva resolver er autoritativ for ho, og kven eig den tenesta? For det tredje, kva veg gjer den resolveren tilgjengeleg frå telefonen: tunnelen, eit ruta Wi-Fi-nettverk eller noko heilt anna?

Dersom nokon av dei tre ikkje har ein eigar, stopp. Ei DNS-endring utan eit namnerom, ei autoritativ kjelde og ein tilgjengeleg veg er ei gjetting som vil feile annleis på mobilnettet enn på kontoret.

Ei Wi-Fi-DNS-oppføring høyrer til det Wi-Fi-nettverket

Den manuelle DNS-konfigurasjonen på iOS blir lagra per nettverk. Han gjeld medan telefonen er tilkopla den SSID-en og sluttar å gjelde når han ikkje er det, noko som tyder at han ikkje kan styre mobiltrafikk eller skildre kva ein VPN-klient gjer. Å redigere han for å reparere ein app som feilar på mobilnettet, er å endre ei innstilling som den feilande vegen aldri les.

Det gjer ikkje DNS per nettverk unyttig. For eit heimelaboratorium eller éin kontor-SSID er det den enklaste måten å nå ein intern resolver, og det er ærleg om grensa si.

DNS-mekanismen til VPN følgjer protokollen og klienten

Ein pakketunnel-leverandør på iOS kan konfigurere DNS via Apples API for DNS-innstillingar, som eksponerer resolveradresser og domenematching for tunnelen som eig tilkopletninga. Ein innebygd IKEv2-konfigurasjon kan motta DNS via IKE-konfigurasjonsnyttelasta når gatewayen sender henne, men om ein gild klient nyttar det han mottek, er ein implementasjonsdetalj du må verifisere. Ein appbasert klient kan implementere sin heilt eigen oppløysingsveg.

Det er ulike integrasjonspunkt, og eit resultat frå eitt av dei blir ikkje ein regel for alle iPhone-ar. Den støtta mekanismen er det profilen eller leverandøren dokumenterer for protokollen som blir brukt.

Avgjer etter eigarskap, ikkje etter kvilegheit

Dersom eininga er styrt, bør profileigaren levere DNS-innstillinga saman med VPN-konfigurasjonen, slik at ei ny registrering gjenopprettar henne utan at ein brukar treng å hugse noko. Dersom ein leverandørapp eig tunnelen, er innstillingsskjermen hans staden å sjå, og dokumentasjonen hans er autoriteten på kva han kan dele. Dersom telefonen er personleg og behovet er eitt internt namn på eitt nettverk, er innstillinga per nettverk passande.

Avgjerdsregelen er kort: innstillinga høyrer til der tilkoplinga blir klargjord. Alle andre stader er ho eit lokalt unntak som den neste nettverksendra vil slette.

Verifiser på vegane telefonen faktisk brukar

Test ein fersk førespurnad frå appen som treng det private namnet, på Wi-Fi på kontoret, på mobilnettet og over ein overgang mellom dei. Ein app med eigen resolverintegrasjon kan ta ein annan veg enn systemet, så test sjølve applikasjonen og ikkje ei nettlesarfane som tilfeldigvis verkar.

Når det private namnet feilar, ta vare på den nøyaktige feilen og profilstatusen. Ein offentleg resolver som svarar at namnet ikkje finst, gir eit korrekt svar på feil spørsmål, og å leggje han ved sida av bedrifta sin resolver er ikkje namneromsdesign.

Til slutt, lagre den verifiserte policyen saman med klargjeringskjelda. Den neste gjenoppkoplinga eller registreringa bør gjenopprette same namnetenesta fordi profilen sa det, ikkje fordi nokon hugsa ei endring gjord på eitt hotspot for to år sidan.