Vì sao câu trả lời DNS64 thay đổi ngay khi VPN kết nối?

Câu trả lời DNS64 mô tả một cách bố trí mạng chứ không phải một thuộc tính của máy chủ. Trình phân giải tổng hợp một địa chỉ IPv6 từ một địa chỉ IPv4, và kết quả chỉ hoạt động ở nơi có một bộ chuyển dịch ngồi ở cuối tiền tố đó. Đưa một VPN vào đường đi và cách bố trí đó có thể giữ nguyên, thay đổi hoặc không còn đúng tùy theo ba điều kiện.

Ba điều kiện đó là trình phân giải đã trả lời, tuyến đường mà thiết bị của bạn có tới tiền tố đã tổng hợp, và việc có thứ gì trên tuyến đó thực hiện việc chuyển dịch hay không. Mỗi điều đều quan sát được, và chính điều đó khiến sự cố có thể chẩn đoán.

Một bản ghi AAAA đã tổng hợp thực sự trỏ tới đâu

Một trình phân giải DNS64 trả lời truy vấn AAAA cho một tên chỉ có IPv4 bằng cách nhúng địa chỉ IPv4 vào bên trong một tiền tố mà nó được cấu hình để dùng, và tiền tố quen thuộc cho công việc đó là 64:ff9b::/96 như mô tả trong RFC 6147. Với ứng dụng, bản ghi trông giống bất kỳ bản ghi AAAA nào khác, và đó chính là điểm mấu chốt: một máy khách chỉ có IPv6 có thể thử kết nối mà không biết rằng đích đến chưa từng có IPv6. Kết nối đó sau đó phụ thuộc vào một chức năng NAT64 chuyển dịch giữa hai họ địa chỉ ở đâu đó trên đường đi. Không có bộ chuyển dịch đó, địa chỉ đã tổng hợp là một đích trông có vẻ hợp lý nhưng không dẫn tới đâu.

Vì vậy bản ghi mã hóa hai điều cùng lúc: địa chỉ IPv4 ban đầu và giả định rằng có thể tiếp cận một bộ chuyển dịch. Chỉ điều thứ nhất là nhìn thấy được trong chính câu trả lời.

Ba điều kiện quyết định liệu nó còn hoạt động

Điều kiện thứ nhất là trình phân giải nào đã tạo ra bản ghi, vì một trình không có DNS64 được cấu hình sẽ không trả về gì cho tên đó và ứng dụng thất bại theo cách khác. Điều kiện thứ hai là thiết bị của bạn có tuyến đường tới tiền tố đã tổng hợp hay không, vì một câu trả lời có thể hợp lệ trong khi đường tới đó bị thiếu. Điều kiện thứ ba là bộ chuyển dịch sở hữu tiền tố đó có nằm trên tuyến bạn sẽ dùng hay không, vì một đường hầm mang 64:ff9b::/96 đi nơi khác sẽ tới một chức năng khác hoặc không tới gì cả. Cả ba có thể đúng trước đường hầm và thất bại sau nó, và đó là lý do triệu chứng trông như một sự thoái lui đột ngột.

Hãy kiểm tra chúng theo thứ tự đó. Một câu trả lời thiếu và một tuyến đường thiếu trông giống nhau trong trình duyệt và hoàn toàn khác nhau trong nhật ký của trình phân giải.

Khi trình phân giải thay đổi, câu trả lời thay đổi

Một máy khách VPN thường đẩy trình phân giải của riêng nó vào hoặc tiếp quản toàn bộ đường truy vấn, và trình phân giải đó có thể không tổng hợp gì cả. Các truy vấn cho tên chỉ có IPv4 khi đó không trả về bản ghi AAAA, điều mà máy khách chỉ có IPv6 trải nghiệm như một cái tên không thể tới. Điều ngược lại cũng xảy ra: một trình phân giải thực sự tổng hợp có thể đưa cho bạn một tiền tố mà tuyến đường hầm của bạn không mang.

Bộ nhớ đệm khiến điều này khó thấy hơn. Một bản ghi đã tổng hợp lấy được trên mạng văn phòng có thể sống lâu hơn bối cảnh đã tạo ra nó, nên máy khách tiếp tục kết nối tới một địa chỉ mà bộ chuyển dịch của nó không còn tiếp cận được. Hãy nhìn trình phân giải đang trả lời bây giờ chứ không phải trình đã trả lời khi mục nhập được lưu. Xóa bộ nhớ đệm mà không ghi lại câu trả lời cũ và mới sẽ phá hủy bằng chứng bạn cần.

Hãy thử tra cứu và tuyến đường riêng rẽ

Hỏi trực tiếp tên trước khi đưa ứng dụng vào, và ghi lại máy chủ nào đã trả lời. Các lệnh dưới đây hiển thị bản ghi AAAA, trình phân giải đang dùng và liệu có tuyến đường tới tiền tố đã tổng hợp hay không. Hãy chạy chúng khi đường hầm đóng rồi chạy lại khi đường hầm mở.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Đọc các kết quả như một chuỗi. Thiếu bản ghi AAAA nghĩa là trình phân giải trước mặt bạn không tổng hợp, nên một tuyến chỉ có IPv6 sẽ không hoạt động cho tên đó, dù máy khách làm gì. Có bản ghi mà không có tuyến nghĩa là tiền tố không được tuyến hiện tại mang, và đó là một quyết định định tuyến chứ không phải lỗi của trình phân giải. Có tuyến trong khi yêu cầu vẫn thất bại cho thấy chính bộ chuyển dịch, và điều đó thuộc về một chủ sở hữu khác.

Ghi lại trình phân giải, bối cảnh mạng và họ địa chỉ bên cạnh mỗi kết quả. Chính ghi chú đó cho phép lần so sánh tiếp theo tách một thay đổi trình phân giải khỏi một thay đổi định tuyến.