Lưu lượng IPv6 đi vòng VPN: tìm tuyến đang rò

Hai trang kiểm tra mâu thuẫn nhau: một trang báo địa chỉ của nhà cung cấp qua đường hầm, trang kia báo tiền tố nhà của bạn, và kết luận hiển nhiên là VPN đang rò. Kết luận đó bỏ qua một bước, vì hai báo cáo đã thực hiện hai quyết định định tuyến khác nhau và chỉ một trong số đó đáng lẽ phải đi vào đường hầm. Lỗ hổng thường là thật, và đó là vấn đề phạm vi phủ chứ không phải đường hầm hỏng. Ba câu hỏi giải quyết: luồng nào thực sự đã đi ra, nhân chọn tuyến nào cho nó, và ứng dụng khách định có hành vi gì.

Làm theo thứ tự đó. Trả lời không theo thứ tự sẽ dẫn tới một cuộc tranh luận dài về việc ứng dụng khách có lỗi hay không, trong khi câu trả lời thật là chưa bao giờ có tuyến IPv6 nào được cài.

Luồng nào thực sự đã đi ra, và trên bộ điều hợp nào

Bắt đầu bằng một bài kiểm tra nêu rõ họ đã dùng, rồi ghi lại ứng dụng, mạng truy cập, cấu hình đang áp dụng và liệu kết nối có cung cấp IPv6 hay không. Bốn sự kiện đó làm hai lần chạy so sánh được với nhau, và điều thứ tư thì người ta quên: mạng không có tiền tố v6 không thể rò v6, và mạng thêm một tiền tố về sau sẽ thay đổi câu trả lời.

Gửi một yêu cầu cho mỗi họ thay vì tải một trang rồi đọc kết quả. Một trang có thể trộn tài nguyên v6 và v4, một tiến trình nền có thể hành xử khác với thẻ đang mở trước mặt bạn, và một câu trả lời trong bộ nhớ đệm có thể sống lâu hơn thay đổi mạng mà bạn đang muốn kiểm tra. Cố định đích bạn kiểm tra và ghi lại, để lần chạy lặp lại đo cùng một thứ.

Đọc tuyến mà nhân đã chọn

Bảng định tuyến trả lời câu hỏi mà trình duyệt không thể. Hỏi hệ thống xem một đích cụ thể sẽ đi đâu, và bao gồm cả quy tắc chính sách lẫn tuyến mặc định nhìn thấy được, vì cả hai đều có thể ghi đè nó:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Một tiền tố cụ thể hơn là lý do thường gặp khiến một đích nằm ngoài đường hầm trong khi mọi thứ khác ở trong, và một quy tắc chính sách có thể làm điều tương tự với ưu tiên cao hơn bất kỳ tuyến nào. Cũng hãy đọc số đo, vì hai mục cho cùng một tiền tố được quyết định bằng số đo chứ không bằng thứ tự trên màn hình. Trên Windows, danh sách tương đương là Get-NetRoute -AddressFamily IPv6, được sắp theo số đo để khớp với thứ tự quyết định. Một quy tắc trông đúng trong bảng vẫn có thể thua một quy tắc chính sách có số thấp hơn, vì thế danh sách quy tắc đi cùng hơi thở với danh sách tuyến.

Chính sách IPv6 của ứng dụng khách đến từ đâu

Ứng dụng khách có thể được xây dựng để mang v6 qua đường hầm, để từ chối nó hoặc để cho phép một ngoại lệ có tên, và ba ý định đó cho ba kết quả đúng khác nhau. Hãy đọc cấu hình và tài liệu của chính ứng dụng khách trước khi gọi một quan sát là rò, vì một ứng dụng khách chặn v6 trong khi hệ điều hành vẫn gửi khám phá lân cận trên liên kết vật lý đang hành xử đúng như thiết kế.

Một ứng dụng bị loại trừ có chủ đích khỏi đường hầm là trường hợp khác với một họ mà đường hầm chưa bao giờ mang. Cái đầu là quyết định về một chương trình, cái sau là lỗ hổng trong phạm vi phủ, và cách sửa khác nhau tương ứng. Hãy đọc danh sách chương trình bị loại trừ của ứng dụng khách trước khi đi tìm một tuyến lẽ ra không bao giờ tồn tại.

Quan sát hẹp, khi bảng mâu thuẫn

Khi việc tra tuyến là mơ hồ, một quan sát giao diện trên máy chủ có thể giải quyết, nhưng chỉ khi nó nhắm vào câu hỏi. Lưu lượng tới chính điểm cuối VPN sẽ đi qua bộ điều hợp vật lý theo thiết kế; điều quan trọng là luồng của ứng dụng, được đánh địa chỉ ở nơi hoàn toàn khác, có xuất hiện ở đó không. Hãy lọc bản ghi theo đích bạn đang kiểm tra thay vì thu thập mọi thứ.

Một bản ghi rộng phơi bày nhiều lưu lượng cá nhân hơn nhiều so với nhu cầu của một câu hỏi. Nó cũng trả lời kém rõ ràng hơn, vì luồng bạn quan tâm đến bị chôn trong một dòng các kết nối không liên quan. Lọc theo đích đã kiểm tra, dừng sau vài gói tin và xóa bản ghi.

Ba cách bịt lỗ hổng

Đưa họ đi qua đường hầm, chặn nó ở ứng dụng khách khi đường hầm không mang nổi, hoặc ghi lại một ngoại lệ có chủ đích với người sở hữu và ngày xem xét. Cách nào cũng biện hộ được, và điều duy nhất không biện hộ được là để lựa chọn thành ngầm định, vì một lựa chọn ngầm định chính là bản chất của sự rò. Nếu đường hầm hoàn toàn không có lối ra v6, từ chối v6 ở ứng dụng khách vừa trung thực vừa kiểm chứng được. Điều quan trọng là lựa chọn được ghi ở nơi người tiếp theo tìm thấy, chứ không phải suy ra từ hành vi sáu tháng sau.

Lặp lại việc kiểm tra sau khi kết nối lại và sau khi chuyển giữa các mạng, vì một tuyến được cài cho liên kết trước có thể sống sót qua thay đổi. Sau đó ghi lại đích, tuyến đã chọn, chính sách của ứng dụng khách và họ mà bài kiểm tra đã dùng, để người tiếp theo đọc một quyết định thay vì tự rút ra lại. RFC 7359 ghi nhận sự rò của ngăn xếp kép là vấn đề thiết kế chứ không phải lỗi, và đó là tài liệu tham chiếu để trích dẫn khi ai đó cho rằng một đường hầm v4 đang hoạt động bao phủ mọi thứ.