Router giữa hai peer IPsec có cần IPsec không?

Một bài tập phòng thí nghiệm nói “cấu hình IPsec giữa hai site” che giấu hai công việc khác nhau. Hai điểm cuối kết thúc đường hầm: chúng thương lượng, xác thực, mã hóa và giải mã. Bất kỳ router nào ở giữa đều chuyển tiếp các gói có tiêu đề ngoài thuộc về các điểm cuối, và nó làm vậy mà không biết đường hầm tồn tại.

Quyết định thiết bị đang được yêu cầu làm công việc nào là bước đầu tiên của bài tập. Phần lớn sự nhầm lẫn trong các báo cáo phòng thí nghiệm, và một phần đáng kể sự nhầm lẫn trong các sơ đồ sản xuất, đến từ việc coi “hỗ trợ IPsec” là một thuộc tính thay vì hai.

Chuyển tiếp không phải kết thúc

Ở chế độ đường hầm, tiêu đề IP ngoài được gửi đến các thiết bị kết thúc đường hầm. Một router ở giữa tra cứu đích và chuyển tiếp, đúng như với bất kỳ gói tin nào khác, và tải trọng nó mang là không trong suốt đối với router.

Sự không trong suốt đó là có chủ ý. Router không giữ bí mật của peer, không chạy thương lượng và không cần cơ sở dữ liệu chính sách. Nó cần một tuyến đến điểm cuối xa và quyền chuyển tiếp gói tin.

Nhầm lẫn hai việc dẫn đến sai sót thực tế: yêu cầu tường lửa trung chuyển “cho phép IPsec” trong khi yêu cầu thực sự là cho phép giao thức 50 giữa các địa chỉ cụ thể, hoặc mong đợi thiết bị giữa giải mã để kiểm tra trong khi nó không có khóa.

Thiết bị giữa vẫn phải làm đúng điều gì

Việc chuyển tiếp có những yêu cầu riêng. Các tuyến phải đến được cả hai điểm cuối bên ngoài, và mọi chính sách trên đường đi phải cho phép lưu lượng bên ngoài thực tế thay vì một số cổng đoán mò. Một quy tắc viết theo TCP 443 vì ai đó giả định TLS sẽ không khớp với giao thức 50.

ESP gốc là giao thức IP 50. Nó không phải TCP 50 và không phải UDP 50, và một quy tắc chặn lưu lượng không phải TCP sẽ loại bỏ nó. Nếu thiết kế dùng đóng gói UDP, giao vận hiển thị chuyển sang cổng đóng gói, và chính sách phải khớp với thiết kế đã chọn.

Kích thước gói cũng quan trọng. Một tuyến mang theo đầu dò nhỏ không chứng minh rằng toàn bộ trao đổi đóng gói vừa khít. Một đường đi loại bỏ các gói lớn có thể để thương lượng thành công và khối lượng công việc thất bại, trông giống như sự cố ứng dụng. Hãy thử với lưu lượng có kích thước bằng khối lượng công việc thực trước khi đổ lỗi cho đường hầm.

Vì sao trình mô phỏng thay đổi câu hỏi

Trình mô phỏng không phải là router có danh sách tính năng ngắn hơn; nó là một mô hình với tập con được ghi nhận và các quy tắc riêng về những gì một thiết bị cụ thể có thể được cấu hình để làm. Câu hỏi thường gặp của Packet Tracer từ Cisco nói rõ rằng thiết bị và giao thức là các mô hình được đơn giản hóa.

Vậy câu hỏi trở thành ba câu hỏi. Thiết bị được mô phỏng có chuyển tiếp các gói mà kịch bản cần không? Cùng thiết bị đó có cung cấp bề mặt cấu hình mà bài học giả định không? Và lệnh được chấp nhận có nghĩa là hành vi thực sự được mô phỏng hay chỉ được phân tích cú pháp?

Một lệnh vắng mặt có thể là giới hạn của mô hình chứ không phải lỗi trong cấu hình của bạn. Một lệnh hiện diện có thể chấp nhận cú pháp mà không tái tạo mọi hành vi sản xuất. Hãy xem trợ giúp thiết bị của phiên bản đã cài trước khi kết luận theo hướng nào.

Viết điều kiện đạt cho bài lab

Với bài học underlay, điều kiện đạt là khả năng tiếp cận của các điểm cuối cùng các gói bên ngoài đi qua thiết bị giữa. Hãy chứng minh bằng bộ đếm của chính trình mô phỏng hoặc chế độ xem gói, và nêu tên giao thức bạn mong đợi thấy.

Với bài học IPsec, hãy thêm trạng thái thương lượng và một luồng LAN-tới-LAN được bảo vệ. Nếu trình mô phỏng hiển thị các hiệp hội bảo mật, hãy ghi lại. Nếu không, hãy nói rõ điều đó trong báo cáo thay vì ngụ ý rằng đường hầm đã được kiểm chứng.

Giữ phiên bản trình mô phỏng, thiết bị đã chọn và mục tiêu học tập cùng với tệp cấu trúc liên kết. Chính bản ghi đó cho phép người khác tái tạo bài tập và hiểu phần nào đã được mô hình hóa.

Cấu hình sản xuất cần bằng chứng nền tảng riêng. Một gói mô phỏng xanh là kết quả giảng dạy, không phải tuyên bố về tính tương thích của phần cứng bạn sẽ triển khai.