VPN qua DNS mô tả một ý tưởng truyền tải và không đồng nghĩa với việc trỏ một thiết bị vào trình phân giải tùy chỉnh. Câu hỏi giải quyết sự nhầm lẫn rất đơn giản: các thông điệp DNS thực sự mang gì? Một VPN thông thường có thể cài đặt trình phân giải để các ứng dụng được bao phủ tìm thấy tên riêng, và thay đổi trình phân giải đó chỉ thay đổi việc phân giải tên. Hãy thực hiện các kiểm tra dưới đây theo thứ tự, vì ba cách bố trí chỉ chia sẻ từ vựng và gần như không chia sẻ gì khác.

Tách ba cách bố trí

Trong cách bố trí thứ nhất, VPN cung cấp một trình phân giải hoặc một thiết lập chính sách tên. Dữ liệu ứng dụng vẫn đi qua các kết nối mạng riêng của nó, và đường hầm chỉ ảnh hưởng đến việc máy chủ nào trả lời truy vấn.

Trong cách thứ hai, DNS được mã hóa bảo vệ chính việc trao đổi DNS. DNS trên HTTPS và DNS trên TLS bọc các truy vấn đến trình phân giải đã chọn và không mang gói tin của bất kỳ ứng dụng nào khác. Chúng cũng không giấu tên truy vấn khỏi trình phân giải bạn đã chọn, đây là một ranh giới tin cậy khác với việc giấu chúng khỏi mạng cục bộ.

Trong cách thứ ba, một máy khách hợp tác mã hóa dữ liệu khác vào thông điệp DNS và một điểm cuối hợp tác dựng lại chúng. Đường đi thông thường của trình phân giải trở thành phương tiện truyền tải, và trình phân giải giờ là một thành phần của đường dữ liệu chứ không phải dịch vụ tên.

Kiểm tra các thông điệp DNS mang gì

Thay đổi trình phân giải và quan sát xem đường đi lưu lượng của ứng dụng có thay đổi không. Nếu ứng dụng vẫn kết nối đến cùng địa chỉ qua cùng socket, bạn chỉ thay đổi việc phân giải tên.

Một đường hầm được DNS mang theo cần một cách bố trí tương ứng ở phía máy chủ. Iodine là một ví dụ có tài liệu: tài liệu dự án của nó mô tả một đường hầm IP qua DNS, và nó cần một thành phần máy chủ hiểu được cách mã hóa. Nhập một địa chỉ trình phân giải công cộng trong Android không cung cấp điểm cuối đó, và một thuật ngữ tiếp thị mà hai sản phẩm chia sẻ không phải là đặc tả giao thức.

Bắt gói là kiểm tra quyết định. Nếu bạn chỉ thấy các truy vấn thông thường đến trình phân giải và không có gì khác, thì không có đường hầm. Nếu bạn thấy tải trọng được mã hóa trong tên truy vấn và phản hồi, bạn đã tìm ra vật mang, và câu hỏi tiếp theo là nó có thể di chuyển bao nhiêu.

Kiểm tra dung lượng trước khi cam kết

DNS được thiết kế cho truy vấn và trả lời, không phải để phân phối khối lượng lớn. Chi phí mã hóa, giới hạn kích thước thông điệp và hành vi của trình phân giải đều lấy một phần của đường đi danh nghĩa, nên dung lượng hữu ích thấp hơn mức mà liên kết nền gợi ý. Hãy coi mọi con số thông lượng bạn chưa đo trên đường đi của riêng mình là giả thuyết chứ không phải ngân sách. Đo cả hai chiều, vì tải lên và tải xuống có thể gặp giới hạn khác nhau trên một vật mang kiểu yêu cầu-trả lời.

Máy khách cũng phải quyết định lưu lượng nào đi vào đường hầm. Một giao diện dịch vụ VPN cục bộ có thể thu thập gói tin, nhưng giao diện không nói gì về cách phương tiện truyền tải từ xa bảo vệ hoặc chuyển tiếp chúng. Việc phân mảnh và truyền lại hoạt động khác đi khi vật mang là giao thức yêu cầu-trả lời chứ không phải một luồng, và một kết nối vẫn mở nói rất ít về độ trễ tương tác.

Đo bằng lưu lượng bạn định mang. Một đường hầm có vẻ ổn cho nhịp tim định kỳ có thể không dùng được cho một phiên tương tác, và ngược lại cũng đúng.

Kiểm tra bảo mật của vật mang

Đừng cho rằng việc đóng gói DNS cung cấp tính bí mật hoặc xác thực mạnh. Đường đi của trình phân giải và điểm cuối đường hầm thấy những gì việc triển khai để lộ, và mức phơi bày đó thay đổi theo thiết kế.

Mã hóa và lựa chọn vật mang là những thuộc tính riêng. Một đường hầm có thể được mã hóa trên một đường IP đơn giản, và một đường hầm do DNS mang có thể được xây dựng có hoặc không có bảo vệ cho tải trọng của nó. Dù thế nào hãy giữ HTTPS của ứng dụng tại chỗ, và đánh giá thiết kế bảo mật thực sự của đường hầm chứ không phải tên của nó.

Nếu yêu cầu là sự riêng tư khỏi mạng cục bộ, DNS được mã hóa và một đường hầm dữ liệu trả lời những phần khác nhau của yêu cầu đó. Hãy ghi ra bạn đang phòng vệ trước quan sát viên nào trước khi chọn một.

Khớp bản sửa với lỗi thực tế

Với một VPN chậm thông thường, việc thay bằng một đường hầm do DNS mang sẽ thêm một phương tiện truyền tải bị hạn chế lên trên vấn đề. Nó không sửa chất lượng vô tuyến, tắc nghẽn hay tải máy chủ, và thường khiến những điều đó dễ thấy hơn.

Với lỗi tên riêng, trước hết hãy xem chính sách trình phân giải dự định: máy chủ nào nên trả lời, những tên nào thuộc phạm vi và máy khách có được phép dùng nó không. Sau đó chọn một phương tiện truyền tải được cấp phép khớp với yêu cầu, và giữ cấu hình trình phân giải trong nhật ký thay đổi để sự cố tiếp theo không bắt đầu lại cùng cuộc tìm kiếm.

Danh sách kiểm tra ngắn: xác định cách bố trí, xác nhận thông điệp mang gì, đo dung lượng, rồi xem xét niềm tin. Bất kỳ bước nào không khớp với triệu chứng nghĩa là hai cách bố trí còn lại vẫn đang trong cuộc.

Bài viết liên quan