Ủy quyền tiền tố IPv6 qua VPN site-to-site: danh sách kiểm tra

Dựng tunnel lên là nửa dễ. Tôi đã thấy một liên kết site-to-site duy trì trạng thái kết nối nhiều ngày trong khi mọi máy chủ trên LAN xa chỉ nhận lại sự im lặng, vì tiền tố được ủy quyền phía sau gateway đó được cấu hình trên một giao diện nhưng chưa bao giờ được định tuyến vào tunnel. Các địa chỉ tunnel vẫn trả lời ping suốt thời gian đó, và chính vì thế không ai nhìn vào tiền tố. Đây là thứ tự tôi kiểm tra khi một tiền tố IPv6 được ủy quyền phải đi qua VPN site: bản đồ tiền tố, bộ chọn lưu lượng, chuyển tiếp và tường lửa, rồi đến đường trở về.

Viết bản đồ tiền tố trước khi chạm vào tunnel

Ủy quyền tiền tố trao một khối cho router đã yêu cầu nó. Nó không cài tuyến trên peer, không mở rộng khối đó theo on-link và không cho gateway xa biết có gì phía sau router yêu cầu. Ba việc này bạn phải tự cấu hình, và chúng thuộc về một kế hoạch địa chỉ trước khi bất kỳ tệp cấu hình nào thay đổi.

Với mỗi site, ghi lại tiền tố được ủy quyền, /64 thực sự dùng trên LAN, địa chỉ tunnel và chủ sở hữu của từng tuyến. Nhà cung cấp ủy quyền 2001:db8:a1::/56 cho site A, site này phục vụ 2001:db8:a1:10::/64 trên LAN của mình; site B giữ 2001:db8:b2::/64. Nếu site A chỉ phục vụ đúng /64 đó, cả hai đầu nên nêu 2001:db8:a1:10::/64 thay vì toàn bộ /56.

Gần như luôn xuất hiện hai lỗi. Một là coi tiền tố xa là on-link, bắc cầu nó hoặc đặt nó lên giao diện tunnel để gateway trả lời yêu cầu lân cận cho những máy chủ nó không thể tới. Hai là quảng bá toàn bộ /56 khi chỉ cấu hình một /64: bảng tuyến khẳng định khối đó có thể tới được và phần lớn địa chỉ rơi vào hố đen.

Khớp bộ chọn lưu lượng của hai đầu với các tuyến

IKEv2 và WireGuard đều từ chối lưu lượng không khớp, đủ im lặng để tunnel vẫn trông khỏe mạnh.

Trong strongSwan, các bộ chọn được nêu rõ. Tại site A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

conn của site B phản chiếu hai subnet. Khi chúng không khớp, bên trả lời từ chối CHILD_SA với TS_UNACCEPTABLE, nên child SA không bao giờ lên dù IKE_SA đã lên. Ở cả hai phía, subnet được cấu hình phải bằng với thứ kernel cục bộ định tuyến về phía tunnel.

WireGuard mang cùng thông tin trong AllowedIPs, với một điểm xoay: AllowedIPs là bộ lọc nguồn khi nhận và là tuyến khi gửi. Nếu mục peer của site B cho site A bỏ sót 2001:db8:a1:10::/64, gói tin từ site A đến với handshake hợp lệ và bị bỏ vì không được phép. Điều đó tạo ra kiểu mẫu quen thuộc: handshake liên tục gia hạn trong khi không có phản hồi nào đi ra. So sánh hai đầu bằng wg show wg0 allowed-ips. Kiểm tra lại danh sách đó mỗi khi ủy quyền thay đổi; một /64 cũ giữ phiên sống và khiến tiền tố mới không thể tới.

Loại trừ chuyển tiếp, tường lửa và MTU trước

Trước khi đọc thêm một dòng log, hãy xác nhận các gateway có chuyển tiếp hay không. sysctl net.ipv6.conf.all.forwarding phải trả về 1 trên cả hai, áp dụng cả cho giao diện tunnel và LAN. Có một cái bẫy đi kèm: khi bật chuyển tiếp, giao diện có accept_ra=1 ngừng nhận quảng cáo router từ nhà cung cấp, nên máy có thể mất tuyến mặc định thượng nguồn dù định tuyến hoàn hảo bên trong tunnel. Đặt accept_ra=2 ở nơi vẫn cần RA của nhà cung cấp.

