Thêm subnet thứ hai vào một đường hầm site-to-site đang chạy mất năm phút với kiểu thiết kế này và gần cả buổi chiều với kiểu kia. Khi đường hầm cài tuyến cho các tiền tố bạn nêu, bạn thêm một tuyến và lưu lượng đi theo. Khi nó thương lượng một cặp bộ chọn cố định, tiền tố mới vẫn không được bảo vệ cho đến khi hai bên đồng ý một cặp khớp nhau. Ba điều quyết định: cấu hình mỗi bên thực sự mô tả gì, lưu lượng đã thương lượng có thu hẹp về cặp khớp nhỏ nhất không, và ai sở hữu tuyến hồi về cho dải mới.

Đọc nhân, không đọc nhãn trạng thái

Một đường hầm báo đã kết nối đã cài ít nhất một liên kết con, nhưng không nhất thiết là cái bạn nghĩ. Trên Linux nhân cho thấy điều gì được áp dụng: ip xfrm policy liệt kê các cặp bộ chọn và swanctl --list-sas (hoặc ipsec statusall cũ) cho thấy hai bên đã thương lượng gì, gồm cả bộ chọn lưu lượng theo mỗi hướng. Nếu tiền tố mới không có trong cả hai, nó không được bảo vệ, bất kể tệp cấu hình nói gì.

So sánh với bảng tuyến. Trong thiết kế dựa trên tuyến, thiết bị đường hầm là chặng kế tiếp cho các tiền tố được bảo vệ. Thiết kế dựa trên chính sách thường không có tuyến riêng cho subnet từ xa, chỉ có tuyến mặc định, vì chính sách chọn lưu lượng chứ không phải bảng.

Dựa trên chính sách: cả hai bên phải liệt kê tiền tố mới

Trong thuật ngữ strongSwan, bộ chọn nằm ở local_ts và remote_ts dưới cấu hình con, là kế thừa của leftsubnet và rightsubnet. Tiền tố mới phải xuất hiện ở cả hai bên như ảnh gương: điều site A gọi là cục bộ thì site B gọi là từ xa. Sự không khớp hiếm khi cho một lỗi rõ ràng. Hai bên thu hẹp về phần giao, tiền tố cũ vẫn chạy và chỉ cái mới thất bại âm thầm.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

Trên pfSense hoặc OPNsense điều đó nghĩa là một mục Phase 2 thứ hai ghép subnet cục bộ mới với subnet từ xa mới, rồi áp dụng. Giữ mục cũ; thay thế nó sẽ di chuyển subnet gốc thay vì thêm vào. Nếu một Phase 2 đang có đã phủ một siêu mạng như 0.0.0.0/0 hoặc một dải tóm tắt, đừng thêm mục hẹp hơn bên cạnh: các bộ chọn chồng lấn cài những chính sách cạnh tranh và thứ tự đánh giá quyết định bên thắng.

IKEv1 biến mỗi cặp subnet thành Phase 2 riêng, và bên chỉ nhận một cặp mỗi lần trao đổi sẽ bỏ phần còn lại. IKEv2 có thể mang nhiều cặp bộ chọn trong một liên kết con, nhưng chỉ khi cả hai bản triển khai chấp nhận. Danh sách từ swanctl --list-sas là sự thật; điều bạn gõ là một yêu cầu.

Dựa trên tuyến: tuyến chính là chính sách

Giao diện XFRM hoặc thiết bị VTI mang lưu lượng theo bảng tuyến. Bạn trỏ tiền tố mới vào thiết bị ở cả hai site, và trạng thái gắn với phép biến đổi của giao diện được áp dụng. Không có cặp bộ chọn nào để đồng bộ, vì thế thiết kế này mở rộng tốt hơn khi subnet tăng. Hướng dẫn chuyển tiếp của strongSwan đi sâu vào phía nhân.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard đi xa hơn. AllowedIPs đồng thời là danh sách cho phép mật mã và, qua wg-quick, là mục trong bảng tuyến. Thêm tiền tố chỉ ở một bên và bạn có bắt tay, gói đi ra và sự im lặng, vì bên kia bỏ các gói có nguồn không nằm trong danh sách của nó. Dạng wg set thay toàn bộ danh sách, nên hãy nêu lại các tiền tố đã chạy được, nếu không bạn sẽ cắt chúng:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Lệnh thứ hai không phải tùy chọn khi bạn dùng wg set thay vì wg-quick. Nhân chấp nhận danh sách mới ngay, nhưng không gì thêm tuyến cho nó, nên lưu lượng tạo cục bộ vẫn ra qua cổng mặc định. Đây là lý do phổ biến nhất khiến subnet WireGuard mới chạy được từ máy chủ đường hầm mà không chạy từ laptop.

