Arbeids-VPN-en din løyser firmanamn perfekt medan skrivaren heime blir verande utilgjengeleg ved namn, og den vanlege løysinga folk grip til er å peika heile Macen mot heimerutaren. Det er ei mykje større endring enn problemet krev. macOS kan senda eitt einskilt DNS-suffiks til sin eigen server gjennom ei lita resolverfil, og la kvart anna oppslag bli nøyaktig der det var.

Tillatingsgrensa kjem først: dette er for eit domene du administrerer eller har fått mynde til å konfigurera. Det er ikkje ein veg rundt ein organisasjons påtvinga DNS-politikk eller avgrensingane hans i det lokale nettet.

Éi fil med ein smal jobb

Tenk at den lokale sona er lab.example.org og at serveren svarar på 192.168.55.1. På ein Mac der du har lov til å gjera endringa, lagar ein administrator ei rein tekstfil som heiter domenet sjølv, /etc/resolver/lab.example.org, med éi einskild nameserver 192.168.55.1-linje. Mappa finst kanskje ikkje på eit nytt system, så laga henne med administratorrettar, og sjå etter før du skriv i fall administrasjonsprogramvare allereie eig ei fil der.

Dokumentasjonen til Apple for resolverkonfigurasjon skildrar konvensjonen at filnamnet gjev domenet når ingen eigen domeneinnstilling viser seg inne i fila. Den namnelekken er heile trikset, og difor må fila heita etter sona og ikkje etter serveren.

Korleis macOS vel mellom resolverar

Meir enn éin resolverklient kan vera aktiv, og det mest spesifikke samsvarande domenet vinn. Ein resolver for lab.example.org har difor eit anna omfang enn standardresolveren, og eit meir spesifikt subdomene med si eiga fil kan igjen ta førerett. Det er dette som lèt ein arbeids-VPN halda på sitt eige suffiks medan labsona di går ein annan stad. Ingenting ved ordninga er globalt, og det er poenget som er verdt å hugsa.

Lat /etc/resolv.conf vera i fred. macOS skriv den fila sjølv, og ho har aldri halde heile biletet av domenespesifikk oppløysing. Konfigurasjon kan òg koma frå konfigurasjonsdatabasen til systemet i staden for frå filer i denne mappa, og difor kan ein administrasjonsprofil overstyra det du skreiv.

Tre ting fila ikkje kan levera

Serveren må vera nåbar. Viss VPN-en blokkerer lokalt nett, eller ei bedriftsrute fangar opp adresseområdet til serveren, kan ei heilt korrekt suffiksfil framleis ikkje levera ei spørjing. Ta det til netteigaren i staden for å utvida lokale unntak på eiga hand.

Sona må halda det rette svaret, og det blir best prøvd med eit fullt kvalifisert namn som printer.lab.example.org. Eit kort namn kan vekkja åtferd for søkjedomene og enda med å stilla eit anna spørsmål enn det du meinte å stilla.

Til slutt må applikasjonen kunna bruka svaret. Å løysa namnet til ein skrivar gjev ikkje tilgang til adressa, og det opnar ikkje tenesta bak henne. Den returnerte adressa treng framleis ei tillaten rute og ein tilgangspolitikk som tillèt tilkoplinga. Ei resolverfil endrar kvar eit namn blir slått opp; ho reserverer ikkje ein veg for resultatet.

Stadfest valet i staden for å byta ut DNS

Sjekk kva macOS faktisk brukar akkurat no, og spør etter det fullt kvalifiserte namnet frå inne i applikasjonen sjølv eller frå eit verktøy som løyser på same måte som applikasjonar. Ei direkte spørjing til 192.168.55.1 provar at serveren svarar; det provar ikkje at macOS valde den serveren for vanlege oppslag. Det er ulike fakta, og berre det andre skildrar det nettlesaren din vil oppleva.

Viss ein annan resolver allereie krev same suffikset, finn ut kven som eig det før du legg til prioritetstips. Den dokumenterte innstillinga search_order ordnar klientar som deler eit domene; ho er ikkje ein global preferansebrytar som gjer at ein generell resolver vinn kvar spørjing.

Stadfest at firmanamn framleis blir løyste med VPN-en tilkopla, og noter deretter fila og føremålet hennar i dei lokale notata dine. Når ordninga blir avvikla, slett berre den fila og kontroller båe namneromma på nytt i staden for å nullstilla alle DNS-innstillingane for nettet.

Relaterte artiklar