Thêm subnet thứ hai vào VPN site-to-site: hai con đường
Đường hầm dựa trên chính sách cần bộ chọn khớp ở cả hai đầu; loại dựa trên tuyến chỉ cần một tuyến. Chọn đúng đường và sửa tuyến hồi về trước.
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 style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A 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 đó.