VPN đã kết nối nhưng tên không phân giải: DNS thực sự đứt ở đâu

Đường hầm đã lên, biểu tượng xanh và mọi tab trình duyệt đều báo lỗi phân giải tên. Ba cơ chế khác nhau tạo ra bức tranh đó: resolver có thể không tiếp cận được, máy khách có thể đang hỏi một resolver mà bạn không ngờ tới, hoặc chỉ các tên riêng mới thất bại. Hãy tách chúng ra trước khi thay đổi bất cứ điều gì trong giao thức đường hầm, vì mỗi thứ được sửa ở một nơi khác nhau. Thứ tự dưới đây bắt đầu bằng những quan sát tách ba trường hợp.

Một truy vấn thực sự cần gì

Một truy vấn cần ba thứ: địa chỉ resolver, tuyến đường đến địa chỉ đó và câu trả lời khớp với câu hỏi. Mỗi thứ có thể thất bại riêng, và triệu chứng nhìn thấy được là cùng một trang không tải. Vì vậy trang lỗi gần như không cho bạn biết gì cho đến khi bạn biết cái nào trong ba đã hỏng.

Máy khách học resolver của mình từ hồ sơ VPN, từ DHCP trên đường hầm hoặc từ cấu hình riêng, và nguồn nào thắng tùy thuộc vào nền tảng. Trên Windows, ipconfig /all liệt kê máy chủ DNS theo từng bộ điều hợp, nên bạn thấy giá trị được đẩy có thực sự đến hay không. Một giá trị được đẩy mà không bao giờ đến hệ điều hành là lỗi âm thầm và phổ biến. Hãy đọc giá trị đã cấu hình trước khi chạm vào hồ sơ.

Linux và macOS trả lời cùng câu hỏi bằng lệnh khác nhau, và câu trả lời cũng đáng được đọc như vậy: resolvectl status và scutil --dns cả hai đều liệt kê máy chủ theo giao diện. So sánh danh sách đó với địa chỉ mà hồ sơ tuyên bố đẩy xuống. Sự không khớp ở đây giải thích mọi thứ phía sau, nên hãy xử lý nó trước khi thử tên.

Thử một tên công khai và một tên riêng

Hỏi một tên máy chủ công khai thông thường và tên máy chủ riêng đã được ghi tài liệu từ cùng một máy, rồi ghi lại máy chủ nào trả lời từng cái. Nếu cả hai thất bại, resolver hoặc tuyến đường của nó đã hỏng. Nếu chỉ tên riêng thất bại, resolver đã trả lời và câu hỏi trở thành vùng hoặc định tuyến. Chạy hai truy vấn trong vòng một phút để thay đổi tuyến đường không thể giải thích sự khác biệt.

Giữ tên nội bộ ngoài ảnh chụp màn hình công khai và ngoài resolver công khai. Hết thời gian chờ và câu trả lời về miền không tồn tại là hai quan sát khác nhau: cái đầu nói không có gì trở về, cái sau nói một thẩm quyền đã trả lời rằng tên đó không tồn tại. Coi cả hai là một lỗi đưa bạn đến tầng sai, và cảnh báo chứng chỉ lại là thứ thứ ba, không phải lỗi DNS.

nslookup in ra cả máy chủ được hỏi và câu trả lời nhận được, và đó chính là cặp bạn cần. Chạy nó hai lần trong cùng một shell và ghi địa chỉ trả lời bên cạnh mỗi câu trả lời.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Xác nhận rằng máy khách thực sự tiếp cận được máy chủ đó

Resolver riêng do hồ sơ đẩy xuống chỉ hữu ích nếu máy khách tiếp cận được nó khi đường hầm đang lên. Một địa chỉ trông đúng mà không có tuyến đường sẽ tạo ra hết thời gian chờ, và trạng thái kết nối của đường hầm không nói gì về tuyến đường đó. Việc kiểm tra là tìm tuyến đường nhắm vào chính resolver, không phải vào điểm cuối VPN.

Mỗi nền tảng trả lời điều đó trong một dòng, và giao diện được nêu trong đầu ra là toàn bộ câu trả lời. Nếu nó trỏ đến bộ điều hợp vật lý trong khi resolver nằm sau đường hầm, hồ sơ không đẩy một tiền tố bao phủ nó.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Trong hồ sơ đường hầm chia tách, resolver có thể nằm ngoài các tuyến đường được đẩy, đó là vấn đề của hồ sơ chứ không phải của máy chủ. So sánh địa chỉ resolver với các tiền tố được đẩy và xác nhận một trong số chúng bao phủ nó. Cùng sự không khớp đó giải thích vì sao DNS hoạt động trên một mạng và thất bại trên mạng khác với hồ sơ giống hệt.

Hãy nhớ rằng trình duyệt có thể bỏ qua resolver của hệ thống

Một trình duyệt có DNS bảo mật được bật có thể gửi truy vấn qua HTTPS đến nhà cung cấp do nó tự chọn và phớt lờ hoàn toàn resolver của hệ điều hành. Khi đó hệ thống trông đúng trong khi trình duyệt thất bại, hoặc ngược lại. Đó là câu hỏi chính sách cho trình duyệt, không phải cho đường hầm.

Kiểm tra cài đặt DNS bảo mật của trình duyệt và mọi chính sách được quản lý kiểm soát nó, sau đó thử một ứng dụng hoặc trình duyệt thứ hai với đường hầm không đổi. Nếu chỉ một ứng dụng thất bại, bản sửa thuộc về ứng dụng đó. Cửa sổ riêng tư không phải là so sánh sạch, vì nó có thể tắt tiện ích theo mặc định ở một trình duyệt và không ở trình duyệt khác, và nó không bao giờ bỏ qua chính sách được quản lý. Hãy dùng hồ sơ trình duyệt thứ hai hoặc ứng dụng khác thay thế.

Xóa bộ nhớ đệm và kiểm tra lại công việc thật

Sau khi sửa một cài đặt, hãy xóa bộ nhớ đệm resolver cục bộ để câu trả lời cũ không sống lâu hơn bản sửa. Hồi phục ngắn rồi lại thất bại nghĩa là nguyên nhân vẫn còn, không phải việc xóa đã thất bại. Chọn dòng khớp với máy bạn đang dùng, vì ba bộ nhớ đệm là riêng biệt.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Sau đó lặp lại công việc ban đầu thay vì một truy vấn tổng hợp, vì công việc mới là điều người dùng quan tâm. Kết nối lại một lần nữa, để lần kiểm tra lại bao phủ trạng thái mà người dùng thực sự sẽ ở trong. Tài liệu tham chiếu nslookup của Microsoft là trang nên giữ lại cho các đối số của truy vấn.

Nếu tên chỉ thất bại sau khi ngắt kết nối, máy khách đã không khôi phục cấu hình trước đó, đó là lỗi vòng đời cần báo cáo, không phải máy chủ DNS cần thay thế. Một truy vấn hoạt động cũng không phải bài kiểm tra rò rỉ, vì quốc gia thoát ra không cho bạn biết resolver nào đã trả lời.