VPN-DNS sur iPhone: kiu posedas la agordon decidas, kie ĝi validas

Tajpu privatan solvilan adreson en la Wi-Fi-agordojn de iPhone kaj ĝi funkcios ĝis la telefono forlasos tiun reton, kio estas ĝuste la momento, kiam VPN devus transpreni. Tio estas la unua kaptilo de poŝa DNS: la loko, kie vi enigis la agordon, difinas ĝian amplekson, kaj la amplekso estas pli mallarĝa ol la plej multaj homoj supozas. Antaŭ ol redakti ion ajn, respondu tri demandojn pri la surlokigo, ĉar la respondoj decidas, kiun regilon vi devas tuŝi. Traktu la sinsekvon kiel dezajnan revizion, ne kiel agordan ĉasadon.

Tri demandoj antaŭ ol tajpi solvilan adreson

Unue, kiuj nomoj fakte bezonas specialan traktadon? Privata zono kiel corp.example estas nomspaco, ne unu gastiga komputilo, kaj la respondo devus esti domajno, ne unu rikordo. Due, kiu solvilo estas aŭtoritata por ĝi, kaj kiu posedas tiun servon? Trie, kiu vojo igas tiun solvilon atingebla de la telefono: la tunelo, enkursigita Wi-Fi-reto, aŭ io tute alia?

Se iu el tiuj tri ne havas posedanton, haltu. DNS-ŝanĝo farita sen nomspaco, aŭtoritata fonto kaj atingebla vojo estas konjekto, kiu malsukcesos alimaniere en poŝa reto ol en la oficejo.

Wi-Fi-DNS-enskribo apartenas al tiu Wi-Fi-reto

La permana DNS-agordo en iOS estas konservata laŭ reto. Ĝi validas dum la telefono estas asociita kun tiu SSID kaj ĉesas validi kiam ĝi ne estas, kio signifas, ke ĝi ne povas regi poŝan trafikon nek priskribi, kion faras VPN-kliento. Redakti ĝin por ripari aplikaĵon, kiu malsukcesas en poŝa reto, estas ŝanĝi agordon, kiun la malsukcesa vojo neniam legas.

Tio ne igas DNS laŭ reto senutila. Por hejma laboratorio aŭ unu ofica SSID, ĝi estas la plej simpla maniero atingi internan solvilon, kaj ĝi estas honesta pri sia limo.

La DNS-mekanismo de VPN sekvas la protokolon kaj la klienton

Paketa tunela provizanto en iOS povas agordi DNS per la DNS-agorda API de Apple, kiu elmontras solvilajn adresojn kaj domajnan kongruadon al la tunelo, kiu posedas la konekton. Indiĝena IKEv2-agordo povas ricevi DNS per la IKE-agorda utilŝarĝo kiam la kluzo puŝas ĝin, sed ĉu donita kliento aplikas tion, kion ĝi ricevas, estas efektiviga detalo, kiun vi devas kontroli. Aplikaĵbazita kliento povas tute efektivigi sian propran solvan vojon.

Tiuj estas malsamaj integraj punktoj, kaj rezulto de unu el ili ne fariĝas regulo por ĉiuj iPhone. La subtenata mekanismo estas tio, kion la profilo aŭ la provizanto dokumentas por la uzata protokolo.

Decidu laŭ posedo, ne laŭ oportuno

Se la aparato estas administrata, la profilposedanto devus liveri la DNS-agordon kun la VPN-agordo, por ke reenskribiĝo restarigu ĝin sen ke uzanto memoru ion ajn. Se provizanta aplikaĵo posedas la tunelon, ĝia agorda ekrano estas la loko por rigardi, kaj ĝia dokumentaro estas la aŭtoritato pri tio, kion ĝi povas apartigi. Se la telefono estas persona kaj la bezono estas unu interna nomo en unu reto, la agordo laŭ reto estas proporcia.

La decida regulo estas mallonga: la agordo apartenas tien, kie la konekto estas provizita. Aliloke ĝi estas loka escepto, kiun la sekva reta ŝanĝo forviŝos.

Kontrolu sur la vojoj, kiujn la telefono fakte uzas

Testu freŝan peton de la aplikaĵo, kiu bezonas la privatan nomon, en la ofica Wi-Fi, en la poŝa reto kaj trans transiro inter ili. Aplikaĵo kun propra solvila integriĝo povas iri alian vojon ol la sistemo, do testu la faktan aplikaĵon, ne retuman langeton, kiu hazarde funkcias.

Kiam la privata nomo malsukcesas, konservu la precizan eraron kaj la profilstaton. Publika solvilo, kiu respondas, ke la nomo ne ekzistas, donas ĝustan respondon al la malĝusta demando, kaj aldoni ĝin apud la firmaa solvilo ne estas nomspaca dezajno.

Fine, konservu la kontrolitan politikon kune kun la provizfonto. La sekva rekonekto aŭ enskribiĝo devus restarigi la saman nomservon ĉar la profilo tion diris, ne ĉar iu memoris redakton faritan ĉe unu alirpunkto antaŭ du jaroj.