VPN của bạn mã hóa DNS hay chỉ mã hóa chặng kế tiếp?

Bật DNS được mã hóa trên máy chủ VPN thường được mô tả là bịt một chỗ rò rỉ, và mô tả đó che giấu việc kết nối nào đã thay đổi. Chặng từ máy khách đến trình phân giải và chặng từ trình phân giải đến thượng nguồn là những kết nối riêng biệt với chủ sở hữu riêng biệt. Mã hóa một kết nối để kết nối kia y nguyên như cũ.

Ghi lại ai nhận truy vấn ở mỗi giai đoạn trước khi bạn động vào tệp cấu hình.

Hai cách bố trí trông giống nhau trên trang cài đặt

Ở cách bố trí thứ nhất, thiết bị tự chạy DNS over TLS, và đường hầm chỉ mang kết nối đó đến trình phân giải bạn đã chọn. Phiên TLS kết thúc tại trình phân giải, nghĩa là trình phân giải thấy truy vấn còn lối ra VPN thấy văn bản đã mã hóa mà nó không đọc được. Ở cách bố trí thứ hai, thiết bị gửi DNS thông thường qua đường hầm đến một bộ chuyển tiếp trên máy chủ VPN, và bộ chuyển tiếp đó mở kết nối mã hóa của riêng nó đến trình phân giải thượng nguồn. Trong danh sách tính năng, cả hai đều trông như "DNS được mã hóa với VPN", và chúng đặt truy vấn đọc được ở những tòa nhà khác nhau.

Khác biệt là đo được chứ không phải triết học. Hãy tìm phiên TLS trên máy khách hoặc trên máy chủ, và bạn sẽ biết mình thực sự có cách bố trí nào.

Lập bản đồ chuỗi trình phân giải trước khi thay đổi

Đếm các trình phân giải trên đường đi và gọi tên vai trò của từng cái. Một thành phần chuyển tiếp giao yêu cầu cho trình phân giải khác, trong khi trình phân giải đệ quy làm công việc tìm câu trả lời và có thể nói chuyện trực tiếp với máy chủ có thẩm quyền. Những vai trò này được định nghĩa riêng chính vì lý do đó, và định nghĩa trình phân giải trong RFC 9076 đáng đọc trước khi bạn cho rằng chỉ có một đích thượng nguồn. Một máy chủ chạy trình phân giải đệ quy của riêng nó không có một "thượng nguồn" duy nhất để mã hóa, điều đó làm vô hiệu toàn bộ kế hoạch.

Sau đó hỏi máy khách được cấu hình dùng thành phần nào. Địa chỉ DNS do hồ sơ VPN đẩy xuống cho bạn biết truy vấn đi đâu, chứ không cho biết tiến trình nào trả lời.

Cũng để ý hành vi khi lỗi. Nếu thượng nguồn đã mã hóa trở nên không thể tiếp cận, bộ chuyển tiếp có thất bại theo hướng đóng, quay về văn bản rõ hay chuyển sang trình phân giải khác? Quyết định đó phải nằm trong hồ sơ, vì nó thay đổi bảo đảm riêng tư đúng lúc đường hầm kém khỏe mạnh nhất.

Xác minh chặng nào được mã hóa

Bắt đầu trên máy khách và xác nhận xem nó có phiên TLS tới cổng 853 hay không. Một truy vấn phân giải đúng qua cổng 53 không chứng minh gì về mã hóa.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Sau đó chuyển sang máy chủ VPN và tìm kết nối mã hóa đi ra mà bộ chuyển tiếp đã mở. Bảng socket cho bạn biết có phiên TLS thượng nguồn hay không, và tiến trình nào sở hữu nó:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Nếu máy khách cho thấy phiên TLS còn máy chủ không có, bạn đang ở cách bố trí thứ nhất và máy chủ không đọc được các truy vấn nó chuyển tiếp ở tầng IP. Nếu máy chủ cho thấy phiên TLS còn máy khách cho thấy lưu lượng cổng 53 thông thường bên trong đường hầm, bạn đang ở cách bố trí thứ hai: chặng tiếp theo được bảo vệ, và bộ chuyển tiếp vẫn đọc mọi tên thiết bị hỏi. Kết quả thứ hai đó không phải là hỏng hóc, nhưng gọi nó là mã hóa đầu cuối thì sai.

Ghi lại chủ sở hữu và hành vi khi lỗi

Quyền sở hữu quyết định điều bạn được phép hứa. Chủ thiết bị kiểm soát kết nối mã hóa phía máy khách, còn quản trị viên VPN kiểm soát kết nối tiếp theo do bộ chuyển tiếp của họ tạo ra. Ai không vận hành cái nào trong hai thì chỉ có thể mô tả đường đi.

Trước khi bật bất cứ thứ gì, hãy kiểm tra cách đặt tên nội bộ. Gửi tên của tổ chức đến trình phân giải công cộng không phải là thiết kế tương đương, và một vùng split-horizon chỉ tồn tại bên trong mạng sẽ không được phân giải ở thượng nguồn chút nào. Hãy thử một tên nội bộ và một tên công cộng sau thay đổi, rồi giữ kết quả cùng với thay đổi cấu hình. Nếu đường mã hóa phá vỡ việc phân giải cho các máy chủ nội bộ, cách sửa là một quy tắc trình phân giải có phạm vi, không phải đường hầm rộng hơn.

Kết thúc bằng việc viết một câu cho mỗi chặng: thành phần nào nhận truy vấn, chặng đó có được mã hóa không, và ai có thể đọc tên. Khi câu về máy chủ VPN vẫn nói rằng nó đọc được truy vấn, tài liệu cũng nên nói như vậy, vì một sơ đồ khẳng định ngược lại sẽ được tin bởi người chưa bao giờ chạy các lệnh đó.