Ping đến đầu bên kia của đường hầm IPv6 thất bại? Hãy kiểm tra địa chỉ ::

Một đầu của đường hầm IPv6 của bạn ping đầu kia, và chỉ một chiều từng trả lời. Giao diện đang hoạt động, tuyến trông đúng, và không có gì trong nhật ký giải thích điều đó. Địa chỉ bạn đã gán là địa chỉ subnet-router anycast, hoàn toàn không phải địa chỉ máy chủ, và trên một liên kết hai đầu nó có đúng một đích giao nhận: người gửi. Không giá trị thời gian chờ nào sửa được điều đó, vì địa chỉ không làm điều bạn nghĩ.

Triệu chứng chỉ vào địa chỉ

Mọi máy chủ trên liên kết đều trả lời trừ máy có định danh giao diện toàn số không. Gói tin gửi đến dạng đó theo định nghĩa được chuyển cho bộ định tuyến trong mạng con, nên trên đường hầm điểm-điểm nó quay lại chính máy đã gửi. Từ đầu xa điều này được đọc là một đối tác không thể tới; từ đầu gần nó được đọc là sự im lặng. Thay bằng một định danh khác trong cùng tiền tố và triệu chứng biến mất mà không cần thay đổi nào khác, đó là xác nhận cần có trước khi chạm vào các tuyến.

Định danh toàn số không được dành riêng cho anycast

RFC 4291 giữ định danh giao diện toàn số không làm địa chỉ subnet-router anycast, nên một /64 như 2001:db8:4a::/64 không chứa máy chủ nào dùng được tại 2001:db8:4a::. Việc dành riêng này có lý do: router advertisements và neighbour discovery hướng tới dạng đó và bộ định tuyến trả lời cho tiền tố nó phục vụ. Gán giá trị đó cho một đầu đường hầm là trao vai trò bộ định tuyến cho một lá, và đó là lý do không có gì quay lại. Bất kỳ định danh nào khác trong tiền tố đều hoạt động như máy chủ, nên cách sửa thường chỉ là một chữ số.

Hãy coi việc dành riêng đó là một vai trò bạn không có quyền chiếm từ đầu đường hầm, chứ không phải một điều kỳ quặc cần lách bằng tuyến.

Gán địa chỉ máy chủ và định tuyến tiền tố

Chọn ::1 và ::2 cho hai đầu, thêm một địa chỉ bằng ip -6 addr add 2001:db8:4a::2/64 dev tun0, rồi định tuyến tiền tố từ xa thay vì cố gán địa chỉ cho nó. Một tuyến cho 2001:db8:4a::/64 ra khỏi đường hầm làm phía xa tới được; chỉ địa chỉ thì chỉ cấu hình giao diện cục bộ.

Với một đường hầm đầy đủ có bước thứ ba, một tuyến mặc định cho unicast toàn cầu qua thiết bị, tương đương IPv6 của việc đưa mọi thứ vào đường hầm. Bỏ qua bước đó thì IPv6 tiếp tục dùng liên kết vật lý trong khi IPv4 đi bên trong đường hầm, nên máy chủ rò rỉ đúng loại lưu lượng bạn tưởng đã được che. Xác nhận bằng ip -6 route get 2001:4860:4860::8888 và đọc xem nó nêu thiết bị nào thay vì đoán câu trả lời.

Multicast bị từ chối trước khi định tuyến

Android kiểm tra địa chỉ và tuyến cho VpnService.Builder qua LinkAddress, và hàm dựng đó từ chối multicast ngay lập tức. Đưa cho nó một tiền tố multicast làm tuyến thì kết quả là lỗi bad LinkAddress parameters chứ không phải tuyến, đó là câu trả lời kiểm tra chứ không phải của mạng. Việc từ chối khớp với môi trường: một thiết bị tun điểm-điểm không có multicast lớp liên kết, nên một tuyến nhóm trên đó không có mô hình giao nhận để cài đặt. Địa chỉ nhóm do chính ngăn xếp tạo ra và tiêu thụ, không được cấu hình thủ công.

Địa chỉ IPv6 all-nodes và solicited-node nằm dưới cùng quy tắc. Giao diện mang chúng vì ngăn xếp đặt chúng ở đó, không phải vì một chính sách nào định thế.

Đường hầm có thể mang gì thay thế

Chuyển khám phá multicast qua một đường hầm cần một lớp hiểu tư cách thành viên nhóm: một cầu TAP trình bày một đoạn Ethernet, một relay ở mức ứng dụng, hoặc một giao thức định tuyến được nói rõ phải sao chép đến những đối tác nào. Không có thứ nào trong mô hình VpnService, nơi ứng dụng đọc và ghi gói tin và không có lời gọi nào tham gia một nhóm cho đường hầm. Hãy thêm thành phần hiểu các nhóm hoặc bỏ yêu cầu khỏi thiết kế.

Ngược lại, unicast không cần gì thêm ngoài các địa chỉ và tuyến ở trên, nên đường hầm thường được kỳ vọng mang nó và sau đó bị đổ lỗi khi một giao thức khám phá thất bại.

Ba kiểm tra trước khi bạn gán bất cứ thứ gì

Xác nhận địa chỉ không phải dạng anycast, xác nhận nó không phải multicast, và xác nhận tiền tố được định tuyến chứ không chỉ được gán cho thiết bị. Rồi gửi thử nghiệm của bạn tới một đích là máy chủ thật, vì một ping nhắm vào địa chỉ anycast đo người gửi và không nói gì về đường đi. Hãy ghi ba kiểm tra đó vào biên bản thay đổi để lần triển khai sau không phải phát hiện lại.

Một tuyến mà nền tảng chưa bao giờ cài đặt không thể sửa bằng cách chờ lâu hơn, và một địa chỉ chưa bao giờ là máy chủ không thể sửa bằng một ping tốt hơn.