DNS không phân giải được khi kill switch của VPN chặn cổng 53

Khi kill switch làm sập đường hầm, nó mang theo cả đường đi của DNS, và resolver còn lại hiếm khi là cái bạn mong đợi. Hai thiết kế xử lý khoảnh khắc đó rất khác nhau: chặn mọi gói DNS không nằm trong đường hầm, hoặc để một resolver đứng làm ngoại lệ. Cả hai đều có lý. Từ một tab trình duyệt, các triệu chứng trông gần như giống hệt nhau, nên việc đầu tiên là tìm ra bạn đã triển khai thiết kế nào.

Tôi giữ sự phân biệt đó trước mắt vì cách sửa ngược nhau trong mỗi trường hợp. Một thiết kế cần ngoại lệ rộng hơn, cái kia cần ngoại lệ hẹp hơn. Đoán mò khiến bạn mất quyền riêng tư hoặc mất một buổi chiều.

Hai thiết kế DNS cho cùng một sự cố

Thiết kế A coi resolver như một dịch vụ bình thường phía sau đường hầm. Các quy tắc tường lửa chỉ cho phép UDP và TCP 53 trên giao diện đường hầm, và địa chỉ cấp cho máy khách là một resolver bên trong đường hầm. Khi đường hầm sập, việc tra cứu dừng lại, và đó là kết quả có chủ đích, không phải lỗi.

Thiết kế B giữ một resolver truy cập được trên mạng cục bộ, thường là router ở 192.168.1.1 hoặc stub của hệ điều hành ở 127.0.0.53, với lý lẽ rằng việc phân giải tên không nên chết theo đường hầm. Điều đó tiện trong LAN gia đình, nơi router phân giải cho cả nhà. Trên Wi-Fi khách sạn hay sân bay, cùng ngoại lệ đó lại trỏ tới máy chủ của người khác, và mọi tên bạn gõ đều bị lộ, dù lưu lượng web vẫn bị chặn.

Ranh giới là ai sở hữu resolver. Nếu bạn tin cái cục bộ, ngoại lệ là một lỗ nhỏ và trung thực. Nếu không, thiết kế chỉ-đường-hầm là cách duy nhất đứng vững, và cái giá là một đường hầm sập sẽ mang theo mọi tên.

Vì sao việc tra cứu của chính máy khách VPN vẫn chạy

Máy khách phải phân giải tên máy chủ của cổng vào trước khi có đường hầm, nên một chặn nghiêm ngặt không được phủ lên đường khởi động của máy khách. Hầu hết máy khách hoặc lưu đệm địa chỉ điểm cuối, hoặc cung cấp một ngoại lệ khởi động có tài liệu cho đúng máy chủ đó. Nếu bộ quy tắc của bạn chặn việc tra cứu đó, đường hầm không bao giờ trở lại và nhật ký cho thấy một máy khách không tới được máy chủ của chính nó, đó là lỗi chính sách chứ không phải lỗi DNS.

DNS chia tách là nơi thứ hai điều này xuất hiện. Máy khách đẩy một vùng nội bộ tới resolver riêng và để mọi thứ khác cho resolver hệ thống. Sau khi sập, các tên công cộng có thể vẫn phân giải trong khi tên nội bộ hết thời gian, vì vùng riêng không còn đường đi. Với người dùng đó là "VPN làm hỏng internet"; với nhật ký resolver đó là một truy vấn không bao giờ tới.

Dưới systemd-resolved bạn thấy sự chia tách trực tiếp. resolvectl status liệt kê máy chủ DNS theo từng liên kết và các miền định tuyến, và sau khi đường hầm xuống, miền nội bộ vẫn trỏ tới một máy chủ trên liên kết không còn tồn tại. Stub ở 127.0.0.53 vẫn nhận truy vấn, rồi chờ một thượng nguồn sẽ không trả lời, và đó là lý do sự cố mất vài giây thay vì trả về ngay.

DNS mã hoá không vòng qua bộ lọc gói

