Hình sao hay lưới đầy đủ: topo VPN nào phù hợp với các site của bạn
Hai đường hầm đang chạy chưa phải là một topo. Trước khi chọn một hub, một lưới đầy đủ hay một hub với vài liên kết trực tiếp, hãy so sánh đường trung chuyển, hành vi khi sự cố và chi phí thay đổi.
Hai văn phòng chi nhánh nói chuyện với nhau cả ngày, và đường hầm giữa chúng vòng qua một trung tâm dữ liệu ở vùng khác. Mỗi yêu cầu trả giá cho vòng đó hai lần, và không ai nhận ra cho đến khi đồng bộ tệp bắt đầu có cảm giác sai. Đó là nơi câu hỏi về topo thực sự bắt đầu: không phải sơ đồ nào trông kiên cố hơn, mà là bạn đang trả tiền cho mẫu lưu lượng nào. Cả hai thiết kế đều chạy, và cả hai đều hỏng theo những cách khác nhau với chi phí khác nhau.
Đếm số quan hệ ngang hàng trước tiên
Với N site, lưới đầy đủ cần N nhân N trừ một, chia hai, đường hầm; hub chỉ cần N. Ở năm site là mười so với năm, vẫn nghe có vẻ xử lý được. Ở mười lăm site là 105 so với mười lăm, và khác biệt không còn là số học mà là nhân sự.
Mỗi quan hệ đó mang theo trạng thái bạn phải quản. Với IPsec, đó là một hiệp hội bảo mật, một danh tính, một khóa hoặc chứng chỉ, phát hiện peer chết và ít nhất một tuyến cho mỗi tiền tố từ xa. Với WireGuard, đó là một khóa công khai và một khối AllowedIPs cho mỗi peer; rẻ hơn trên mỗi peer nhưng hoàn toàn không có cơ chế khám phá: một site mới dù sao cũng là thay đổi cấu hình trên mọi site sẵn có.
Để thành phần lưu lượng quyết định, không phải bản vẽ
Nếu lưu lượng chi nhánh chủ yếu là yêu cầu tới một ERP trung tâm hoặc cụm tệp, hub không phải thỏa hiệp mà là hình dạng đúng: lưu lượng vốn đã muốn đi tới đó, và một điểm chính sách dễ kiểm toán hơn một lưới quy tắc theo cặp. Lưới đầy đủ đáng giá với độ phức tạp của nó khi các chi nhánh trao đổi dữ liệu với nhau: sao chép giữa hai văn phòng, thoại giữa các site, một thư mục CAD mà cả chục kỹ sư mở suốt ngày.
Những trường hợp khó xử nằm ở giữa, và chúng là số đông. Hãy đo trước khi tranh luận, thay vì đoán từ sơ đồ tổ chức.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Đọc bảng như yếu tố phân xử, không phải quy tắc. Ba trong bốn dòng nghiêng về một phía thường là đủ chốt thiết kế, còn chia đôi nghĩa là mô hình lai, thứ mà phần lớn mạng trưởng thành rốt cuộc vẫn chạy.
Phải nói cho hub biết là nó cần chuyển tiếp
Hai đường hầm nhánh-hub đang chạy không tạo ra truy cập giữa các nhánh. Hub cần bật chuyển tiếp IP, một tuyến tới mỗi mạng nhánh, một quy tắc tường lửa cho phép trung chuyển và đường về được tính toán; mỗi nhánh cần một tuyến tới các tiền tố của site kia. Trên hub Linux, đó là net.ipv4.ip_forward=1 cộng một chuỗi FORWARD không âm thầm bỏ cặp gói, còn với IPsec dựa trên chính sách thì là các bộ chọn lưu lượng liệt kê mạng con của nhánh từ xa ở cả hai đầu. strongSwan ghi chú về chuyển tiếp bao quát phía nhân và tường lửa khi đúng lớp đó là thứ bạn còn thiếu. Một phép thử rẻ: gửi lưu lượng từ nhánh này tới một dịch vụ ở nhánh kia trong khi xem bộ đếm của hub; một quy tắc không bao giờ tăng nghĩa là sai thứ tự, không phải sai tuyến.
Chính sách trung tâm cũng là phần hữu ích. Có thể cho các chi nhánh tới dịch vụ dùng chung mà không tới được nhau, và ma trận truy cập đó đáng được ghi rõ. Tuyến thiếu là thứ thay thế tồi cho một quy tắc mà người ta đọc được.
Coi chừng phiên bản làm nửa vời: nhánh A định tuyến tới nhánh B qua hub, hub định tuyến cả hai chiều, và tường lửa của hub cho phép kết nối mới từ A nhưng không từ B. Chiều thứ nhất kiểm tra ổn, chiều thứ hai treo, trông như lỗi định tuyến nhưng không phải.
Thiết kế sự cố trước, rồi mới tới đường bình thường
Một hub duy nhất là phụ thuộc chung và nút thắt trung chuyển, còn dự phòng là chỗ các thiết kế hub thường sai. Hai hub nghĩa là mỗi nhánh giữ hai đường hầm, và đường về phải khớp với đường đi; khi không khớp, tường lửa có trạng thái bỏ gói trả lời, và triệu chứng là một kết nối mở ra rồi chết. Các triển khai lớn giải quyết bằng giao thức định tuyến chạy trên các đường hầm thay vì tiền tố tĩnh: nhiều máy móc hơn nhưng bỏ được việc đoán. Dù chọn gì, hãy ghi đường về ngay cạnh đường đi, vì nửa đường về là nửa không ai kiểm tra.
Lưới đầy đủ trải rủi ro đó ra: đứt liên kết một site không cô lập các site còn lại. Nhưng nó cũng nhân lên những chỗ việc chọn đường có thể làm bạn bất ngờ, và phiên ứng dụng vẫn không sống qua việc đổi đường nếu không có trợ giúp.
Không thiết kế nào tự giữ một phiên TCP sống qua một lần chuyển đổi. Nếu ứng dụng không thể kết nối lại, topo không phải vấn đề của bạn.
Chọn theo chi phí thay đổi, rồi kiểm tra các tuyến
Bắt đầu từ hub, vì đó là thứ rẻ hơn nếu chọn sai, và thêm đường hầm trực tiếp cho những cặp mà lưu lượng biện minh cho nó. Mô hình lai đó không phải là thất bại trong việc quyết định; đó là thiết kế mà phần lớn tổ chức hội tụ về trong vòng một năm. Điều quan trọng là mỗi liên kết trực tiếp có lý do được nêu và có người chịu trách nhiệm.
Sau đó kiểm tra hai bản vẽ thay vì một. Với đường bình thường, chạy traceroute từ mỗi site tới mỗi tiền tố dịch vụ và xác nhận các hop khớp với sơ đồ. Với đường sự cố, tắt một đường hầm rồi lặp lại, vì một tuyến chỉ chạy khi mọi thứ còn sống thì chưa được thiết kế, chỉ mới được cấu hình.
Giữ cả hai bản vẽ cùng ma trận truy cập, và xem lại chúng khi thêm site; chi phí bạn đang quản là chi phí của lần thay đổi tiếp theo, không phải vẻ thanh lịch của bức hình hiện tại.