Plik resolvera macOS dla domeny lokalnej obok VPN

Twój firmowy VPN doskonale rozwiązuje nazwy firmowe, a drukarka w domu pozostaje nieosiągalna po nazwie, i zwykłym rozwiązaniem, po które ludzie sięgają, jest skierowanie całego Maca na router domowy. To znacznie większa zmiana, niż wymaga problem. macOS może wysłać jeden sufiks DNS do własnego serwera przez mały plik resolvera, zostawiając każde inne zapytanie dokładnie tam, gdzie było.

Najpierw granica uprawnień: to dotyczy domeny, którą administrujesz lub do której konfiguracji masz upoważnienie. Nie jest to droga wokół wymuszonej przez organizację polityki DNS ani jej ograniczeń sieci lokalnej.

Jeden plik z wąskim zadaniem

Załóżmy, że strefa lokalna to lab.example.org, a jej serwer odpowiada na 192.168.55.1. Na Macu, na którym wolno ci wprowadzić zmianę, administrator tworzy zwykły plik tekstowy, którego nazwą jest sama domena, /etc/resolver/lab.example.org, zawierający jedną linię nameserver 192.168.55.1. Ten katalog może nie istnieć w nowym systemie, więc utwórz go z uprawnieniami administratora i sprawdź przed zapisaniem, czy oprogramowanie do zarządzania nie ma tam już pliku.

Dokumentacja konfiguracji resolvera firmy Apple opisuje konwencję, że nazwa pliku dostarcza domenę, gdy wewnątrz pliku nie występuje osobne ustawienie domeny. Ta zasada nazewnictwa jest całą sztuczką i dlatego plik musi być nazwany od strefy, a nie od serwera.

Jak macOS wybiera spośród resolverów

Może być aktywny więcej niż jeden klient resolvera, a wygrywa najbardziej szczegółowo pasująca domena. Resolver dla lab.example.org ma więc inny zakres niż resolver domyślny, a bardziej szczegółowa subdomena z własnym plikiem może ponownie uzyskać pierwszeństwo. To właśnie pozwala firmowemu VPN zachować własny sufiks, gdy twoja strefa laboratoryjna idzie gdzie indziej. Nic w tym układzie nie jest globalne i to jest punkt wart zapamiętania.

Zostaw /etc/resolv.conf w spokoju. macOS sam zapisuje ten plik i nigdy nie zawierał on pełnego obrazu rozwiązywania nazw w obrębie domeny. Konfiguracja może też przychodzić z systemowej bazy konfiguracji, a nie z plików w tym katalogu, i dlatego profil zarządzania może nadpisać to, co zapisałeś.

Trzy rzeczy, których plik nie może zapewnić

Serwer musi być osiągalny. Jeśli VPN blokuje sieć lokalną albo firmowa trasa przechwytuje zakres adresów serwera, idealnie poprawny plik sufiksu nadal nie dostarczy zapytania. Zgłoś to właścicielowi sieci, zamiast samodzielnie rozszerzać lokalne wyjątki.

Strefa musi zawierać właściwą odpowiedź, a najlepiej sprawdzić to pełną nazwą kwalifikowaną, taką jak printer.lab.example.org. Krótka nazwa może uruchomić zachowanie domen wyszukiwania i ostatecznie zadać inne pytanie niż to, które chciałeś zadać.

Wreszcie aplikacja musi móc użyć odpowiedzi. Rozwiązanie nazwy drukarki nie daje dostępu do jej adresu i nie otwiera usługi stojącej za nim. Zwrócony adres nadal wymaga dozwolonej trasy i polityki dostępu, która pozwala na połączenie. Plik resolvera zmienia to, gdzie nazwa jest wyszukiwana; nie rezerwuje ścieżki dla wyniku.

Sprawdź wybór, zamiast zastępować DNS

Sprawdź, czego macOS faktycznie używa teraz, i odpytaj pełną nazwę kwalifikowaną z wnętrza samej aplikacji lub z narzędzia, które rozwiązuje tak jak aplikacje. Bezpośrednie zapytanie do 192.168.55.1 dowodzi, że serwer odpowiada; nie dowodzi, że macOS wybrał ten serwer do zwykłych wyszukiwań. To różne fakty i tylko drugi opisuje to, czego doświadczy twoja przeglądarka.

Jeśli inny resolver już rości sobie prawo do tego samego sufiksu, dowiedz się, do kogo należy, zanim dodasz wskazówki priorytetu. Udokumentowane ustawienie search_order porządkuje klientów współdzielących domenę; nie jest globalnym przełącznikiem preferencji, który sprawia, że ogólny resolver wygrywa każde zapytanie.

Potwierdź, że nazwy firmowe nadal się rozwiązują przy połączonym VPN, a następnie zapisz plik i jego cel w lokalnych notatkach. Gdy układ zostanie wycofany, usuń tylko ten plik i ponownie sprawdź obie przestrzenie nazw, zamiast resetować wszystkie ustawienia DNS sieci.