Chế độ trap của strongSwan: vì sao đường hầm IPsec chờ lưu lượng

Không có CHILD SA nào xuất hiện trong đầu ra trạng thái, đường hầm trông như chết, rồi một ping tới subnet xa đưa nó lên. Trong một thiết lập IPsec theo yêu cầu, trình tự đó chính là thiết kế, không phải lỗi. Một chính sách trap cài đặt bộ chọn và chờ, và gói đầu tiên khớp với nó là thứ khởi động IKE và đàm phán CHILD SA.

Một phần của sự nhầm lẫn là từ vựng: “up” được dùng cho hai trạng thái khác nhau. Cấu hình đã được tải và chính sách của nhân tồn tại, nhưng liên kết dữ liệu thì không. Một giám sát chỉ đếm SA đang hoạt động sẽ báo một trang khỏe mạnh là ngừng hoạt động chừng nào chưa ai gửi lưu lượng tới đó.

Đường hầm theo yêu cầu không hoạt động không có CHILD SA để hiển thị

Một mục trap không tự xác thực bất cứ điều gì. Nó yêu cầu nhân giữ một chính sách cho lưu lượng đã chọn và dựng một acquisition khi một gói cần chính sách đó. Daemon nhận acquisition, khớp nó với định nghĩa child và đàm phán từ đó. Cho tới thời điểm đó cũng không có IKE SA để hiển thị, vì vậy cả hai danh sách có thể trống cùng lúc.

Chính trình tự đó làm cho nhật ký dễ đọc. Đầu tiên acquisition đến, sau đó IKE_SA_INIT và IKE_AUTH, rồi đến CHILD SA. Nếu nhật ký kết thúc ngay sau acquisition, trình kích hoạt đã hoạt động. Đàm phán thất bại, và câu hỏi tiếp theo là về thông tin xác thực, đề xuất hoặc khả năng tiếp cận, không phải về trap.

Với backend của nhân Linux, bạn có thể xem chính sách trước khi bất kỳ SA nào tồn tại. Chạy ip xfrm policy và tìm bộ chọn có hướng out và một mẫu trỏ tới kết nối. Mục đó là trạng thái theo yêu cầu, và sự hiện diện của nó là điều đầu tiên cần xác nhận.

start_action quyết định có bất cứ thứ gì chờ hay không

Mỗi child trong swanctl.conf mang một start_action. start khởi động khi cấu hình được tải, trap cài đặt chính sách và chờ, và none để việc khởi tạo cho thứ khác. Chỉ trap tạo ra hành vi “ping và nó lên” được mô tả ở trên.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Hai bộ chọn lưu lượng xác định điều gì được coi là thú vị, và một gói từ máy ngoài các tiền tố đó không kích hoạt trap; nó được định tuyến như thường. Mở rộng bộ chọn để trình kích hoạt hăng hái hơn cũng mở rộng phạm vi mà đường hầm tuyên bố bảo vệ, vì vậy hãy lấy chúng từ lưu lượng bạn thực sự định mã hóa.

Tài liệu tham chiếu swanctl.conf liệt kê các giá trị được chấp nhận, cùng với các hành động close và DPD riêng điều chỉnh điều gì xảy ra khi SA đã tồn tại.

Tìm hiểu xem trình kích hoạt có thực sự kích hoạt không

Bắt đầu với swanctl --list-conns và xác nhận child đã được tải với hành động bạn định. Sau đó gửi một gói từ máy bên trong local_ts tới một địa chỉ bên trong remote_ts và quan sát swanctl --list-sas. Nếu đầu ra không thay đổi, không có acquisition nào tới được daemon.

Hai lý do thường gặp của một trap im lặng: gói đã bị source-NAT trước khi chạm chính sách và không còn khớp với local_ts, hoặc kết nối chưa bao giờ được tải do lỗi cú pháp hoặc thông tin xác thực. Chạy lại swanctl --load-all và đọc đầu ra trước khi chạm vào bộ chọn. Một kết nối không tải được thì không cài chính sách nào, nên không có gì để lưu lượng kích hoạt.

Hướng cũng quan trọng: một trap cài cho lưu lượng đi ra không khởi động trên gói đi vào. Nếu phía xa phải dựng đường hầm, nó cần trap riêng, hoặc phía này cần start.

Chờ gói đầu tiên không phải lúc nào cũng là đánh đổi đúng

Các phiên tương tác cảm nhận chi phí thiết lập. Yêu cầu đầu tiên trả giá cho trao đổi IKE và đàm phán CHILD, và một máy khách có hạn chót ngắn có thể bỏ cuộc trước khi SA tồn tại. start chủ động loại bỏ độ trễ gói đầu tiên đó. Nhưng nó giữ đường hầm mở cho lưu lượng có thể không bao giờ tới.

Ba sự thật quyết định lựa chọn: đường đi được dùng thường xuyên đến đâu, yêu cầu đầu tiên có hạn chót chặt hay không, và peer có tiếp cận được khi khởi động hay không. Lưu lượng theo lô không thường xuyên và một peer có thể ngoại tuyến khi khởi động đều ủng hộ trap. Một máy khách nhạy cảm với độ trễ và một peer luôn tiếp cận được ủng hộ start. Nếu cả hai bên đều có thể khởi tạo, hãy thống nhất ai sở hữu trình kích hoạt để không có đàm phán trùng lặp.

Một chính sách đã cài cũng không phải bảo đảm chống rò rỉ. Nếu yêu cầu là fail-closed, tường lửa phải bỏ lưu lượng không có SA, và quy tắc đó sống ngoài định nghĩa child.

Ghi lại ba dòng kết thúc cuộc tranh luận tiếp theo

Viết ra các bộ chọn, hành động khởi động và đầu ra lệnh cho thấy chính sách hiện diện mà không có SA. Ba dòng đó tách “theo yêu cầu và không hoạt động” khỏi “không tải được” lần tới khi ai đó báo đường hầm ngừng hoạt động. Chúng mất một phút để ghi lại. Không có chúng, cùng một cuộc điều tra lại bắt đầu từ số không.

Kiểm tra từ một máy thực sự nằm trong bộ chọn. Một ping từ chính router thường đi theo đường khác và không chứng minh được gì về chính sách bảo vệ subnet phía sau nó.