macOS-resolva dosiero por loka domajno apud VPN

Via labora VPN solvas kompaniajn nomojn perfekte, dum la presilo hejme restas neatingebla laŭ nomo, kaj la kutima solvo, al kiu homoj sin turnas, estas direkti la tutan Mac al la hejma enkursigilo. Tio estas multe pli granda ŝanĝo ol la problemo postulas. macOS povas sendi unu DNS-sufikson al sia propra servilo per malgranda resolva dosiero, lasante ĉiun alian serĉon ĝuste tie, kie ĝi estis.

La permesa limo venas unue: ĉi tio estas por domajno, kiun vi administras aŭ por kies agordado vi estas rajtigita. Ĝi ne estas itinero ĉirkaŭ la trudita DNS-politiko de organizo aŭ ĝiaj limigoj pri loka reto.

Unu dosiero kun mallarĝa tasko

Supozu, ke la loka zono estas lab.example.org kaj ĝia servilo respondas ĉe 192.168.55.1. Sur Mac, kie vi rajtas fari la ŝanĝon, administranto kreas simplan tekstodosieron, kies nomo estas la domajno mem, /etc/resolver/lab.example.org, enhavanta unu solan nameserver 192.168.55.1 linion. La dosierujo eble ne ekzistas en nova sistemo, do kreu ĝin kun administraj rajtoj, kaj rigardu antaŭ ol skribi, se administra programaro jam posedas dosieron tie.

La resolva agordo de Apple dokumentas la konvencion, ke la dosiernomo donas la domajnon kiam ene de la dosiero ne aperas aparta domajna agordo. Tiu nomiga regulo estas la tuta truko, kaj tial la dosiero devas esti nomita laŭ la zono, ne laŭ la servilo.

Kiel macOS elektas inter resolviloj

Pli ol unu resolva kliento povas esti aktiva, kaj la plej specifa kongrua domajno venkas. Resolvilo por lab.example.org tial havas alian amplekson ol la apriora resolvilo, kaj pli specifa subdomajno kun propra dosiero povas denove akiri prioritaton. Tio ebligas al labora VPN konservi sian propran sufikson dum via laboratoria zono iras aliloken. Nenio en la aranĝo estas tutmonda, kaj tio estas la punkto inda je memoro.

Lasu /etc/resolv.conf trankvila. macOS mem skribas tiun dosieron, kaj ĝi neniam entenis la plenan bildon de domajn-specifa solvado. Agordo ankaŭ povas veni el la sistema agorda datumbazo anstataŭ el dosieroj en ĉi tiu dosierujo, kaj tial administra profilo povas anstataŭigi tion, kion vi skribis.

Tri aferoj, kiujn la dosiero ne povas doni

La servilo devas esti atingebla. Se la VPN blokas lokan retadon, aŭ kompania itinero kaptas la adresaron de la servilo, tute ĝusta sufiksa dosiero tamen ne povas liveri demandon. Portu tion al la retposedanto anstataŭ mem larĝigi lokajn esceptojn.

La zono devas teni la ĝustan respondon, kaj tio estas plej bone testata per plene kvalifikita nomo kiel printer.lab.example.org. Mallonga nomo povas ekigi konduton de serĉdomajno kaj fini demandante alian demandon ol tiu, kiun vi celis.

Fine, la aplikaĵo devas povi uzi la respondon. Solvi la nomon de presilo ne donas aliron al ĝia adreso, kaj ĝi ne malfermas la servon malantaŭ ĝi. La redonita adreso ankoraŭ bezonas permesitan itineron kaj alirpolitikon, kiu permesas la konekton. Resolva dosiero ŝanĝas, kie nomo estas serĉata; ĝi ne rezervas vojon por la rezulto.

Kontrolu la elekton anstataŭ anstataŭigi DNS

Kontrolu, kion macOS fakte uzas nun, kaj demandu la plene kvalifikitan nomon el la aplikaĵo mem aŭ el ilo, kiu solvas tiel, kiel faras aplikaĵoj. Rekta demando ĉe 192.168.55.1 pruvas, ke la servilo respondas; ĝi ne pruvas, ke macOS elektis tiun servilon por ordinaraj serĉoj. Tiuj estas malsamaj faktoj, kaj nur la dua priskribas, kion via retumilo spertos.

Se alia resolvilo jam postulas la saman sufikson, eltrovu, kiu posedas ĝin, antaŭ ol aldoni prioritatajn signalojn. La dokumentita search_order agordo ordigas klientojn, kiuj kunhavas domajnon; ĝi ne estas tutmonda prefera ŝaltilo, kiu igas ĝeneralan resolvilon venki ĉiun demandon.

Konfirmu, ke kompaniaj nomoj ankoraŭ solviĝas kun la VPN konektita, poste registru la dosieron kaj ĝian celon en viaj lokaj notoj. Kiam la aranĝo estas forigita, forigu nur tiun dosieron kaj rekontrolu ambaŭ nomspacojn anstataŭ restarigi ĉiujn retajn DNS-agordojn.