IPv6 link-local không hoạt động qua VPN: vì sao fe80 dừng ở liên kết

Bạn dựng đường hầm lên, ping fe80::1 với đường hầm làm giao diện nguồn, và không có gì trả về. Đây không phải quy tắc tường lửa bạn quên. Địa chỉ link-local chỉ có ý nghĩa trên đúng một liên kết nơi nó được hình thành, và VPN định tuyến không phải liên kết đó. fe80::1 của bộ định tuyến từ xa nằm trên phân đoạn LAN từ xa; bạn ở cách một bước nhảy trên phân đoạn khác, và IPv6 hoàn toàn không có cơ chế để bộ định tuyến chuyển tiếp gói tin link-local.

Tiền tố fe80 mô tả phạm vi, không phải dải

Link-local unicast là fe80::/10, và thuộc tính quyết định không phải con số mà là phạm vi. Địa chỉ chỉ hợp lệ trên một liên kết, và mỗi giao diện tạo một địa chỉ từ định danh của chính nó, vì thế hai máy không liên quan trên hai mạng không liên quan đều có thể trả lời fe80::1 mà không có xung đột nào. Tiền tố về cơ bản nói “trên một liên kết nào đó”; bản thân liên kết đến từ ngữ cảnh.

Trên máy chủ, ngữ cảnh đó là vùng, hay scope ID, mà bạn thêm sau dấu phần trăm: fe80::1%eth0 trên Linux, fe80::1%3 hoặc fe80::1%12 trên Windows và trong các công cụ hiển thị chỉ số giao diện. Nhân phân giải địa chỉ cùng với chỉ số giao diện rồi mới gửi. Bỏ vùng đi thì đích trở nên mơ hồ, nên ngăn xếp không có cách chọn phân đoạn.

Vì sao đường hầm định tuyến không thể chuyển nó

VPN định tuyến là giao diện điểm-điểm mang địa chỉ riêng, thường là /64 không gian IPv6 unique-local hoặc riêng tư bên trong đường hầm. LAN từ xa là một liên kết riêng, được điểm cuối đường hầm định tuyến và chuyển tiếp thay bạn để đến. Đó là hai phân đoạn khác nhau, nên địa chỉ từ phân đoạn này không phải đích hợp lệ trên phân đoạn kia.

Quy tắc chuyển tiếp được ghi rõ trong tiêu chuẩn, không phải sự kỳ quặc của ứng dụng khách: bộ định tuyến không chuyển tiếp gói tin có nguồn hoặc đích link-local. Đó là lý do gói tin chết ngay cả khi bảng định tuyến trông đúng. Thêm tuyến cho fe80::/64 trỏ về đường hầm và ngăn xếp tuân thủ sẽ từ chối nó hoặc chấp nhận rồi loại bỏ mọi gói khớp: phạm vi đích nói “chỉ liên kết này”, và giao diện đi ra không phải liên kết đó.

Khám phá láng giềng củng cố cùng ranh giới đó. Máy chủ phân giải bước nhảy tiếp theo link-local bằng yêu cầu láng giềng gửi tới multicast phạm vi liên kết với giới hạn bước nhảy 255, nên bộ định tuyến có thể từ chối mọi thứ được chuyển tiếp. Làm cho nó hoạt động qua đường hầm nghĩa là proxy khám phá cho một phân đoạn từ xa, tức là cầu nối Layer 2 đội chiếc mũ khác.

Có một thất bại thứ hai lặng lẽ hơn, và nó bắt những người vẫn cố ép tuyến: vùng. Bất kỳ vùng nào bạn gõ cục bộ đều đặt tên cho giao diện đường hầm, trong khi địa chỉ bạn muốn lại gắn với giao diện LAN từ xa. Hai thứ không bao giờ khớp, nên gói tin không thể được lái tới giao diện đúng ở đầu xa.

Thất bại trông thế nào trong thực tế

Kết quả công cụ cho lỗi phạm vi đọc như lỗi định tuyến hoặc tường lửa, và đó chính là lý do mọi người dành cả buổi chiều ở sai tầng.

