VPN DNS so với DoH của trình duyệt: điều bài kiểm tra rò rỉ không thể nói

Trang kiểm tra rò rỉ nói DNS của bạn ổn, huy hiệu trên trình duyệt nói an toàn, và wiki nội bộ vẫn không tải được. Cả ba có thể cùng đúng một lúc, vì địa chỉ của resolver không phải là chính sách đã chọn nó hay đường đi mà truy vấn đã đi. Điều người ta gọi là rò rỉ DNS thực ra là một câu hỏi: resolver nào đã nhận tên, và lựa chọn đó có chủ đích không? Phân định điều đó cần ba lần kiểm tra, và chỉ lần cuối mới liên quan đến việc đổi một cài đặt.

Ngộ nhận một: huy hiệu nêu tên resolver của bạn

Một bài kiểm tra rò rỉ phân giải một tên thăm dò và báo cáo địa chỉ đã trả lời. Nó không báo cáo chính sách đã chọn resolver đó, và khi truy vấn được gói trong DNS over HTTPS, một thiết bị trung gian trên đường đi hoàn toàn không thấy tên. Hai cỗ máy rất khác nhau tạo ra cùng một huy hiệu trấn an: một nơi VPN đẩy 10.8.0.1 và trình duyệt dùng nó, và một nơi trình duyệt phớt lờ danh sách của hệ thống rồi gửi tên đến nhà cung cấp mã hóa riêng của nó qua đường hầm.

Sự khác biệt trở nên quan trọng ngay khi một tên riêng tư thất bại. Trong cách bố trí đầu tiên, resolver của VPN trả lời cho miền doanh nghiệp; trong cách thứ hai, trình duyệt chưa bao giờ hỏi nó, nên tên máy rút gọn không phân giải được và lỗi trông như VPN hỏng. Việc kiểm tra không phải một bài kiểm tra rò rỉ khác, mà là tra cứu một cái tên chỉ một resolver biết.

Ngộ nhận hai: trình duyệt rời khỏi đường hầm

DNS chọn một địa chỉ, định tuyến mang kết nối đi, và hai thứ đó là hai lớp riêng. Một truy vấn gửi đến nhà cung cấp DoH công cộng vẫn là TCP port 443 tới một địa chỉ có thể định tuyến. Nếu bảng định tuyến của bạn đưa tuyến mặc định vào đường hầm, truy vấn đó cũng đi qua đường hầm. Thương hiệu resolver không quyết định đường đi.

Điều DoH của trình duyệt thay đổi là người nhận các tên. Đó là một quyết định riêng tư thật và một quyết định chính sách thật, nhưng không phải là vòng tránh định tuyến. Nếu yêu cầu của bạn là tên phải ở lại với nhà vận hành VPN, một truy vấn mã hóa gửi cho người khác không đáp ứng yêu cầu đó dù vẫn dùng đường hầm cho kết nối thực tế.

Ngộ nhận ba: mọi VPN đè lên mọi trình duyệt

DNS an toàn trong trình duyệt có các chế độ, không phải một công tắc: tắt, nhà cung cấp mặc định có dự phòng, mẫu tùy chỉnh, hoặc chính sách do hệ điều hành hay tổ chức áp đặt. Trường hợp dự phòng là trường hợp tạo ra các báo cáo chập chờn. Khi điểm cuối mã hóa không đến được, trình duyệt có thể quay về resolver của hệ thống, nên cùng một laptop phân giải đúng một tên riêng tư vào thứ Hai và không vào thứ Ba.

Đồng thời, hầu hết ứng dụng VPN đặt resolver hệ thống khi kết nối lên và khôi phục cái trước đó khi nó rớt. Một trình duyệt giữ resolver mã hóa tùy chỉnh hoàn toàn không quan sát thấy lần khôi phục đó. Đây là lý do cùng một hồ sơ hành xử khác nhau trên hai laptop và vì sao resolv.conf trông đúng trong khi trình duyệt vẫn hỏi ai đó khác.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Chạy chúng khi đang kết nối, ghi lại các miền mà mỗi resolver tuyên bố, và so sánh với những gì trình duyệt báo cáo về chế độ của nó. Tài liệu DoH của Mozilla là mô tả hợp lý về cách hành vi mặc định và dự phòng của trình duyệt nên hoạt động.

Quyết định có ba đầu vào, không phải một

Tên riêng tư, niềm tin vào nhà vận hành và khả năng tiếp cận quyết định cách bố trí đúng. Những tên chỉ resolver của VPN biết buộc phải dùng DNS chia tách: hậu tố riêng tư đi đến resolver được đẩy vào, mọi thứ khác theo chính sách bạn đã chọn cho tên công cộng. Niềm tin vào nhà vận hành quyết định liệu tên công cộng cũng nên đi đến resolver đó hay đến một dịch vụ riêng. Khả năng tiếp cận quyết định liệu resolver mã hóa bạn chọn có dùng được trên mạng này hay không.

Không hàng nào trong số này là khuyến nghị phổ quát. Một resolver do VPN vận hành tập trung quan sát ở nhà vận hành đó; một dịch vụ riêng thêm một người nhận nữa cho các tên được hỏi. Không cách bố trí nào chứng minh được điều gì về việc lưu giữ trừ khi bạn đọc chính sách.

Hãy ghi quyết định theo từng hồ sơ, vì những cài đặt này trôi. Một hồ sơ đã đẩy resolver vào tháng trước có thể hôm nay không đẩy gì, và trình duyệt sẽ vui vẻ giữ một điểm cuối tùy chỉnh cũ vẫn còn trả lời. Điều nên có trong ghi chú là địa chỉ resolver, các hậu tố nó sở hữu và chế độ trình duyệt, không phải thương hiệu của dịch vụ.

Hãy kiểm tra chính sách mà bạn nghĩ mình đã cấu hình

Kiểm tra bằng tên, không bằng huy hiệu. Phân giải một tên công cộng và một tên riêng tư qua resolver hệ thống, rồi lặp lại bên trong trình duyệt với cài đặt DNS an toàn của nó ở chế độ bạn định dùng. Nếu tên riêng tư chỉ thất bại trong trình duyệt, bạn đã tìm ra sự không khớp về người nhận mà không chạm vào một cài đặt VPN nào.

Sau đó kết nối lại và kiểm tra việc khôi phục, vì đó là nơi các lỗi bàn giao sinh sống: ngắt kết nối, xác nhận resolver trước đã trở lại, kết nối lại, xác nhận cái được đẩy vào đã trở lại. Cuối cùng, kiểm tra một trình duyệt có chính sách được quản lý nếu bạn có, vì chế độ đó có thể từ chối hoàn toàn thay đổi của bạn và lặng lẽ giữ resolver trước.

Hãy bắt đầu với câu hỏi về không gian tên và bạn sẽ tránh được phần lớn chuyện này. Nếu cỗ máy phải đến được các tên nội bộ, resolver mã hóa của trình duyệt chỉ là quyết định về nửa công cộng, còn nửa riêng tư ở lại với thứ VPN đã đẩy vào.