Azure VPN Client na Macu: DNS servery patří do profilu

DNS pro Azure VPN Client na macOS sídlí v importovaném XML profilu. Upravte ho, importujte a znovu se připojte, poté otestujte cestu překladače zvlášť.

Na macOS dostávají tři různé otázky stejné pokrčení rameny. Který klient to je? Odkud berou jeho DNS servery? A když je nastavení na místě, proč krátké jméno pořád selhává? Mají oddělené odpovědi a jen první se týká souboru profilu. Správné pořadí promění mlhavý problém s DNS v jeden ověřitelný krok za druhým.

Potvrďte, kterého klienta nastavujete

Toto je Azure VPN Client od Microsoftu, který používá OpenVPN pro přístup bod–lokalita. Jeho XML není nativní profil IKEv2 pro macOS a není ani konfigurační soubor pro každého klienta OpenVPN od třetí strany.

Pokud se Mac připojuje přes vestavěný systémový dialog, jste ve špatném dokumentu.

DNS žije uvnitř XML profilu

Stáhněte aktuální profil pro zamýšlenou bránu a metodu ověřování a potom si před jakýmkoli zásahem ponechte nezměněnou kopii. Upravujte jen pracovní kopii a nevkládejte její ověřovací materiál do tiketu podpory.

Průvodce volitelným nastavením umísťuje DNS záznamy do prvku clientconfig. Minimální fragment vypadá takto, s adresou, kterou vaše organizace skutečně provozuje.

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

Tato adresa je ilustrativní, ne překladač, který poskytuje Azure. Záznamy vložte do stávající konfigurace, místo abyste vkládali druhý prvek clientconfig, protože Microsoft uvádí, že duplicitní prvky nejsou na macOS podporovány. Vygenerované profily mohou mít také zástupný symbol nil tam, kam patří skutečná konfigurace, a přidání nastavení vedle prvku nil není oprava.

Import je ta změna

Uložení souboru samo o sobě nic nemění. Otevřete Azure VPN Client, zvolte Import, vyberte upravené XML, doplňte požadovaná pole a uložte připojení.

Poté se znovu připojte přes toto importované připojení. Profil ležící na disku, zatímco starší připojení zůstává aktivní, je nejčastějším důvodem, proč se správná úprava jeví jako neúčinná.

Omezení přípony rozhoduje o prvním testu

Jak je zdokumentováno 30. října 2026, další hodnoty přípony DNS se v této konfiguraci na macOS správně neuchovávají. Zkopírovat příklad přípony z Windows a slíbit stejné chování je přesně to, jak se funkční překladač nahlásí jako rozbitý. Zadejte přípony, uložte, připojte se znovu a zkontrolujte, zda přežily opětovné připojení. Pokud ne, plánujte s plně kvalifikovanými názvy, místo abyste bojovali s klientem.

Nejprve testujte s plně kvalifikovaným soukromým názvem hostitele. Pokud se FQDN přeloží a krátké jméno ne, naučili jste se něco konkrétního: překladač je dostupný a rozšíření krátkého jména chybí. To je jiná závada než nedostupný DNS server a potřebuje jiného vlastníka.

Překladač stále potřebuje cestu

Uvedení adresy v XML nevytváří službu DNS. Adresa musí provozovat autorizovaný překladač, který dovede odpovědět nebo předat soukromý jmenný prostor, a Mac musí mít povolení se k němu dostat tunelem. Pokud tento překladač stojí za pravidlem firewallu, které nezná rozsah tunelu, dotazy vyprší bez užitečné chyby. Časový limit pak vypadá přesně jako špatná adresa a lidé hodinu znovu upravují XML.

Prohlédněte aktivní stav překladače na připojeném Macu a poté se toho serveru zeptejte přímo, abyste jeho odpověď oddělili od volby překladače v aplikaci. Přímý dotaz dokazuje, že server funguje. Nedokazuje, že běžná vyhledávání volí právě jej.

Předejte tři oddělené výsledky

V předávce je držte oddělené: upravený profil byl importován, zamýšlený překladač odpověděl na požadované jméno a aplikace dosáhla vrácené adresy. Každý má jiného vlastníka a jinou opravu.

Stačí jeden řádek na výsledek a zabrání to tomu, aby další člověk znovu upravoval profil, který už byl správný.

Související články