Dòng thứ ba lãng phí thời gian nhất, vì ứng dụng ssh không có đầu ra trông như vấn đề dịch vụ đang lắng nghe. Nếu bạn có bất kỳ cách nào vào trong, hãy kiểm tra phía xa và xác nhận sshd gắn với mọi địa chỉ hay chỉ một.

Hãy dùng địa chỉ được tạo ra để định tuyến

Với mọi thứ bạn cần đến qua đường hầm, hãy dùng địa chỉ mà dịch vụ được cấp đúng cho mục đích đó: địa chỉ unicast toàn cầu, hoặc địa chỉ unique-local từ fc00::/7, dải được dành riêng đúng cho trường hợp nội bộ này. Xác nhận trình lắng nghe thực sự gắn nó, và kiểm tra đường về cùng mọi quy tắc tường lửa của máy chủ.

Hãy nhìn máy chủ từ xa thay vì đoán. ip -6 addr show liệt kê các địa chỉ tồn tại, và ss -6 -ltn liệt kê những gì daemon đang lắng nghe. Một dịch vụ chỉ gắn với fe80:: chỉ đến được từ phân đoạn của chính nó, thường là mặc định mà không ai cố ý chọn và có thể thay đổi khi quản trị viên đồng ý.

Khi dịch vụ thực sự không thể gắn lại, hãy nâng cầu lên tầng ứng dụng thay vì tầng mạng. Một relay trên máy chủ từ xa lắng nghe trên địa chỉ định tuyến được và kết nối tới địa chỉ link-local giải quyết vấn đề mà không mở rộng phân đoạn nào:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Ở đây vùng nằm đúng phía, trên máy chủ thực sự có eth0 trên liên kết đó. Ứng dụng khách của bạn nói chuyện với fd00:1:2::10, địa chỉ này định tuyến bình thường, và relay thực hiện bước nhảy link-local tại chỗ. Cùng mẹo đó cũng hiệu quả cho giao diện web của thiết bị hoặc BMC cũ chỉ quảng bá địa chỉ link-local.

Khi cầu nối thực sự là câu trả lời, và cần kiểm tra gì

Một số triển khai thực sự cần một phân đoạn chia sẻ: thiết bị chỉ nói khám phá link-local, thiết bị phụ thuộc multicast, phòng thí nghiệm tái tạo LAN phẳng. Đó là vấn đề Layer 2 và cần câu trả lời Layer 2, như thiết bị tap được bắc cầu tới giao diện từ xa hoặc sản phẩm khách có chế độ cầu nối rõ ràng. Nó tốn lưu lượng broadcast và multicast đi qua đường hầm cùng khám phá láng giềng phải hoạt động từ đầu đến cuối.

Đừng tiếp cận điều này bằng cách thêm fe80::/64 vào hồ sơ định tuyến. Nó tạo ra trạng thái tệ nhất: cấu hình trông đã xong, bảng định tuyến hiện một mục, và mọi gói vẫn bị loại bỏ ở đâu đó giữa hai ngăn xếp đều đang hành xử đúng.

Kiểm tra bằng giao diện thay vì ping. ip -6 addr show tun0 cho biết liên kết đường hầm có tạo địa chỉ link-local riêng không, và ip -6 route get fe80::1%tun0 cho biết nhân thực sự sẽ làm gì với đích có phạm vi. Khi nhân nói đích không thể đến trên giao diện đó, không cài đặt đường hầm nào thay đổi được, và đã đến lúc ngừng sửa hồ sơ.

Một trình tự ngắn giải quyết câu hỏi:

• Đọc địa chỉ trên máy chủ từ xa và ghi nhận đó là fe80:: hay tiền tố định tuyến được.
• Nếu là fe80::, hãy gắn lại dịch vụ, relay trên máy chủ đó, hoặc bắc cầu phân đoạn; nếu định tuyến được, hãy sửa tuyến, tường lửa hoặc địa chỉ gắn.
• Kiểm tra lại vùng mỗi lần chạy lại thử nghiệm, vì lệnh được sao chép thường giữ giao diện sai.

Nguồn: RFC 4291, kiến trúc địa chỉ IPv6.