Azure VPN Client na Macu: umieść serwery DNS w profilu

W systemie macOS trzy różne pytania spotykają się z tym samym wzruszeniem ramion. Który to klient? Skąd pochodzą jego serwery DNS? I skoro ustawienie jest już na miejscu, dlaczego krótka nazwa nadal zawodzi? Odpowiedzi są odrębne, a tylko pierwsza dotyczy pliku profilu. Właściwa kolejność zamienia mgliste problemy z DNS w jeden weryfikowalny krok naraz.

Ustal, którego klienta konfigurujesz

To klient Azure VPN firmy Microsoft, który używa OpenVPN do dostępu punkt–lokacja. Jego XML nie jest natywnym profilem IKEv2 systemu macOS ani plikiem konfiguracyjnym dla dowolnego zewnętrznego klienta OpenVPN.

Jeśli Mac łączy się przez wbudowane okno systemowe, jesteś w niewłaściwym dokumencie.

DNS mieszka w XML profilu

Pobierz aktualny profil dla docelowej bramy i metody uwierzytelniania, a następnie zachowaj niezmienioną kopię, zanim czegokolwiek dotkniesz. Edytuj tylko kopię roboczą i nie wklejaj jej materiału uwierzytelniającego do zgłoszenia do pomocy technicznej.

Przewodnik po ustawieniach opcjonalnych umieszcza wpisy DNS w elemencie clientconfig. Minimalny fragment wygląda tak, z adresem, który twoja organizacja naprawdę uruchamia.

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

Ten adres jest przykładowy, a nie resolverem dostarczanym przez Azure. Zintegruj wpisy z istniejącą konfiguracją, zamiast wklejać drugi element clientconfig, ponieważ Microsoft podaje, że zduplikowane elementy nie są obsługiwane w systemie macOS. Wygenerowane profile mogą też zawierać symbol zastępczy nil tam, gdzie powinna być prawdziwa konfiguracja, a dodawanie ustawień obok elementu nil nie jest naprawą.

Import jest zmianą

Zapisanie pliku samo w sobie niczego nie zmienia. Otwórz klienta Azure VPN, wybierz Import, wskaż poprawiony XML, uzupełnij wymagane pola i zapisz połączenie.

Następnie połącz się ponownie przez to zaimportowane połączenie. Profil leżący na dysku, podczas gdy starsze połączenie pozostaje aktywne, to najczęstsza przyczyna wrażenia, że poprawna zmiana nic nie robi.

Ograniczenie sufiksu decyduje o pierwszym teście

Jak udokumentowano 30 października 2026, dodatkowe wartości sufiksów DNS w tej konfiguracji nie są poprawnie zachowywane w systemie macOS. Kopiowanie przykładu sufiksu z Windows i obiecywanie identycznego zachowania to droga do zgłoszenia działającego resolvera jako zepsutego. Wpisz sufiksy, zapisz, połącz ponownie i sprawdź, czy przetrwały ponowne połączenie. Jeśli nie, zaplanuj działanie na pełnych nazwach, zamiast walczyć z klientem.

Najpierw przetestuj z w pełni kwalifikowaną prywatną nazwą hosta. Jeśli FQDN się rozwiązuje, a krótka nazwa nie, nauczyłeś się czegoś konkretnego: resolver jest osiągalny, a rozszerzanie krótkich nazw nie działa. To inny defekt niż nieosiągalny serwer DNS i wymaga innej osoby odpowiedzialnej.

Resolver nadal potrzebuje ścieżki

Wymienienie adresu w XML nie tworzy usługi DNS. Na adresie musi działać autorytatywny resolver, który potrafi odpowiadać lub przekazywać prywatną przestrzeń nazw, a Mac musi mieć zgodę na dotarcie do niego przez tunel. Jeśli ten resolver stoi za regułą zapory, która nie zna zakresu tunelu, zapytania kończą się przekroczeniem czasu bez użytecznego błędu. Wtedy limit czasu wygląda dokładnie jak błędny adres i ludzie przez godzinę ponownie edytują XML.

Sprawdź aktywny stan resolvera połączonego Maca, a potem zapytaj ten serwer bezpośrednio, aby oddzielić jego odpowiedź od wyboru resolvera przez aplikację. Bezpośrednie zapytanie dowodzi, że serwer działa. Nie dowodzi, że zwykłe wyszukiwania go wybierają.

Przekaż trzy osobne wyniki

Trzymaj je osobno przy przekazaniu: poprawiony profil został zaimportowany, zamierzony resolver odpowiedział na żądaną nazwę, a aplikacja dotarła do zwróconego adresu. Każdy ma inną osobę odpowiedzialną i inne rozwiązanie.

Jedna linia na wynik wystarczy i nie pozwala następnej osobie ponownie edytować profilu, który już był poprawny.