VPN-DNS på iPhone: hvem der ejer indstillingen afgør, hvor den gælder
En DNS-post under ét Wi-Fi-netværk er ikke en enhedsdækkende politik. Afstem det private navneområde, resolveren og ejeren af udrulningen, før du redigerer.
Skriv en privat resolveradresse i Wi-Fi-indstillingerne på en iPhone, og den virker, indtil telefonen forlader netværket, hvilket er præcis det øjeblik, hvor en VPN skal overtage. Det er den første fælde i mobil DNS: stedet, hvor du indtastede indstillingen, definerer dens rækkevidde, og rækkevidden er snævrere, end de fleste antager. Før du redigerer noget, skal du besvare tre spørgsmål om udrulningen, fordi svarene afgør, hvilken kontrol du bør røre ved. Behandl rækkefølgen som en designgennemgang frem for en jagt på indstillinger.
Tre spørgsmål, før du skriver en resolveradresse
For det første: hvilke navne har faktisk brug for særlig håndtering? En privat zone som corp.example er et navneområde, ikke en enkelt vært, og svaret bør være et domæne frem for én post. For det andet: hvilken resolver er autoritativ for den, og hvem ejer den tjeneste? For det tredje: hvilken vej gør den resolver tilgængelig fra telefonen: tunnelen, et routet Wi-Fi-netværk eller noget helt andet?
Hvis en af de tre ikke har nogen ejer, så stop. En DNS-ændring uden et navneområde, en autoritativ kilde og en tilgængelig vej er et gæt, der vil fejle anderledes på mobildata end på kontoret.
En DNS-post for Wi-Fi tilhører det Wi-Fi-netværk
Den manuelle DNS-konfiguration på iOS gemmes pr. netværk. Den gælder, mens telefonen er forbundet med det SSID, og holder op med at gælde, når den ikke er, hvilket betyder, at den ikke kan styre mobiltrafik eller beskrive, hvad en VPN-klient gør. At redigere den for at rette en app, der fejler på mobildata, er at ændre en indstilling, som den fejlende vej aldrig læser.
Det gør ikke DNS pr. netværk ubrugeligt. For et hjemmelaboratorium eller et enkelt kontor-SSID er det den enkleste måde at nå en intern resolver på, og det er ærligt om sin grænse.
VPN'ens DNS-mekanisme følger protokollen og klienten
En pakketunneludbyder på iOS kan konfigurere DNS via Apples API til DNS-indstillinger, som eksponerer resolveradresser og domænematchning for den tunnel, der ejer forbindelsen. En indbygget IKEv2-konfiguration kan modtage DNS via IKE-konfigurationspayloaden, når gatewayen sender den, men om en given klient anvender det, den modtager, er en implementeringsdetalje, du skal verificere. En appbaseret klient kan implementere sin helt egen opløsningsvej.
Det er forskellige integrationspunkter, og et resultat fra et af dem bliver ikke en regel for alle iPhones. Den understøttede mekanisme er det, profilen eller udbyderen dokumenterer for den protokol, der bruges.
Beslut ud fra ejerskab, ikke bekvemmelighed
Hvis enheden er administreret, bør profilejeren levere DNS-indstillingen sammen med VPN-konfigurationen, så en ny tilmelding gendanner den, uden at en bruger skal huske noget. Hvis en udbyderapp ejer tunnelen, er dens indstillingsskærm stedet at kigge, og dens dokumentation er autoriteten på, hvad den kan opdele. Hvis telefonen er personlig, og behovet er ét internt navn på ét netværk, er indstillingen pr. netværk passende.
Beslutningsreglen er kort: indstillingen hører til der, hvor forbindelsen udrulles. Alle andre steder er den en lokal undtagelse, som den næste netværksændring vil slette.
Verificér på de veje, telefonen faktisk bruger
Test en frisk anmodning fra den app, der har brug for det private navn, på Wi-Fi på kontoret, på mobildata og hen over en overgang mellem dem. En app med sin egen resolverintegration kan tage en anden vej end systemet, så test selve applikationen frem for en browserfane, der tilfældigvis virker.
Når det private navn fejler, skal du gemme den præcise fejl og profiltilstanden. En offentlig resolver, der svarer, at navnet ikke findes, giver et korrekt svar på det forkerte spørgsmål, og at tilføje den ved siden af virksomhedens resolver er ikke et navneområdedesign.
Gem til sidst den verificerede politik sammen med udrulningskilden. Den næste genopkobling eller tilmelding bør gendanne den samme navnetjeneste, fordi profilen sagde det, ikke fordi nogen huskede en ændring foretaget på et hotspot for to år siden.