IPsec trong IPsec: đường hầm ngoài phải mang những địa chỉ nào

IPsec lồng nhau dễ suy luận hơn khi hai lớp kết thúc trên các máy khác nhau. Bốn cổng, hai đường hầm và một câu hỏi quyết định thiết kế có hoạt động không: đường hầm ngoài thực sự thấy gì khi đường hầm trong đã xử lý xong gói tin? Trả lời được điều đó thì bộ chọn, tuyến đường và thứ tự xử lý sự cố sẽ theo sau. Sai thì bạn sẽ mất một ngày gỡ lỗi một đường hầm mà về mặt kỹ thuật vẫn đang hoạt động.

Mô hình bốn cổng

Hai cổng ngoài A và B dựng đường hầm đầu tiên giữa hai site. Sau A là cổng trong C với địa chỉ trung chuyển 10.60.0.2; sau B là cổng trong D với địa chỉ trung chuyển 10.70.0.2. Các mạng ứng dụng nằm sau C và D, và mọi địa chỉ trong ví dụ đều cố ý không chồng lấn.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Chia các lớp cho bốn máy chủ nghĩa là mỗi máy thực thi một ranh giới. Một máy chủ chạy cả hai lớp phải dung hòa hai bộ chính sách, hai bảng định tuyến và hai chế độ lỗi trên cùng một máy, điều này khả thi nhưng khó quan sát hơn nhiều.

Mỗi lớp chỉ gỡ bỏ lớp bảo vệ của chính nó

C mã hóa một gói ứng dụng cho D. Kết quả được đánh địa chỉ từ C đến D, và đó là thứ đến được A. Mọi thứ phía sau đều phụ thuộc vào lần ghi lại đó.

A mã hóa nó lần nữa cho B. B giải mã lớp ngoài, thấy một gói từ C đến D và chuyển tiếp nó vẫn ở dạng mã hóa. D gỡ lớp bảo vệ trong và giao gói ứng dụng.

Vậy A và B thấy các điểm cuối bên trong và siêu dữ liệu của chúng, nhưng không phải là bên giải mã tải trọng ứng dụng. Đó là thuộc tính thực của thiết kế, không phải tuyên bố rằng C, D hay các máy chủ ứng dụng đáng tin cậy.

Bộ chọn ngoài đặt tên các cổng trong

Đây là chỗ hầu hết các cấu trúc kiểu này thất bại. Với đường hầm ngoài dựa trên chính sách, các bộ chọn bạn thương lượng phải chứa những địa chỉ mà A và B thực sự xử lý: 10.60.0.2/32 và 10.70.0.2/32, đúng thứ tự cục bộ và từ xa.

Đặt các subnet ứng dụng cuối vào bộ chọn ngoài không hoạt động, vì khi gói tin đến A, phần đóng gói bên trong đã ghi lại thứ mà A phải bảo vệ. Khi đó chính sách ngoài sẽ không khớp với gì cả, và đường hầm sẽ lên mà không mang dữ liệu.

Cũng đừng thu hẹp quyền ngoài xuống UDP 500. Kết nối bên trong có đường dữ liệu riêng, dùng ESP hoặc đóng gói UDP tùy theo những gì đã thương lượng, và chính sách ngoài phải cho phép giao thức đó.

Kiểm tra kết quả bằng swanctl --list-sas trên từng cổng và xác nhận rằng các liên kết bảo mật con báo cáo những địa chỉ bạn dự định, không phải những địa chỉ bạn giả định. Nếu danh sách hiển thị các subnet ứng dụng, chính sách ngoài đã được viết cho sai lớp. Sửa bộ chọn trước khi gỡ lỗi định tuyến, vì định tuyến sẽ trông ổn và các bộ đếm sẽ không nhúc nhích.

Chuyển tiếp và cái bẫy đệ quy

Bộ chọn không thay thế định tuyến. A và B phải chuyển tiếp lưu lượng giữa C và D theo cả hai chiều, nghĩa là bật chuyển tiếp IP, có tuyến đường trỏ tới đường hầm và có đường quay về tồn tại ở phía bên kia.

Nếu đường hầm ngoài dùng giao diện XFRM, các tuyến chọn giao diện trong khi chính sách đã thương lượng vẫn giới hạn những gì nó mang. Giao diện không mở rộng phạm vi được bảo vệ; nó chỉ thay đổi cách nhân lấy gói tin.

Cái bẫy là đệ quy. Tuyến của A tới điểm cuối ngoài của B phải đi theo mạng nền, không phải đường hầm A đang dựng, nếu không phần đóng gói sẽ cố đi bên trong chính nó và kết nối không bao giờ hoàn tất.

Kiểm tra bản dịch trước khi thêm lớp

Xem mọi NAT nguồn trên A và B trước khi tinh chỉnh bất cứ thứ gì khác. Một quy tắc ghi lại địa chỉ của C trước khi chính sách IPsec áp dụng có thể phá vỡ các bộ chọn đã thống nhất, và cũng có thể thay đổi những gì D nhận được ở phía bên kia.

Đánh lừa rộng không trở nên an toàn hơn nhờ có hai lớp. Nó giấu việc đầu xa thấy địa chỉ nào, và đó chính là thông tin bạn cần khi đường hầm đang lên mà ứng dụng không chạy.

Nếu quy tắc NAT thực sự cần thiết, hãy ghi lại mỗi bên nghĩ mình đang nói chuyện với địa chỉ nào. Một dòng đó giải quyết phần lớn tranh cãi về việc đường hầm hay bản dịch là thủ phạm. Nó cũng cho kỹ sư tiếp theo biết nhìn vào đâu khi quy tắc bị gỡ một năm sau. Ping sẽ không làm được điều nào trong số đó.

Chứng minh fail-closed và kiểm tra MTU

Một tuyến biến mất tự nó không phải là chính sách fail-closed. Một bảng khác, tuyến mặc định hoặc quy tắc chính sách có thể lặng lẽ cung cấp phương án dự phòng, và cách duy nhất để biết là hạ đường hầm ngoài xuống và quan sát lưu lượng ứng dụng làm gì. Hãy làm điều đó có chủ đích, trong một cửa sổ bảo trì, thay vì phát hiện tình cờ.

Thử ba trạng thái: đường hầm ngoài tắt, đường hầm trong tắt và phục hồi sau khi cả hai trở lại. Dùng bộ đếm chính sách trên từng cổng, vì hai phiên IKE đã thiết lập chỉ chứng minh rằng thương lượng ở mặt phẳng điều khiển thành công.

Lập ngân sách cho cả hai lần đóng gói. IKE hoạt động là kết quả của gói nhỏ, và gói ứng dụng kích thước đầy đủ vẫn có thể thất bại khi thêm hai tiêu đề; hãy thử với kích thước tải trọng đã biết trên tuyến thật thay vì giả định các con số cộng lại. Số học thì dễ, tuyến đường thì không.