iPhone'i VPN-i DNS: kes seadet omab, see määrab, kus see kehtib
DNS-kirje ühe Wi-Fi-võrgu all ei ole seadmepõhine poliitika. Enne muutmist sobitage privaatne nimeruum, resolver ja provisioneerimise omanik.
Sisestage iPhone'i Wi-Fi-seadetesse privaatse resolveri aadress ja see töötab seni, kuni telefon sellest võrgust lahkub — täpselt siis peaks VPN üle võtma. See on mobiilse DNS-i esimene lõks: koht, kuhu seade sisestasite, määrab selle ulatuse ja ulatus on kitsam, kui enamik eeldab. Enne millegi muutmist vastake kolmele juurutamist puudutavale küsimusele, sest vastused otsustavad, millist juhtelementi peaksite puudutama. Käsitlege jada pigem disainiülevaatusena kui seadete otsinguna.
Kolm küsimust enne resolveri aadressi sisestamist
Esiteks, millised nimed vajavad tegelikult erikäsitlust? Privaatne tsoon nagu corp.example on nimeruum, mitte üks host, ja vastuseks peaks olema domeen, mitte üks kirje. Teiseks, milline resolver on selle jaoks autoriteetne ja kellele see teenus kuulub? Kolmandaks, milline tee muudab selle resolveri telefonist kättesaadavaks: tunnel, marsruuditud Wi-Fi-võrk või hoopis midagi muud?
Kui mõnel neist kolmest omanikku pole, peatuge. DNS-i muudatus, mis tehakse ilma nimeruumi, autoriteetse allika ja kättesaadava teeta, on oletus, mis ebaõnnestub mobiilivõrgus teisiti kui kontoris.
Wi-Fi DNS-kirje kuulub sellele Wi-Fi-võrgule
Käsitsi DNS-i konfiguratsioon iOS-is salvestatakse võrgu kaupa. See kehtib seni, kuni telefon on selle SSID-ga seotud, ja lakkab kehtimast, kui ei ole, mis tähendab, et see ei saa juhtida mobiilset liiklust ega kirjeldada, mida VPN-klient teeb. Selle muutmine rakenduse parandamiseks, mis mobiilivõrgus ebaõnnestub, on seade muutmine, mida ebaõnnestuv tee kunagi ei loe.
See ei muuda võrgupõhist DNS-i kasutuks. Kodulabori või ühe kontori SSID jaoks on see lihtsaim viis sisemise resolverini jõudmiseks ja see on oma piiri suhtes aus.
VPN-i DNS-mehhanism järgib protokolli ja klienti
Paketitunneli pakkuja iOS-is saab DNS-i konfigureerida Apple'i DNS-i seadete API kaudu, mis pakub ühendust omavale tunnelile resolveri aadresse ja domeenide sobitamist. Natiivne IKEv2-konfiguratsioon saab DNS-i IKE konfiguratsiooni kandevõime kaudu, kui lüüs selle saadab, kuid see, kas antud klient rakendab saadut, on rakendusdetail, mida peate kontrollima. Rakendusepõhine klient võib täielikult rakendada oma lahendustee.
Need on erinevad integreerimispunktid ja ühe tulemus ei muutu reegliks kõigi iPhone'ide jaoks. Toetatud mehhanism on see, mida profiil või pakkuja dokumenteerib kasutatava protokolli jaoks.
Otsustage omandi, mitte mugavuse järgi
Kui seade on hallatud, peaks profiili omanik DNS-i seade VPN-i konfiguratsiooniga kaasa andma, et uus registreerimine selle taastaks, ilma et kasutaja midagi mäletaks. Kui tunnel kuulub pakkuja rakendusele, on selle seadete ekraan koht, kuhu vaadata, ja selle dokumentatsioon on autoriteet selle kohta, mida see saab eraldada. Kui telefon on isiklik ja vajadus on üks sisemine nimi ühes võrgus, on võrgupõhine seade proportsionaalne.
Otsustusreegel on lühike: seade kuulub sinna, kus ühendus provisioneeritakse. Igal pool mujal on see kohalik erand, mille järgmine võrgu muudatus kustutab.
Kontrollige teedel, mida telefon tegelikult kasutab
Testige värsket päringut rakendusest, mis vajab privaatset nime, kontori Wi-Fi-s, mobiilivõrgus ja nende vahelisel üleminekul. Oma resolveri integratsiooniga rakendus võib minna süsteemist erinevat teed, seega testige tegelikku rakendust, mitte brauseri vahekaarti, mis juhuslikult töötab.
Kui privaatne nimi ebaõnnestub, hoidke täpset viga ja profiili olekut. Avalik resolver, mis vastab, et nime ei ole olemas, annab õige vastuse vale küsimusele, ja selle lisamine ettevõtte resolveri kõrvale ei ole nimeruumi disain.
Lõpuks hoidke kinnitatud poliitikat koos provisioneerimise allikaga. Järgmine taasühendus või registreerimine peaks taastama sama nimeteteenuse, sest profiil ütles nii, mitte sellepärast, et keegi mäletas kaks aastat tagasi ühes hotspotis tehtud muudatust.