Một giao diện WAN có thể phục vụ cả VPN giữa các site và VPN từ xa không?

Một địa chỉ công cộng có thể phục vụ đồng thời một đường hầm chi nhánh và một pool người dùng di động. Nhưng nó không thể phục vụ một quy tắc tiếp nhận dùng chung. Peer của chi nhánh và người dùng di động khác nhau ở việc họ tự nhận là ai, cách bằng chứng đó được kiểm tra, những địa chỉ họ nhận được và những tiền tố nào được phép trả lời họ. Khi bạn coi địa chỉ bên ngoài là chi tiết vận chuyển chứ không phải danh tính, thiết kế trở nên đơn giản hơn nhiều.

Một phép thử nhanh: hãy thử viết cả hai bản ghi tiếp nhận trước khi chạm vào bộ định tuyến. Nếu một điều kiện khớp phải bao trùm cả hai, chính sách đã mơ hồ, và triệu chứng đầu tiên sẽ trông như lỗi định tuyến hay tường lửa trong khi thực chất là lỗi danh tính.

Hai bản ghi trước mọi cấu hình

Bản ghi chi nhánh ngắn và ổn định. Nó liệt kê địa chỉ peer hoặc tên chứng chỉ, khóa chia sẻ trước hoặc điểm tin cậy của chứng chỉ, các mạng con được bảo vệ ở hai phía, giao diện đường hầm, và tuyến tĩnh đưa lưu lượng hướng về chi nhánh vào đường hầm đó. Mỗi trường liên quan đến một peer đã biết và một tập tiền tố cố định.

Bản ghi di động rộng hơn và riêng tư hơn. Nó liệt kê giao thức và cổng của máy khách, cách người dùng hoặc thiết bị xác thực, pool địa chỉ được cấp khi kết nối, các tài nguyên mà pool đó được phép chạm tới, các tiền tố của đường hầm chia tách, máy chủ DNS được đẩy về máy khách, và bất kỳ yếu tố thứ hai nào. Mỗi trường trả lời câu hỏi về một số người dùng không xác định chứ không phải về một cổng duy nhất.

Chính sự khác biệt về độ chi tiết đó là toàn bộ lý do hai vai trò tách khỏi nhau. Hồ sơ chi nhánh có thể tin cậy một khóa duy nhất vì khóa thuộc về một thiết bị tại một chỗ. Hồ sơ di động tin cậy một khóa nhóm cho tất cả mọi người sẽ phá hỏng trách nhiệm giải trình theo từng người dùng, và điều đó thường được phát hiện muộn hơn, khi rà soát sự cố chứ không phải khi triển khai.

Nơi việc khớp peer và xác thực tách nhau

Trên IOS XE, hồ sơ IKEv2 mang các tham số không thể thương lượng và các điều kiện dùng để chọn peer. Điều đó có nghĩa phía chi nhánh và phía di động mỗi bên cần hồ sơ riêng, ngay cả khi chúng kết thúc trên cùng một giao diện và ngay cả khi chúng chia sẻ cùng một PKI mật mã. Cisco ghi lại vai trò của hồ sơ, xác thực và khớp trong hướng dẫn cấu hình IKEv2 cho IOS XE 17.

Hồ sơ chi nhánh thường khớp với một danh tính hẹp: một địa chỉ từ xa, một FQDN hoặc một chủ thể chứng chỉ. Một thứ như match identity remote address 198.51.100.10 255.255.255.255 ghim một peer, và authentication remote pre-share với khóa lưu theo từng site là đủ. Giữ việc khớp cụ thể nhất mà danh mục peer cho phép, vì một wildcard chồng lấn ở vị trí cao hơn trong thứ tự chọn có thể kéo lưu lượng chi nhánh vào hồ sơ sai.

Hồ sơ di động không thể ghim địa chỉ, nên nó khớp với một nhóm, một key-id hoặc một trường chứng chỉ, rồi giao việc kiểm tra người dùng thực sự cho AAA hoặc cho chính sách ủy quyền gắn với hồ sơ. Sự tách biệt đó quan trọng: xác thực peer trả lời liệu máy khách có được phép dựng đường hầm, còn ủy quyền theo từng người dùng trả lời họ nhận pool nào và tài nguyên nào. Dùng khóa chi nhánh làm đăng nhập phổ quát là vứt bỏ câu trả lời thứ hai.

Chuyển tiếp và dịch địa chỉ cũng cần sự tách biệt đó

Tiếp nhận và khả năng tiếp cận là hai vấn đề khác nhau. Một cuộc trao đổi IKE và IPsec thành công chứng minh hai bên đồng ý về khóa; nó không tạo tuyến tới pool mà máy khách nhận được. Vì vậy các pool truy cập từ xa cần một đường quay về: hoặc tuyến tĩnh trỏ tới giao diện đường hầm, hoặc giao thức định tuyến tiêm bản tóm tắt pool. Các tiền tố chi nhánh thường đến qua cùng tiến trình định tuyến phục vụ phần còn lại của site.

Dịch địa chỉ là nơi hai vai trò va chạm thường xuyên nhất. Lưu lượng giữa các site phải giữ địa chỉ riêng của nó cần một miễn trừ NAT giới hạn trong hai tiền tố đó, theo cả hai hướng. Máy khách di động thường cũng cần miễn trừ cho lưu lượng trong đường hầm, nhưng lưu lượng ra internet của họ hoặc đi vòng qua đường hầm nhờ đường hầm chia tách, hoặc đi ra ở trung tâm sau NAT. Miễn trừ mọi thứ đến từ đường hầm là lỗi kinh điển, vì nó cũng lấy đi việc dịch địa chỉ của lưu lượng thực sự cần.

Giữ các quy tắc miễn trừ hẹp như các quy tắc tiếp nhận. Nếu bản tóm tắt pool và tiền tố chi nhánh chồng lấn, đường quay về trở nên mơ hồ từ rất lâu trước khi có gói nào bị bỏ, và triệu chứng xuất hiện như một site thỉnh thoảng mất một mạng con chứ không phải như một sự cố đường hầm sạch sẽ.

Các ca nghiệm thu phơi bày chính sách chéo

Dựng bốn ca và chạy theo thứ tự. Một máy chủ trong chi nhánh chạm tới tài nguyên chỉ dành cho chi nhánh. Một máy khách di động chạm tới cùng tài nguyên đó qua địa chỉ pool của mình. Một máy khách di động thử một tiền tố chi nhánh mà nó không được chạm. Peer của chi nhánh thử lấy địa chỉ từ pool truy cập từ xa. Hai ca cuối là những ca bắt được hồ sơ dùng chung, vì chúng thất bại âm thầm trong giám sát thông thường.

Sau đó xác nhận mặt phẳng dữ liệu chứ không phải cấu hình. show crypto ikev2 sa và show crypto ipsec sa cho biết hồ sơ nào và bộ chọn nào đã mang mỗi luồng, trong khi show ip nat translations và các bộ đếm đường hầm cho thấy đường quay về và miễn trừ có thực sự khớp hay không. Một tracer hoặc bắt gói trên giao diện đường hầm khép kín vòng lặp.

Ghi lại danh tính quan sát được, địa chỉ pool và chính sách đã chọn bên cạnh mỗi kết quả. Vòng chạy kết thúc khi mỗi ca ánh xạ tới đúng một bản ghi, và không ca nào cần một ngoại lệ tạm thời để vượt qua.