Cách kiểm tra các bộ phân giải DNS mà Mac của bạn dùng trên VPN

scutil --dns in ra cấu hình bộ phân giải mà macOS thực sự tham khảo, không phải máy chủ DNS duy nhất bạn đã gõ vào bảng cài đặt. Kết quả dài hơn hầu hết mọi người tưởng, vì hệ thống giữ các khối bộ phân giải riêng cho đường mặc định, cho giao diện có phạm vi và cho việc chuyển tiếp dành riêng cho miền. Khối ở đầu kết quả không nhất thiết là khối trả lời truy vấn. Nếu một tên riêng tư phân giải được ở văn phòng và thất bại đúng lúc VPN bật lên, sự lệch nằm ở quy tắc khớp và tuyến đường, không ở địa chỉ máy chủ. Đọc thứ tự trước, rồi chứng minh câu trả lời bằng một tra cứu thật.

Đọc thứ tự khối trước các địa chỉ

Mỗi mục mở đầu bằng resolver #N và liệt kê nameserver[0], đôi khi if_index, một dòng flags, reach và, khi khối không phải mặc định đơn giản, một domain cùng danh sách search domain. Bộ phân giải số 1 không có miền là mặc định xử lý các tên công khai. Bất cứ thứ gì mang Scoped trong cờ của nó đều gắn với giao diện mà if_index nêu tên, và bất cứ thứ gì được đánh dấu Supplemental chỉ áp dụng cho các miền được liệt kê bên dưới.

Việc chọn là khớp hậu tố. Với một tên như intranet.corp.example, macOS ưu tiên bộ phân giải có mục domain là hậu tố khớp dài nhất, nên một khối có domain : corp.example thắng mặc định ngay cả khi nằm rất sâu trong kết quả. order phá vỡ thế hòa giữa các miền cùng độ dài. Lần xem đầu hiếm khi cần hơn thế: toàn bộ kết quả khi bạn muốn đọc một khối từ đầu đến cuối, những dòng đầu để học thứ tự khối, và một lượt lọc in các tiêu đề khối bên cạnh các dòng trường. Các khối có phạm vi xuất hiện dưới tiêu đề riêng và được đọc như phần tiếp theo của danh sách phía trên, nên hãy giữ tiêu đề trong tầm mắt mỗi khi trích dẫn kết quả.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Ghép if_index với giao diện đường hầm

Chỉ số chỉ hữu ích nếu bạn có thể nêu tên giao diện phía sau nó. scutil --nwi liệt kê thông tin mạng mà hệ thống nắm giữ, gồm giao diện chính và khả năng tiếp cận, trong khi ifconfig -l cho bạn các tên, nơi utun0 đến utun9 là các ứng viên đường hầm mà một ứng dụng khách thường tạo. Apple dùng scutil --dns làm ví dụ kiểm tra của chính mình trong hướng dẫn triển khai, và ghi lại cách Network Extension có thể định tuyến các miền đã chọn đến các bộ phân giải đã chọn, đó chính là cơ chế mà những khối có phạm vi kia phơi ra.

Phép kiểm tra quyết định vấn đề là bộ phân giải có nằm trên tuyến mà đường hầm đã cài hay không:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Nếu route -n get trả về một cổng và giao diện không khớp với mục bộ phân giải, địa chỉ có thể hoàn toàn đúng mà vẫn không tới được. Một đường hầm chia tách chỉ chở các mạng con của công ty sẽ bỏ rơi các truy vấn hướng tới máy chủ DNS bên ngoài chúng, và lỗi hiện ra như hết thời gian chờ, nên kết quả cấu hình vẫn trông sạch sẽ.

Hỏi bộ phân giải hệ thống, rồi hỏi máy chủ

