VPN hai ngăn xếp: máy khách chọn họ địa chỉ, không phải bạn

Đường hầm đang hoạt động, các trang IPv4 tải được, và một tên máy chủ hết thời gian chờ. Kết luận tức thời là VPN hỏng hoặc thông tin đăng nhập sai, và thường thì cả hai đều không đúng. Tên trả về cả địa chỉ IPv4 lẫn IPv6, ứng dụng chọn một, và chỉ một trong các ứng viên đó có đường đi hoạt động. Máy khách đưa ra quyết định chọn; đường hầm chỉ đơn giản là không bao phủ thứ nó đã chọn.

Lựa chọn không phải lời hứa về độ phủ

Việc chọn địa chỉ mặc định, được mô tả trong RFC 6724, quyết định cặp nguồn và đích nào máy chủ ưu tiên khi có nhiều lựa chọn. Happy Eyeballs thêm một chiến lược kết nối lên trên: nó bắt đầu thử ở cả hai họ và giữ cái trả lời trước, để người dùng không phải chờ một họ hỏng hết thời gian.

Không cơ chế nào tạo ra tuyến đường. Nếu đường hầm chỉ mang IPv4, ứng viên AAAA vẫn là đích hợp lệ mà máy khách có thể thử, và lỗi hiện ra như tải chậm chứ không phải lỗi, vì trình duyệt đã lùi lại. Người dùng báo trang chậm chứ không phải trang hỏng, và phiếu hỗ trợ thừa hưởng sự mơ hồ đó. Hãy tái hiện với một họ cố định và báo cáo sẽ trở nên cụ thể.

Chính sự lùi lại đó khiến triệu chứng không nhất quán giữa các ứng dụng. Trình duyệt che giấu độ trễ; máy khách dòng lệnh với họ cố định cho bạn thấy lỗi thật ngay lập tức.

Tìm ra họ mà yêu cầu thực sự đã dùng

Bắt đầu từ tên, không phải đường hầm. Truy vấn cả hai loại bản ghi và ghi lại những gì trả về:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Nếu yêu cầu v4 thành công và yêu cầu v6 thất bại, bạn đã tái hiện vấn đề ở dạng có thể gỡ lỗi. Nếu cả hai thành công từ shell mà trình duyệt vẫn thất bại, hãy xem bộ phân giải của chính ứng dụng hoặc một câu trả lời đã lưu trong bộ nhớ đệm trước khi chạm vào đường hầm.

Giữ họ và đích trong ghi chú của bạn. Một phiếu nói rằng trang không tải qua VPN thì không ai kiểm chứng được, trong khi một phiếu nói rằng AAAA thất bại và A hoạt động thì chỉ ra một tuyến cụ thể.

Kiểm tra tuyến đường cho họ đó

Với họ đang thất bại, hỏi nhân hệ điều hành xem nó sẽ dùng đường nào và so sánh với các địa chỉ đã cấu hình của đường hầm. Trên Linux, ip -6 route get cho đích hiển thị giao diện và nguồn sẽ được chọn.

Sau đó kiểm tra chính đường hầm. Các peer WireGuard mang danh sách IP được phép, và mục cho 0.0.0.0/0 không nói gì về IPv6. Nếu danh sách của peer không có tiền tố IPv6, máy khách không có lý do gửi lưu lượng AAAA vào đường hầm, và gói tin đi ra theo cách mà máy chủ vẫn làm nếu không có nó.

Các quy tắc tường lửa và chính sách NAT cũng đáng được kiểm tra như vậy cho từng họ. Một quy tắc viết cho IPv4 không bao phủ IPv6 trên bất kỳ nền tảng nào, và đây là lý do phổ biến nhất khiến một họ hoạt động còn họ kia thì không.

Đừng tắt IPv6 để đơn giản hóa ảnh chụp màn hình

Tắt IPv6 trên toàn hệ thống sẽ làm triệu chứng biến mất và để bạn không có chẩn đoán. Nó cũng phá hỏng mọi đích chỉ có IPv6, và che giấu cùng lỗi đó cho ứng dụng tiếp theo. Nếu một máy thực sự không nên dùng IPv6, đó là chính sách có chủ đích với người sở hữu và bài kiểm tra. Tắt nó trong lúc xử lý sự cố không phải cả hai.

Quyết định máy khách nên làm gì với họ và cấu hình điều đó một cách rõ ràng: mang nó qua đường hầm, hoặc chặn nó theo cách được hỗ trợ để lựa chọn không bao giờ đưa ra ứng viên không thể tới. Cả hai đều là thiết kế hợp lệ. Tắt toàn cục không phải cả hai, vì đó không phải là thiết kế.

Cần ghi gì vào phiếu

Ghi bốn thứ: tên máy chủ, họ đã thất bại, tuyến mà nhân chọn, và kết quả của một yêu cầu riêng cho họ. Bộ đó đủ để người khác tái hiện lỗi mà không phải đoán bạn muốn nói đến đường nào trong hai đường.

Các quy tắc chọn địa chỉ của RFC 6724 giải thích vì sao máy khách ưu tiên ứng viên mà nó đã chọn, và RFC 8305 giải thích hành vi đua tranh đã che giấu độ trễ. Không cái nào định tuyến gói tin thay bạn, và đó chính là phần mà đường hầm phải làm.