Vì sao điểm phát sóng chuyển hướng DNS trước khi VPN kết nối?
Điểm phát sóng viết lại các truy vấn trên mạng của chính nó, và điểm cuối dạng tên máy chủ được phân giải trước khi có bất kỳ đường hầm nào. Theo dõi trình phân giải nào đã trả lời từng truy vấn.
Tham gia mạng khách sạn đặt hai quyết định DNS trước mặt bạn ở những thời điểm khác nhau: các truy vấn thiết bị thực hiện khi đăng nhập, và các truy vấn được thực hiện sau khi đường hầm hoạt động. Điểm phát sóng có thể ảnh hưởng đến nhóm đầu qua mạng mà nó kiểm soát. Nhóm sau phụ thuộc vào chính sách của máy khách, đây là việc riêng cần kiểm tra.
Đi qua kết nối theo thứ tự, từ hợp đồng DHCP đầu tiên đến truy vấn đã phân giải một tên riêng. Khi đó hai lỗi trông giống nhau trong phiếu hỗ trợ tách ra rõ ràng: một xảy ra trước khi có đường hầm, một xảy ra bên trong nó.
Điểm phát sóng có thể và không thể chạm vào gì
Mạng truy cập cấp một địa chỉ trình phân giải qua DHCP và có thể chặn cổng 53 hướng tới địa chỉ đó. Thế là đủ để trả lời mọi truy vấn không được bảo vệ bằng địa chỉ cổng hoặc trang chặn. Cũng đủ để phá một máy khách VPN mà điểm cuối được viết dưới dạng tên máy chủ.
Điều điểm phát sóng không thể làm là đọc hoặc viết lại một truy vấn khi nó đã đi bên trong một đường hầm đã thiết lập, giả sử đường hầm thực sự mang nó. Việc chặn phụ thuộc vào việc nhìn thấy câu hỏi ở dạng văn bản rõ.
Các truy vấn vẫn rời đường hầm vì lý do không liên quan đến điểm phát sóng: cài đặt DNS bảo mật của trình duyệt, quy tắc split-DNS giữ hậu tố doanh nghiệp ở trình phân giải cục bộ, hoặc máy khách được cấu hình để loại trừ DNS khỏi đường hầm. Mỗi thứ là một lựa chọn phía máy khách, và mỗi thứ trông như sự can thiệp của điểm phát sóng khi nhìn từ bên ngoài.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Truy vấn khởi tạo diễn ra trước khi đường hầm tồn tại
Máy khách được cấp tên máy chủ phải phân giải nó trước, và tại thời điểm đó không đường hầm nào bảo vệ truy vấn. Nếu điểm phát sóng trả lời bằng địa chỉ cổng, quá trình thương lượng thất bại hoặc bị treo. Nếu nó không trả lời gì, máy khách báo lỗi tên và đường hầm không bao giờ khởi động. Cả hai kết cục đều giải thích một nhật ký đường hầm trống mà nếu không thì trông vô hại.
Hệ điều hành cũng chạy các kiểm tra kết nối và dò tìm cổng của riêng chúng, được mô tả trong RFC 8910 và RFC 8952, và các yêu cầu đó đi ra trước khi bất kỳ VPN nào hoạt động. Nhìn thấy chúng trong nhật ký proxy là hành vi mong đợi chứ không phải bằng chứng rò rỉ.
Giải pháp thực tế là cấp cho máy khách một điểm cuối không cần truy vấn. Khi điều đó bất khả thi, hãy hoàn tất đăng nhập trước rồi mới kết nối.
Tìm ra trình phân giải nào đã trả lời
Hỏi hệ thống chứ không hỏi trình duyệt, và chạy truy vấn hai lần: một lần qua bất kỳ trình phân giải nào thiết bị đang dùng, một lần với một địa chỉ cố định.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Một câu trả lời từ lệnh đầu tiên khác với lệnh thứ ba cho bạn biết trình phân giải cục bộ đang trả về thứ khác, và đó chính là điều một điểm phát sóng chuyển hướng làm. Lỗi từ lệnh thứ ba cùng với thành công từ lệnh đầu chỉ ra cổng: trình phân giải cục bộ đã phục vụ địa chỉ đăng nhập trong khi cổng 53 đi ra bị bỏ. Hết thời gian ở cả hai nghĩa là mạng bỏ DNS cho đến khi xác thực hoàn tất.
Lặp lại sau khi kết nối và so sánh. Câu trả lời được lưu trong bộ nhớ đệm sống qua quá trình chuyển đổi, nên hãy xóa bộ nhớ đệm hoặc hỏi một tên mới cho lần quan sát thứ hai.
Giữ các truy vấn sau trên con đường bạn dự định
Một hồ sơ đường hầm đầy đủ cũng bắt DNS là cách bố trí đơn giản nhất: mọi truy vấn từ mọi ứng dụng đi đến trình phân giải mà đường hầm đẩy tới, và mạng cục bộ chỉ thấy lưu lượng đã mã hóa. Hãy chứng minh bằng cách phân giải một tên nội bộ và một tên công khai sau khi kết nối, rồi so sánh cả hai câu trả lời với những gì trình phân giải của đường hầm tự trả về.
Split-DNS cần một danh sách miền được viết có chủ đích: hậu tố doanh nghiệp qua đường hầm, mọi thứ khác ở cục bộ, và không chồng chéo giữa hai bên.
DNS bảo mật của trình duyệt nằm ngoài chính sách đó, vì vậy nếu nó phải tắt để hồ sơ hoạt động có thể dự đoán, hãy tắt nó cho hồ sơ đó chứ không phải cho cả máy. Hãy làm điều đó trong cài đặt trình duyệt, không phải bằng cách sửa trình phân giải hệ thống, để thay đổi hiển thị vào lần sau. Ghi lại câu trả lời, trình phân giải và giai đoạn kết nối trên một dòng cho mỗi lần kiểm tra. Một báo cáo nói rằng DNS thất bại trên Wi-Fi khách sạn mô tả một triệu chứng với ít nhất ba nguyên nhân khác nhau.