Ba công cụ trả lời ba câu hỏi khác nhau, và việc lẫn lộn chúng tạo ra phần lớn kết luận sai trong lĩnh vực này. dscacheutil -q host -a name đi qua đúng bộ phân giải hệ thống mà ứng dụng thông thường dùng, nên các khối có phạm vi và bổ sung đều áp dụng. dig không có đối số máy chủ sẽ đọc /etc/resolv.conf, thứ không phải nguồn chân lý cho việc phân giải có phạm vi trên macOS, và nó bỏ qua hoàn toàn các quy tắc theo miền. dig @address chỉ tới đúng một máy chủ và không nói gì về việc chọn.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Khi lệnh thứ nhất trả lời và lệnh thứ hai trả về NXDOMAIN, bạn đã tìm thấy sự chia tách mình cần và không có gì hỏng. Khi lệnh thứ nhất hết thời gian chờ trong khi dig @10.20.0.53 trả lời, bộ phân giải hoạt động nhưng không tới được trên tuyến mà đường hầm đã chọn, nên bước tiếp theo là route -n get chứ không phải sửa cài đặt DNS. Giữ các tên riêng tư ngoài mọi thứ bạn dán vào phiếu yêu cầu hay ghi chú chia sẻ.

Điều kết quả không thể cho bạn thấy

Vài tầng nằm trên hoặc cạnh danh sách bộ phân giải, và mỗi tầng có thể gửi một truy vấn tới nơi mà kết quả không bao giờ nhắc tới. Một trình duyệt bật DNS bảo mật có thể phân giải qua kênh mã hóa riêng của nó, nên một trang tải được trong khi dscacheutil hết thời gian chờ không phải là mâu thuẫn. Một proxy DNS do phần mềm bảo mật cài đặt chạy như nhà cung cấp Network Extension và tự chuyển tiếp truy vấn, và scutil --dns cho thấy điều đã được cấu hình chứ không phải địa chỉ thượng nguồn mà proxy rốt cuộc đã dùng. Các miền tìm kiếm thêm một nếp gấp thứ ba: một tên không đủ điều kiện sẽ được gắn lần lượt từng hậu tố được liệt kê, nên khối đã trả lời có thể là một khối bạn chưa từng ngờ tới.

Câu trả lời cũ là thứ rẻ nhất để loại trừ và hay bị bỏ qua nhất:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Nếu kết quả thay đổi sau khi xóa bộ nhớ đệm, trạng thái đã được lưu đệm và kết quả trước đó mô tả một đường hầm không còn tồn tại. Nếu không thay đổi, cấu hình là như vậy, và câu hỏi chuyển sang tuyến đường và chính sách ứng dụng.

Một cẩm nang ngắn cho trước và sau

Chỉ chụp đường cơ sở ở nơi chính sách cho phép, và giữ các tệp ngoài mọi thư mục được đồng bộ. Trình tự bên dưới là thứ tôi chạy trên máy khách: chụp đường cơ sở, kết nối, chụp lại, rồi so sánh và tra cứu.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Đọc sự khác biệt theo khối chứ không theo dòng. Một bộ phân giải có phạm vi mới mang chỉ số giao diện đường hầm và một mục domain cho hậu tố riêng là hình dạng mong đợi. Một bộ phân giải mặc định mới trỏ tới địa chỉ công khai là một phát hiện đáng nêu với người sở hữu hồ sơ máy khách. Sau đó lặp lại việc tra cứu bên trong ứng dụng thực sự thất bại, không chỉ trong shell, và ghi chú giao diện từ route -n get bên cạnh kết quả.

Để hoàn tác một thay đổi, hãy ngắt kết nối và lặp lại việc chụp đường cơ sở. Nếu khối có phạm vi đã biến mất, máy khách đã tự dọn dẹp. Nếu khối vẫn được liệt kê với một giao diện không còn tồn tại, trạng thái đã cũ, và xóa bộ nhớ đệm rồi kết nối lại là cách sửa nhẹ nhàng nhất trước khi ai đó chạm vào hồ sơ.

Bốn phép kiểm tra, theo thứ tự này: có khối bộ phân giải nào khớp với hậu tố dài nhất của tên không; khối đó có gắn với giao diện mà đường hầm đã cài không; tuyến tới máy chủ tên của nó có dùng đường hầm không; và bộ phân giải hệ thống, chứ không phải dig, có trả về câu trả lời không. Phép kiểm tra đầu tiên thất bại cho bạn biết nên đổi chính sách DNS, tuyến đường hầm hay ứng dụng. Nếu cả bốn đều qua mà tên vẫn thất bại, vấn đề nằm trên DNS, và thứ tiếp theo cần kiểm tra là bất cứ gì trả lời cổng 53 phía trước nó.