Vì sao khám phá láng giềng IPv6 thất bại qua VPN định tuyến

Khám phá láng giềng IPv6 thuộc về một liên kết, và đường hầm định tuyến là ranh giới giữa hai liên kết. Câu duy nhất đó giải thích gần như mọi báo cáo về một máy chủ từ xa trả lời theo địa chỉ và không thể tìm thấy bằng bất kỳ cách nào khác. Hãy kiểm tra phạm vi của địa chỉ bạn đang thử trước khi kiểm tra đường hầm. Địa chỉ cục bộ theo liên kết chỉ có nghĩa trên chính liên kết của nó, và nhóm multicast của nút được yêu cầu cũng bị giới hạn theo cách đó. Cả hai đều không đi qua bộ định tuyến, nên ping tới một địa chỉ toàn cầu có thể thành công trong khi việc khám phá cho cùng máy chủ đó thì không.

Phạm vi đi trước cấu hình

Yêu cầu và thông báo láng giềng mang giới hạn bước nhảy 255 và không được chuyển tiếp, theo thiết kế. Bộ định tuyến giữa đường hầm của bạn và LAN từ xa chuyển tiếp gói IPv6 và không chuyển tiếp thông điệp láng giềng thay cho nó. Vì vậy bộ nhớ đệm láng giềng trên giao diện đường hầm chỉ chứa đối tác và ít thứ khác, đó là hành vi đúng chứ không phải lỗi cần sửa.

Một địa chỉ cục bộ theo liên kết như mục fe80:: cũng bị giới hạn theo vùng, và cùng văn bản đó có thể chỉ một máy chủ khác trên liên kết khác. Thử một địa chỉ như vậy từ phía bên kia đường hầm không chứng minh gì ngoài việc địa chỉ đó mơ hồ.

Cái bẫy là giả định tiền tố nằm trên liên kết

Một máy chủ tin rằng tiền tố nằm trên liên kết sẽ gửi yêu cầu láng giềng thay vì trao gói cho bộ định tuyến của nó, và điều đó bao gồm một /64 được định tuyến tới một site từ xa. Khi một tiền tố như vậy đến như thể nằm trên liên kết, máy chủ hỏi liên kết cục bộ về một máy chủ sống ở nơi khác, và không có gì trả lời. Hãy định tuyến một thứ nhỏ hơn tới máy chủ từ xa, hoặc kết thúc tiền tố tại bộ định tuyến sẽ trả lời thay cho nó.

Một /128 cho một dịch vụ duy nhất là cách bố trí ít bất ngờ nhất, và nó loại bỏ hoàn toàn sự mơ hồ. Đặc tả khám phá láng giềng mô tả tập thông điệp và cờ trên-liên-kết quyết định điều này.

Cầu nối thay đổi quy tắc một cách có chủ ý

Khi đường hầm mang khung Ethernet, các phân đoạn từ xa và cục bộ trở thành một liên kết, multicast đến được cả hai phía, và khám phá láng giềng hoạt động như trên một switch. Hệ quả đi kèm: lũ broadcast và multicast, phát hiện địa chỉ trùng lặp xuyên cầu, và thông báo bộ định tuyến rò rỉ vào một phân đoạn không nên thấy chúng. Miền lỗi giờ cũng trải rộng hai site. Không điều nào trong số đó phản đối cầu nối, và mỗi điểm là lý do để làm cầu nối một cách có chủ ý chứ không phải tình cờ.

Chuyển một hồ sơ từ TUN sang TAP để khám phá xuất hiện là thứ tự thao tác sai. Máy chủ, máy khách và kế hoạch địa chỉ đều phải đồng ý, và máy khách di động không cung cấp giao diện TAP nào cả, nên thiết kế như vậy chạy trên laptop và thất bại trên điện thoại. Proxy và relay láng giềng là những cơ chế riêng với yêu cầu riêng, và chúng thuộc về cách bố trí có tài liệu của quản trị viên mạng chứ không phải cài đặt của ứng dụng.

Thử với địa chỉ mà ứng dụng dùng

Xác nhận tuyến bằng ip -6 route get, xem mục láng giềng bằng ip -6 neigh, rồi xác nhận dịch vụ trên đường đi đã định tuyến. DNS và đường về là những kiểm tra riêng, và một mục láng giềng khỏe mạnh không chứng minh cả hai.

Nếu ứng dụng khăng khăng đòi một đích cục bộ theo liên kết hoặc dựa trên khám phá, đó là cuộc trò chuyện thiết kế chứ không phải bài tập tinh chỉnh, vì không cài đặt máy khách nào làm cho một cơ chế giới hạn theo liên kết hoạt động xuyên bộ định tuyến.

Hãy ghi lại bạn có thiết kế nào

Ghi lại trước sự cố là định tuyến hay có cầu nối, vì hai cách triển khai trả lời những câu hỏi này khác nhau và kỹ sư trực ca không nên suy ra điều đó từ một hồ sơ.

Đọc tập thông điệp một lần loại bỏ cám dỗ giải thích một thuộc tính phạm vi liên kết như lỗi VPN, và đó là chẩn đoán sai đắt nhất trong lĩnh vực này.