Lập kế hoạch IPv6 cho một hub WireGuard hai site: tiền tố, peer, tuyến

Hai LAN, một hub WireGuard và một kế hoạch địa chỉ IPv6 phải trả lời ba câu hỏi riêng biệt: tiền tố nào, địa chỉ nào thuộc về router nào, và peer nào sở hữu subnet nào. Sai một trong số đó sẽ tạo ra một đường hầm bắt tay được mà không định tuyến gì. Kế hoạch dưới đây đi qua một thiết kế riêng hai site theo thứ tự đó. Nó cố ý không cung cấp truy cập Internet qua IPv6.

Quyết định tiền tố dùng để làm gì

Một tiền tố cục bộ duy nhất từ fd00::/8 là lựa chọn tự nhiên khi mục tiêu là khả năng tiếp cận riêng giữa các site. Nó ổn định bất kể nhà cung cấp nào phục vụ mỗi vị trí và không được quảng bá trong bảng định tuyến toàn cầu, nên không thể làm rò rỉ cách đánh số nội bộ của bạn ra Internet.

Cùng thuộc tính đó cũng là giới hạn. ULA không cho đường quay về công cộng, vì không nhà cung cấp thượng nguồn nào biết phải định tuyến nó tới gateway của bạn. Nếu yêu cầu bao gồm lối ra Internet qua IPv6, bạn cần một phân bổ từ nhà cung cấp định tuyến nó về phía bạn, và đó là một quyết định thiết kế riêng với kích thước tiền tố của nó.

Đừng giả định mọi triển khai đều cần /48. RFC 6177 đã rời bỏ một kích thước bắt buộc duy nhất cho site đầu cuối, và kích thước đúng phụ thuộc số mạng bạn sẽ vận hành. Tạo ULA bằng thủ tục RFC 4193 thay vì bịa ra một tiền tố mà tổ chức khác cũng có thể dùng. Ghi kết quả vào kế hoạch địa chỉ trước khi cấu hình bất kỳ thiết bị nào, vì một tiền tố không ai ghi lại là tiền tố mà ai đó sẽ dùng lại.

Chia tiền tố thành các vai trò

Ví dụ dưới đây dùng fd7c:2e91:4a00::/48, và bảng được sắp theo nơi mỗi khối được ghi, không theo site. Hãy coi các giá trị là ví dụ và tạo của riêng bạn trước khi triển khai bất cứ thứ gì.

Các khối LAN là /64 vì SLAAC thông thường mong đợi một định danh giao diện 64 bit. Chia một LAN thành khối nhỏ hơn phá vỡ giả định đó trên hầu hết máy chủ, và chi phí vận hành không đáng so với tiết kiệm địa chỉ trong một kế hoạch riêng. Cả hai khối LAN đến từ giữa /48, để dải thấp trống cho các site sau.

Địa chỉ đường hầm là một kho quản trị, không phải mạng trên liên kết. Mỗi giao diện nhận một /128 từ đó, nên không máy chủ nào giả định một subnet chia sẻ trên đường hầm và việc dò lân cận không chạy ở nơi không cần. Giữ các vai trò tách rời và ghi chúng vào kế hoạch địa chỉ của tổ chức để site sau không dùng lại một khối.

Cho mỗi router một địa chỉ đường hầm

Gán một /128 cho mỗi router và giữ nguyên khóa cùng điểm cuối hiện có của hub đang hoạt động. Ba giá trị dưới đây chỉ khác ở phần máy chủ.

Hub:    Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128

/128 này mô tả địa chỉ duy nhất được gán cho giao diện đó. Nó không nói gì về số đích mà peer có thể định tuyến, vì khả năng tiếp cận được biểu đạt trong AllowedIPs chứ không phải trong tiền tố giao diện.

Mỗi router site cũng cần một địa chỉ trong khối LAN của nó và một cách phân phối địa chỉ đó, thường là quảng cáo router cho SLAAC. WireGuard không gửi những quảng cáo đó thay bạn và không bắc cầu hai LAN. Router site là router theo cả hai chiều.

Đặt quyền sở hữu subnet trong AllowedIPs

Mục peer của hub cho Site A sở hữu địa chỉ đường hầm của A và LAN của A, và cặp đó là toàn bộ tuyên bố sở hữu. Không gì khác trong phần peer đó cần mô tả site.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

Mục peer cho Site B sở hữu cặp tương ứng, và ở đây tính đối xứng quan trọng hơn sự ngắn gọn. Đọc hai dòng cùng nhau và cách phân chia quyền sở hữu hiện ra trong một cái nhìn.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Đây là hai phần peer riêng biệt, không phải hai danh sách tranh nhau một peer. WireGuard dùng AllowedIPs theo cả hai chiều: nó chọn peer cho một đích đi ra và từ chối một gói đi vào có nguồn không khớp với dải được gán cho peer đã giải mã gói đó. Gán toàn bộ /48 cho cả hai peer sẽ vô hiệu hóa lần kiểm tra thứ hai và làm mờ việc site nào sở hữu khối nào. Chính sự phân biệt đó khiến một địa chỉ nguồn sai hiện ra thay vì được chấp nhận âm thầm.

Mỗi site chỉ cần những đích tiếp cận được qua peer hub của nó: Site A liệt kê địa chỉ hub, địa chỉ đường hầm của Site B và LAN của B, còn Site B liệt kê tập ngược lại. Các danh sách bất đối xứng là có chủ ý, vì mỗi router nhìn một phía khác của topo. Hãy viết cả hai từ kế hoạch địa chỉ chứ không từ cấu hình của site kia, vì đó là cách một dải cũ sống sót qua việc đánh số lại.

Với wg-quick, các dải này cũng tạo tuyến. Với systemd-networkd hoặc cấu hình thủ công, hãy tự thêm các tuyến tương đương; nếu không, đường hầm mang những gói mà nhân hệ điều hành không bao giờ gửi vào đó.

Hoàn tất chuyển tiếp và kiểm tra cả hai chiều

Bật chuyển tiếp IPv6 trên hub và trên cả hai router site, và cho phép các dịch vụ liên site cần thiết trong chính sách chuyển tiếp. Giữ các thông điệp ICMPv6 Packet Too Big dùng được, vì bỏ chúng sẽ phá vỡ việc dò MTU đường đi và tạo ra tắc nghẽn khi truyền lớn trông như lỗi ứng dụng. Một hub chuyển tiếp mà không có sự cho phép của tường lửa sẽ bỏ gói giữa định tuyến và đường hầm. Chế độ hỏng đó đáng để biết, vì đường hầm vẫn hoạt động và chỉ một số luồng chết.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Kiểm tra từ một máy chủ ở Site A tới một máy chủ ở Site B rồi theo chiều ngược lại. Ping tới địa chỉ đường hầm của hub chỉ thử chặng đầu và sẽ thành công kể cả khi tuyến LAN sai. Chính luồng máy chủ tới máy chủ mới chứng minh kế hoạch.

Kết nối WireGuard bên ngoài có thể chạy trên IPv4 trong khi lưu lượng bên trong là IPv6, và sự độc lập đó hữu ích khi chuyển đổi. Nếu sau này thêm lối ra IPv6 toàn cầu, hãy xem lại phân bổ của nhà cung cấp, việc chọn địa chỉ nguồn và định tuyến quay về như một bước thiết kế mới; kế hoạch riêng ở trên vẫn đúng cho lưu lượng giữa các site.