Azure VPN Client trên Mac: đặt máy chủ DNS vào hồ sơ

Trên macOS, ba câu hỏi khác nhau nhận cùng một cái nhún vai. Đây là ứng dụng khách nào? Máy chủ DNS của nó đến từ đâu? Và khi thiết lập đã vào vị trí, vì sao tên ngắn vẫn thất bại? Chúng có câu trả lời riêng, và chỉ câu đầu liên quan đến tệp hồ sơ. Đúng thứ tự sẽ biến một vấn đề DNS mơ hồ thành từng bước kiểm chứng được.

Xác nhận ứng dụng khách bạn đang cấu hình

Đây là Azure VPN Client của Microsoft, dùng OpenVPN cho truy cập điểm-đến-trang. XML của nó không phải hồ sơ IKEv2 gốc của macOS, cũng không phải tệp cấu hình cho bất kỳ ứng dụng OpenVPN bên thứ ba nào.

Nếu Mac kết nối qua hộp thoại hệ thống tích hợp, bạn đang ở sai tài liệu.

DNS nằm bên trong XML hồ sơ

Tải hồ sơ hiện tại cho cổng và phương thức xác thực dự định, rồi giữ một bản sao không chỉnh sửa trước khi chạm vào bất cứ thứ gì. Chỉ sửa bản làm việc, và đừng dán tài liệu xác thực của nó vào phiếu hỗ trợ.

Hướng dẫn cài đặt tùy chọn đặt các mục DNS bên trong phần tử clientconfig. Một đoạn tối thiểu trông như sau, với địa chỉ mà tổ chức của bạn thực sự vận hành.

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

Địa chỉ đó chỉ là ví dụ, không phải trình phân giải do Azure cung cấp. Hãy tích hợp các mục vào cấu hình sẵn có thay vì dán phần tử clientconfig thứ hai, vì Microsoft nêu rõ các phần tử trùng lặp không được hỗ trợ trên macOS. Hồ sơ được tạo có thể còn chứa ký tự thay thế nil ở nơi đáng lẽ phải có cấu hình thật, và thêm cài đặt bên cạnh phần tử nil không phải là sửa chữa.

Nhập lại chính là thay đổi

Lưu tệp không tự nó thay đổi gì. Mở Azure VPN Client, chọn Import, chọn tệp XML đã sửa, điền các trường cần thiết và lưu kết nối.

Sau đó kết nối lại qua kết nối đã nhập đó. Một hồ sơ nằm trên đĩa trong khi kết nối cũ vẫn hoạt động là lý do phổ biến nhất khiến một chỉnh sửa đúng có vẻ không làm gì.

Giới hạn hậu tố quyết định lần kiểm tra đầu tiên

Như được ghi nhận ngày 30 tháng Mười năm 2026, các giá trị hậu tố DNS bổ sung trong cấu hình này không được lưu đúng trên macOS. Sao chép một ví dụ hậu tố của Windows và hứa hẹn hành vi giống hệt là cách một trình phân giải đang hoạt động bị báo là hỏng. Nhập các hậu tố, lưu, kết nối lại và kiểm tra xem chúng có sống sót qua lần kết nối lại không. Nếu không, hãy lập kế hoạch với tên đầy đủ thay vì đấu với ứng dụng khách.

Trước tiên hãy thử với một tên máy chủ riêng đầy đủ. Nếu FQDN phân giải được mà tên ngắn thì không, bạn đã học được điều cụ thể: trình phân giải có thể truy cập được và thiếu phần mở rộng tên ngắn. Đó là lỗi khác với máy chủ DNS không truy cập được, và cần một người phụ trách khác.

Trình phân giải vẫn cần một đường đi

Liệt kê một địa chỉ trong XML không tạo ra dịch vụ DNS. Địa chỉ đó phải chạy một trình phân giải được ủy quyền có thể trả lời hoặc chuyển tiếp không gian tên riêng, và Mac phải được phép chạm tới nó qua đường hầm. Nếu trình phân giải đó nằm sau một quy tắc tường lửa không biết dải đường hầm, các truy vấn sẽ hết thời gian chờ mà không có lỗi hữu ích. Khi đó thời gian chờ trông giống hệt một địa chỉ sai, và người ta sửa lại XML suốt một giờ.

Kiểm tra trạng thái trình phân giải đang hoạt động của Mac đã kết nối, rồi hỏi trực tiếp máy chủ đó để tách câu trả lời của nó khỏi lựa chọn trình phân giải của ứng dụng. Truy vấn trực tiếp chứng minh máy chủ hoạt động. Nó không chứng minh các tra cứu thông thường chọn máy chủ đó.

Bàn giao ba kết quả riêng biệt

Giữ chúng riêng khi bàn giao: hồ sơ đã sửa đã được nhập, trình phân giải dự định đã trả lời tên được yêu cầu, và ứng dụng đã tới địa chỉ được trả về. Mỗi mục có người phụ trách và cách khắc phục khác nhau.

Một dòng cho mỗi kết quả là đủ, và nó ngăn người tiếp theo sửa lại một hồ sơ vốn đã đúng.