VPN-DNS på iPhone: vem som äger inställningen avgör var den gäller

Skriv in en privat resolveradress i Wi-Fi-inställningarna på en iPhone och den fungerar tills telefonen lämnar nätverket, vilket är exakt när en VPN ska ta över. Det är den första fällan i mobil DNS: platsen där du angav inställningen definierar dess omfattning, och omfattningen är snävare än de flesta antar. Innan du redigerar något, svara på tre frågor om utrullningen, eftersom svaren avgör vilken kontroll du bör röra. Behandla sekvensen som en designgranskning och inte som en jakt på inställningar.

Tre frågor innan du skriver in en resolveradress

För det första, vilka namn behöver verkligen särskild hantering? En privat zon som corp.example är ett namnområde, inte en enda värd, och svaret bör vara en domän och inte en enda post. För det andra, vilken resolver är auktoritativ för den, och vem äger den tjänsten? För det tredje, vilken väg gör den resolvern nåbar från telefonen: tunneln, ett routat Wi-Fi-nätverk eller något helt annat?

Om någon av de tre saknar ägare, stanna. En DNS-ändring utan ett namnområde, en auktoritativ källa och en nåbar väg är en gissning som kommer att misslyckas annorlunda i mobilnätet än på kontoret.

En Wi-Fi-DNS-post tillhör det Wi-Fi-nätverket

Den manuella DNS-konfigurationen på iOS lagras per nätverk. Den gäller medan telefonen är ansluten till det SSID:et och slutar gälla när den inte är det, vilket betyder att den inte kan styra mobiltrafik eller beskriva vad en VPN-klient gör. Att redigera den för att reparera en app som misslyckas i mobilnätet är att ändra en inställning som den misslyckade vägen aldrig läser.

Det gör inte DNS per nätverk värdelöst. För ett hemmalabb eller ett enda kontors-SSID är det det enklaste sättet att nå en intern resolver, och det är ärligt om sin gräns.

VPN:ens DNS-mekanism följer protokollet och klienten

En pakettunnel-leverantör på iOS kan konfigurera DNS via Apples API för DNS-inställningar, som exponerar resolveradresser och domänmatchning för tunneln som äger anslutningen. En inbyggd IKEv2-konfiguration kan ta emot DNS via IKE-konfigurationsnyttolasten när gatewayen skickar den, men om en viss klient tillämpar det den tar emot är en implementeringsdetalj du måste verifiera. En appbaserad klient kan implementera sin helt egen upplösningsväg.

Det är olika integrationspunkter, och ett resultat från en av dem blir inte en regel för alla iPhones. Den stödda mekanismen är det som profilen eller leverantören dokumenterar för protokollet som används.

Bestäm efter ägande, inte efter bekvämlighet

Om enheten är hanterad bör profilägaren leverera DNS-inställningen tillsammans med VPN-konfigurationen, så att en ny registrering återställer den utan att en användare behöver komma ihåg något. Om en leverantörsapp äger tunneln är dess inställningsskärm stället att titta på, och dess dokumentation är auktoriteten för vad den kan dela. Om telefonen är personlig och behovet är ett internt namn på ett nätverk är inställningen per nätverk proportionerlig.

Beslutsregeln är kort: inställningen hör till där anslutningen etableras. Överallt annars är den ett lokalt undantag som nästa nätverksändring kommer att radera.

Verifiera på de vägar telefonen faktiskt använder

Testa en färsk begäran från appen som behöver det privata namnet, på Wi-Fi på kontoret, i mobilnätet och över en övergång mellan dem. En app med egen resolverintegration kan ta en annan väg än systemet, så testa själva applikationen och inte en webbläsarflik som råkar fungera.

När det privata namnet misslyckas, spara det exakta felet och profilstatusen. En offentlig resolver som svarar att namnet inte finns ger ett korrekt svar på fel fråga, och att lägga den bredvid företagets resolver är inte namnområdesdesign.

Spara slutligen den verifierade policyn tillsammans med etableringskällan. Nästa återanslutning eller registrering bör återställa samma namntjänst eftersom profilen sa det, inte för att någon kom ihåg en ändring gjord på en hotspot för två år sedan.