WireGuard-DNS sur iPhone: la domajno estas nur serĉa sufikso

Vi skribas unu linion kun solvila adreso kaj firmaa domajno, esperante ke nur nomoj en tiu domajno uzos la tunelan solvilon. Ĉe la Apple-kliento nun ĉiuj nomoj iras tien, kaj mallongaj nomoj en la domajno ankaŭ estas solvataj. La linio faras du apartajn aferojn, kaj nur unu el ili temas pri kiuj demandoj la tunelo pritraktas. La alia estas tajpa oportuneco, kiun revema legado promociis al politiko.

Kiel la DNS-linio estas analizata

La kliento legas la eron kiel liston kaj klasifikas ĉiun elementon laŭ formo. Ĉio, kio aspektas kiel adreso, fariĝas DNS-servilo; ĉio, kio aspektas kiel domajno, fariĝas serĉa sufikso. Ambaŭ finiĝas en la tunelaj agordoj, sed en malsamaj kampoj. Ilustra linio por tunelo, kiu portas privatan solvilon kaj unu internan domajnon, aspektas tiel.

DNS = 10.24.8.53, lab.internal.example

La adreso provizas la solvilon. La domajno provizas sufikon, kiu ebligas al kliento tajpi mallongan nomon kaj al la sistemo aldoni la reston antaŭ ol demandi. Neniu el la du diras ion pri limigo de la solvilo al tiu domajno, kaj ĝuste tion homoj atendas kaj ne ricevas. Nur unu kampo en la platformo povas esprimi tiun limigon, kaj ĝi ne estas ĉi tiu.

Du Apple-kampoj, du malsamaj taskoj

Apple elmontras la distingon en sia DNS-agorda objekto. La serĉdomajna listo estas dokumentita kiel la listo uzata por kvalifiki unuetikedajn gastigantnomojn: tajpu nudan gastigantnomon kaj la sistemo povas aldoni ĉiun sufikon laŭvice. Tio estas kompletiga regulo, ne enkursiga regulo. Nenio en tiu listo decidas, kiun servilon oni demandas.

La kongruodomajna listo estas alia eco. Ĝi decidas, kiuj nomspacoj uzas ĉi tiun DNS-agordaron, kaj malplena ero signifas la defaŭltan domajnon anstataŭ unu specifan sufikon. generatoro de pakettunelaj agordoj en la Apple-kliento sekvas tiun modelon. Ĝi metas analizitajn serĉsufiksojn en la serĉliston, kaj kiam serviloj ĉeestas, ĝi agordas la kongruoliston al la malplena ĉeno. La rezulto estas tunela solvilo, kiu respondas al ĉio, kion la sistemo sendas al ĝi, plus sufiko, kiu helpas pri mallongaj nomoj.

Do domajno en tiu linio ne estas nomspaca selektilo. Aldoni alian ne mallarĝigas, kiujn demandojn la tunelo uzas, kaj forigi ĝin ankaŭ ne larĝigas ilin. La sola afero, kiu ŝanĝiĝas, estas kiom da mallongaj nomoj kompletigatas.

Kial ĉiu nomo ankoraŭ atingas la tunelan solvilon

Kun la malplena kongruero, la tunelo estas kandidata solvilo por ordinaraj nomoj, ne nur por la firmaa domajno. En plentunela agordo tio kutime malmulte gravas, ĉar la tuta trafiko estas ĉiuokaze en la tunelo. En dividita tunelo tio tre gravas. Publikaj nomoj nun povas esti solvataj de solvilo, kiu tenas nur privatan zonon, kaj malsukceso aspektas kiel rompita VPN, dum ĝi fakte estas solvilo, kiu respondas nur al parto de la nomspaco. La tunelo estas en ordo, la demandoj foriras, kaj la respondoj revenas malplenaj.

Disponeblas du riparoj kaj ili estas malsamaj decidoj. Faru la tunelan solvilon plena solvilo, kiu plusendas publikajn nomojn laŭ la aprobita vojo, aŭ ĉesu sendi publikajn nomojn tien per ŝanĝo de la klienta agordo anstataŭ de la domajna listo. La unua tenas ĉiun demandon en la tunelo kaj fidas la supran fluon. La dua tenas kelkajn demandojn loke kaj akceptas, ke privataj nomoj eble ĉesos solviĝi dum la tunelo estas malŝaltita.

Kion dividita DNS fakte postulus

Nomspace limigita solvila politiko postulas klienton, kiu ebligas al vi esprimi ĝin: kongruigu domajnojn sur Apple-platformoj, aŭ ekvivalentan agordon en la produkto, kiun vi uzas. Agorda kampo, kiu akceptas nur servilojn kaj sufiksojn, ne povas esprimi ĝin, kiel ajn ĝi estas interpunkciata. Profilo povas porti la politikon, ĉar ĝi priskribas administritan agordon anstataŭ aludon je konekta tempo. Ĝi povas nomi la domajnon, la servilojn, kaj kion oni faru, kiam tiu domajno estas neatingebla. Tio estas la diferenco inter agordo kaj kontrakto.

Sur administritaj Apple-aparatoj tio kutime liveriĝas per agorda profilo, kiu portas la domajno-specifajn DNS-agordojn. Tio estas alia mekanismo ol WireGuard-agorda dosiero, kaj la du povas kunekzisti nur se la kliento respektas la profilon. Kontrolu, kiel via kliento efektive nomas la kampon, antaŭ ol supozi, ke la du produktoj kondutas same. Skripto kun wg-quick sur Mac kaj la WireGuard-aplikaĵo sur iPhone legas similajn liniojn kaj instalas ilin tra malsamaj tavoloj.

Legu la instalitajn agordojn, ne la agorddosieron

Sur Mac vi povas inspekti, kien la sistemo finfine venis, kio estas pli informa ol relegi la dosieron, kiun vi skribis. La solvila listo montras, kiuj serviloj estas agorditaj por kiuj domajnoj, kaj la limigitaj demandoj montras, kiu venkis. Kliento, kiu fuŝas la linion, montras tion ĉi tie anstataŭ en la dosiero, kiun vi skribis. Sur iOS ne ekzistas ekvivalenta komandlinio, do la pruvo tie estas rezulto: privata nomo, kiu solviĝas tra la tunelo, kaj publika nomo, kies respondo malkaŝas, kiu solvilo respondis.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Ĉi tiuj du komandoj presas la nunan solvilan agordon kaj la DNS-servilojn por la aktiva servo. Se la tunela solvilo aperas kiel defaŭlta solvilo sen domajna limigo, la agordo faras ĝuste tion, kion la kliento petis. Riparu tion per ŝanĝo de la mekanismo, ne per aldono de dua sufiko kaj espero, ke la konduto ŝanĝiĝos.