DNS over HTTPS và DNS over TLS đi trên 443 và 853, nên một quy tắc chặn cổng 53 không nói gì về chúng. Chặn "DNS" theo cổng là chính sách về một cổng, không phải về phân giải tên. Nếu kill switch của bạn chặn mọi lưu lượng bên ngoài đường hầm, DoH bị phủ một cách tình cờ. Nếu bạn đã dành một ngoại lệ cho captive portal hoặc resolver công cộng, thì không.

Các điều khiển phía máy khách là đòn bẩy rẻ hơn. Firefox từ bỏ resolver DoH của mình khi tên chim hoàng yến use-application-dns.net không phân giải được, và đó là lý do các mạng được quản lý công bố miền đó là NXDOMAIN; chính sách doanh nghiệp cũng có thể ghim nó ở trạng thái tắt. Android Private DNS và DNS an toàn của Chrome có công tắc và giá trị mặc định riêng. Tắt chúng đáng tin hơn là đuổi theo địa chỉ resolver, vì danh sách địa chỉ thay đổi còn bộ quy tắc của bạn thì không.

Có một phiên bản của điều này hoàn toàn không nói về rò rỉ. Một ứng dụng có resolver ghim vẫn cần một đường mạng để tới nó. Mã hoá thay đổi ai có thể đọc truy vấn, không phải gói có thể rời máy hay không, nên một chặn cho toàn bộ thiết bị đánh bại thiết lập mà không cần chạm vào nó.

Ghép triệu chứng với lớp

Hầu hết báo cáo đến dưới dạng một câu, và câu đó thường đã gọi tên lớp. Bảng dưới đây là thứ tôi đi qua trước khi chạm vào một quy tắc; mục đích là quyết định truy vấn bị chặn, bị chuyển sai hướng hay chưa từng được gửi.

Hai dòng đầu là những dòng người ta chẩn đoán sai. Một sập im lặng và một từ chối đều trông như "DNS hỏng" trên trình duyệt, nhưng chỉ một trong hai nghĩa là kill switch của bạn đang làm việc. Từ chối nghĩa là có thứ gì đó đã trả lời, nên chặn không nằm ở chỗ bạn nghĩ.

Khôi phục chính sách resolver, rồi chứng minh

Sửa thiết kế, không sửa triệu chứng. Với phân giải chỉ trong đường hầm, cho phép 53 trên giao diện đường hầm, đẩy resolver nội bộ đi cùng cấu hình đường hầm và để liên kết vật lý không có bất kỳ quyền DNS nào. Trong wg-quick, dòng DNS = là dòng ghi resolver vào cấu hình giao diện, nên một đường hầm bỏ qua nó sẽ để resolver cũ tại chỗ và mọi truy vấn đi sai đường. hướng dẫn wg-quick ghi lại hành vi đó theo từng nền tảng.

Sau đó xác minh theo thứ tự này. Trên Linux, resolvectl status hiển thị liên kết đang hoạt động, dig +short example.com thử một tên công cộng, dig @10.8.0.1 internal.example.com thử tên nội bộ, và sudo tcpdump -ni any port 53 cho thấy gói dùng giao diện nào khi bạn chạy cả hai. Trên Windows, Get-DnsClientServerAddress -AddressFamily IPv4 và Resolve-DnsName example.com cho cùng hai sự thật: ai được cấu hình và ai trả lời.

Kết thúc bằng bài kiểm tra âm. Ngắt đường hầm, xác nhận một tên công cộng mới thất bại, xác nhận tên nội bộ thất bại, và xác nhận không có gói nào trên cổng 53 rời khỏi card mạng vật lý. Một chặn chỉ đứng vững với các câu trả lời đã lưu đệm thì không đứng vững chút nào.

Danh sách kiểm tra trước khi đóng phiếu:

• Resolver dùng trong sự cố là cái mà chính sách nhắm tới.
• Việc tra cứu điểm cuối của chính máy khách vẫn được phép, qua bộ đệm hoặc ngoại lệ.
• DoH và DoT hoặc được chặn phủ, hoặc bị chính sách tắt.
• Vùng riêng thất bại theo hướng đóng, không phải mở, khi đường hầm biến mất.