iPhone VPN-DNS: wie die instelling besit, bepaal waar dit geld

Tik 'n private resolver-adres in die Wi-Fi-instellings van 'n iPhone en dit sal werk totdat die foon daardie netwerk verlaat, en dit is presies wanneer 'n VPN veronderstel is om oor te neem. Dit is die eerste valstrik in mobiele DNS: die plek waar jy die instelling ingevoer het, bepaal die omvang daarvan, en die omvang is smaller as wat die meeste mense aanneem. Voordat jy enigiets wysig, beantwoord drie vrae oor die ontplooiing, want die antwoorde bepaal watter beheer jy behoort te raak. Behandel die volgorde as 'n ontwerphersiening eerder as 'n soektog na instellings.

Drie vrae voordat jy 'n resolver-adres intik

Eerstens, watter name het werklik spesiale hantering nodig? 'n Private sone soos corp.example is 'n naamruimte, nie 'n enkele gasheer nie, en die antwoord behoort 'n domein te wees eerder as een rekord. Tweedens, watter resolver is gesaghebbend daarvoor, en wie besit daardie diens? Derdens, watter pad maak daardie resolver bereikbaar vanaf die foon: die tonnel, 'n geroteerde Wi-Fi-netwerk, of iets heeltemal anders.

As enige van daardie drie geen eienaar het nie, stop. 'n DNS-verandering wat sonder 'n naamruimte, 'n gesaghebbende bron en 'n bereikbare pad gemaak word, is 'n raaiskoot wat anders op sellulêr sal misluk as in die kantoor.

'n Wi-Fi-DNS-inskrywing behoort aan daardie Wi-Fi-netwerk

Die handmatige DNS-konfigurasie op iOS word per netwerk gestoor. Dit geld terwyl die foon met daardie SSID geassosieer is en hou op geld wanneer dit nie is nie, wat beteken dit kan nie sellulêre verkeer beheer of beskryf wat 'n VPN-kliënt doen nie. Om dit te wysig om 'n app reg te maak wat op sellulêr misluk, is 'n verandering aan 'n instelling wat die falende pad nooit lees nie.

Dit maak per-netwerk-DNS nie nutteloos nie. Vir 'n tuislaboratorium of 'n enkele kantoor-SSID is dit die eenvoudigste manier om 'n interne resolver te bereik, en dit is eerlik oor sy grens.

Die VPN se DNS-meganisme volg die protokol en die kliënt

'n Pakkettunnel-verskaffer op iOS kan DNS konfigureer deur Apple se DNS-instellings-API, wat resolver-adresse en domeinpassing blootstel aan die tonnel wat die verbinding besit. 'n Inheemse IKEv2-konfigurasie kan DNS ontvang deur die IKE-konfigurasielading wanneer die poort dit stoot, maar of 'n gegewe kliënt toepas wat hy ontvang, is 'n implementeringsbesonderheid wat jy moet verifieer. 'n App-gebaseerde kliënt kan heeltemal sy eie resolusiepad implementeer.

Dit is verskillende integrasiepunte, en 'n resultaat van een daarvan word nie 'n reël vir alle iPhones nie. Die ondersteunde meganisme is wat die profiel of verskaffer dokumenteer vir die protokol wat gebruik word.

Besluit op grond van eienaarskap, nie gerief nie

As die toestel bestuur word, behoort die profieleienaar die DNS-instelling saam met die VPN-konfigurasie te lewer, sodat 'n herregistrasie dit herstel sonder dat 'n gebruiker enigiets hoef te onthou. As 'n verskaffer-app die tonnel besit, is sy instellingskerm die plek om te kyk, en sy dokumentasie is die gesag oor wat dit kan splits. As die foon persoonlik is en die behoefte een interne naam op een netwerk is, is die per-netwerk-instelling proporsioneel.

Die beslissingsreël is kort: die instelling hoort waar die verbinding voorsien word. Enige ander plek is 'n plaaslike uitsondering wat die volgende netwerkverandering sal uitwis.

Verifieer op die paaie wat die foon werklik gebruik

Toets 'n vars versoek vanaf die app wat die private naam nodig het, op Wi-Fi in die kantoor, op sellulêr, en oor 'n oorgang tussen hulle. 'n App met sy eie resolver-integrasie kan 'n ander pad as die stelsel volg, so toets die werklike toepassing eerder as 'n blaaier-oortjie wat toevallig werk.

Wanneer die private naam misluk, hou die presiese fout en die profieltoestand. 'n Openbare resolver wat antwoord dat die naam nie bestaan nie, is 'n korrekte antwoord op die verkeerde vraag, en om dit langs die maatskappy-resolver te voeg, is nie 'n naamruimte-ontwerp nie.

Laastens, stoor die geverifieerde beleid saam met die voorsieningsbron. Die volgende herverbinding of registrasie behoort dieselfde naamdiens te herstel omdat die profiel so gesê het, nie omdat iemand 'n wysiging onthou wat twee jaar gelede aan een hotspot gemaak is nie.