Sau đó các quy tắc tường lửa phải cho phép tiền tố theo cả hai chiều, và ICMPv6 phải sống sót: phát hiện lân cận, packet-too-big và destination-unreachable không phải tùy chọn. Bỏ chúng đi thì phát hiện MTU đường đi hỏng, và bạn nhận được các kết nối mở ra rồi đứng lại ở phản hồi lớn đầu tiên. Một cặp quy tắc tối thiểu trông như sau:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU nằm phía sau điều này. Tunnel thu nhỏ MTU khả dụng xuống dưới 1500, và IPv6 yêu cầu mỗi liên kết mang ít nhất 1280. Ping nhỏ đi qua, phiên SSH đông cứng khi có đợt lớn, và /proc/net/snmp6 hiển thị các thông báo packet-too-big không bao giờ quay lại. Đặt MTU của tunnel một cách rõ ràng, hoặc giới hạn MSS TCP trong bảng mangle, và để ICMPv6 báo MTU nhỏ hơn quay về.

Kiểm tra đường trở về, không phải địa chỉ tunnel

Sự cố tốn nhiều thời gian nhất là định tuyến một chiều. Mỗi gateway định tuyến tiền tố xa vào tunnel, nhưng máy chủ trả lời qua gateway mặc định của chính chúng vì /64 của chúng nằm ở đó. Đưa một gói tin đến đích chỉ là nửa đường.

Hai lệnh giải quyết phần lớn. Tại site A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 cho biết phản hồi từ nguồn đó sẽ dùng giao diện nào; chạy kiểm tra đối xứng tại site B. Sau đó tạo lưu lượng từ máy chủ thay vì từ gateway, và so sánh bộ đếm ở hai đầu.

Nếu yêu cầu lân cận cho tiền tố xa xuất hiện trên tunnel, tiền tố đó đang on-link ở nơi không nên có; sửa điều đó trước khi chỉnh tuyến. Proxy NDP bao phủ các trường hợp thật sự cần bắc cầu, không phải thứ thay thế cho một tuyến.

Lập kế hoạch cho việc tiền tố thay đổi dưới chân bạn

Ủy quyền tiền tố là một hợp đồng thuê giữa router ủy quyền và router yêu cầu, và việc gia hạn có thể trả về một khối khác: một /56 khác sau khi nhà cung cấp di chuyển, hoặc thời hạn thuê ngắn hơn thời gian tunnel đã hoạt động. Mọi nơi nêu tiền tố cũ đều lỗi thời cùng lúc: tuyến, bộ chọn, AllowedIPs, quy tắc tường lửa, bản ghi DNS và mọi giám sát mã hóa cứng địa chỉ theo nghĩa đen. Luồng thông điệp nằm trong RFC 8415.

Ở nơi tiền tố được dự kiến sẽ di chuyển, hãy giữ một kế hoạch địa chỉ nội bộ không phụ thuộc vào nó và dịch ở biên. NPTv6 là lựa chọn không trạng thái và giữ chính sách nội bộ dễ đọc, nhưng đó là dịch tiền tố, không phải lớp ma thuật: ranh giới /64 phải khớp, checksum được điều chỉnh, và các ứng dụng nhúng địa chỉ theo nghĩa đen vẫn hỏng. Nếu bạn giữ địa chỉ nhà cung cấp từ đầu đến cuối, hãy ghi lại hành vi thuê và quy trình thay đổi trong kế hoạch địa chỉ.

Kết thúc bằng một bài kiểm tra chịu được thời gian: một máy chủ được phép trên mỗi LAN tới được dịch vụ trên LAN kia, phản hồi quay về qua tunnel, và cặp đó vẫn hoạt động sau khi khởi động lại tunnel và gia hạn ủy quyền. Nếu phần cuối thất bại, thiết kế phụ thuộc vào trạng thái không sống qua nổi một tuần.