VPN-DNS på iPhone: hvem som eier innstillingen avgjør hvor den gjelder

Skriv inn en privat resolveradresse i Wi-Fi-innstillingene på en iPhone, og den virker til telefonen forlater nettverket – som er nøyaktig når en VPN skal ta over. Det er den første fellen i mobil DNS: stedet der du la inn innstillingen, definerer dens omfang, og omfanget er smalere enn de fleste antar. Før du redigerer noe, svar på tre spørsmål om utrullingen, fordi svarene bestemmer hvilken kontroll du bør røre. Behandle rekkefølgen som en designgjennomgang og ikke som en jakt på innstillinger.

Tre spørsmål før du skriver en resolveradresse

For det første, hvilke navn trenger egentlig spesiell behandling? En privat sone som corp.example er et navnerom, ikke én vert, og svaret bør være et domene og ikke én oppføring. For det andre, hvilken resolver er autoritativ for den, og hvem eier den tjenesten? For det tredje, hvilken vei gjør den resolveren tilgjengelig fra telefonen: tunnelen, et rutet Wi-Fi-nettverk eller noe helt annet?

Hvis noen av de tre ikke har en eier, stopp. En DNS-endring uten et navnerom, en autoritativ kilde og en tilgjengelig vei er en gjetning som vil feile annerledes på mobilnettet enn på kontoret.

En Wi-Fi-DNS-oppføring tilhører det Wi-Fi-nettverket

Den manuelle DNS-konfigurasjonen på iOS lagres per nettverk. Den gjelder mens telefonen er tilkoblet den SSID-en og slutter å gjelde når den ikke er, noe som betyr at den ikke kan styre mobiltrafikk eller beskrive hva en VPN-klient gjør. Å redigere den for å reparere en app som feiler på mobilnettet, er å endre en innstilling som den feilende veien aldri leser.

Det gjør ikke DNS per nettverk ubrukelig. For et hjemmelaboratorium eller én kontor-SSID er det den enkleste måten å nå en intern resolver, og det er ærlig om grensen sin.

VPN-ens DNS-mekanisme følger protokollen og klienten

En pakketunnel-leverandør på iOS kan konfigurere DNS via Apples API for DNS-innstillinger, som eksponerer resolveradresser og domenematching for tunnelen som eier tilkoblingen. En innebygd IKEv2-konfigurasjon kan motta DNS via IKE-konfigurasjonsnyttelasten når gatewayen sender den, men om en gitt klient anvender det den mottar, er en implementasjonsdetalj du må verifisere. En appbasert klient kan implementere sin helt egen oppløsningsvei.

Det er forskjellige integrasjonspunkter, og et resultat fra ett av dem blir ikke en regel for alle iPhone-er. Den støttede mekanismen er det profilen eller leverandøren dokumenterer for protokollen som brukes.

Bestem etter eierskap, ikke bekvemmelighet

Hvis enheten er administrert, bør profileieren levere DNS-innstillingen sammen med VPN-konfigurasjonen, slik at en ny registrering gjenoppretter den uten at en bruker trenger å huske noe. Hvis en leverandørapp eier tunnelen, er innstillingsskjermen dens stedet å se, og dokumentasjonen dens er autoriteten på hva den kan dele. Hvis telefonen er personlig og behovet er ett internt navn på ett nettverk, er innstillingen per nettverk passende.

Beslutningsregelen er kort: innstillingen hører til der tilkoblingen klargjøres. Alle andre steder er den et lokalt unntak som den neste nettverksendringen vil slette.

Verifiser på veiene telefonen faktisk bruker

Test en fersk forespørsel fra appen som trenger det private navnet, på Wi-Fi på kontoret, på mobilnettet og over en overgang mellom dem. En app med egen resolverintegrasjon kan ta en annen vei enn systemet, så test selve applikasjonen og ikke en nettleserfane som tilfeldigvis virker.

Når det private navnet feiler, ta vare på den nøyaktige feilen og profilstatusen. En offentlig resolver som svarer at navnet ikke finnes, gir et korrekt svar på feil spørsmål, og å legge den ved siden av bedriftens resolver er ikke navneromsdesign.

Til slutt, lagre den verifiserte policyen sammen med klargjøringskilden. Den neste gjenoppkoblingen eller registreringen bør gjenopprette samme navnetjeneste fordi profilen sa det, ikke fordi noen husket en endring gjort på ett hotspot for to år siden.