Tuyến hồi về hỏng thường xuyên hơn đường hầm

Các máy trong subnet từ xa mới phải gửi trả lời qua cổng VPN. Khi cổng đó không phải router mặc định của chúng, trả lời đi tới router LAN, nơi bỏ nó hoặc chuyển tiếp ra internet với địa chỉ nguồn riêng. Hãy thử từ một máy ở phía xa chứ không phải từ cổng: ip route get 10.30.20.15 trên Linux hoặc Find-NetRoute -RemoteIPAddress 10.30.20.15 trong PowerShell cho thấy chặng kế tiếp mà máy thực sự dùng. Nếu trả lời không phải điểm cuối đường hầm, hãy thêm tuyến tĩnh cho tiền tố mới ở đó.

NAT nguồn ở site thiếu tuyến hồi về là lựa chọn hợp lệ và là cách nhiều triển khai hub-and-spoke tránh chạm vào từng máy chủ. Áp dụng nó cho tiền tố mới ở cổng phía đích nữa:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Cái giá là thật. Nhật ký từ xa không còn hiện địa chỉ nguồn riêng lẻ và các quy tắc tường lửa dựa trên subnet gốc gộp thành một quy tắc cho cổng. Hãy chọn điều đó có chủ đích, không phải vì thiếu tuyến.

Tường lửa là nửa còn lại của tuyến hồi về. Thiết bị dựa trên vùng không tự mở rộng vùng của giao diện đường hầm sẵn có sang subnet mới, và quy tắc viết cho tiền tố cũ sẽ không khớp. Thêm subnet mới vào vùng hoặc vào cặp quy tắc theo cả hai chiều trước khi đổ lỗi cho IPsec.

Quyết định bằng ba câu hỏi, rồi kiểm chứng bằng lưu lượng

Bản ngắn: cấu hình của bên có nêu tiền tố (dựa trên chính sách), hay lưu lượng được định tuyến vào một giao diện (dựa trên tuyến)? Cả hai đầu có liệt kê tiền tố mới? Có đường trở về từ subnet mới tới dải nguồn gốc không?

Tunnel styleWhere the prefix goesWhat breaks if you skip it
Policy-based IPsecSelector pair on both peersOld subnets work, the new one fails with no clear error
Route-based XFRM or VTIRoute into the device on both sitesPackets routed but not transformed, or the state never matches
WireGuardAllowedIPs on both peers plus a routeHandshake succeeds, replies are dropped
Overlapping supernetAdjust the existing entry insteadA shadowed policy wins or loses by evaluation order

Kiểm chứng là nơi phần lớn thay đổi bị đóng quá sớm. Ping từ cổng chứng minh ít, vì cổng gửi từ chính nó và thường khớp một chính sách khác với máy. Hãy ping từ một máy trong subnet mới, rồi chạy ứng dụng đã khiến bạn thay đổi, và xem bộ đếm chứ không phải biểu tượng trạng thái.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Trên đường hầm dựa trên chính sách, bộ đếm của ip xfrm state phải tăng ở cả hai chiều; bộ đếm phẳng nghĩa là gói được định tuyến nhưng không được chọn. Trên WireGuard, wg show báo cáo truyền tải theo mỗi bên, và một bắt tay không nhận được byte nào chỉ vào danh sách của bên kia hoặc tuyến hồi về của nó.

Kết thúc bằng việc ghi lại tiền tố, bộ chọn hoặc tuyến của bên, quyết định về tuyến hồi về và mục tường lửa cùng phần còn lại của bản kiểm kê đường hầm. Sau đó khởi động lại một cổng và thử lại: tuyến thêm bằng tay sẽ biến mất, và người tiếp theo không phải phát hiện lại điều đó.

Bài viết liên quan