Một đề xuất IPsec gồm những gì? Các trường IKE và ESP

IKE khởi động, cả hai bên công bố AES, và đường hầm vẫn thất bại với NO_PROPOSAL_CHOSEN. Nhật ký nêu tên đề xuất nhưng không nêu trường nào không khớp. Một đề xuất là một lời chào hàng trọn vẹn, và một trường không tương thích làm vô hiệu toàn bộ tổ hợp chứ không chỉ dòng đó. Đọc nó như một túi lựa chọn thuật toán độc lập chính là lý do thường gặp khiến sự không khớp vẫn vô hình.

Hai cuộc thương lượng với danh sách đề xuất riêng

IKEv2 dựng hai hiệp hội bảo mật. Cái thứ nhất là IKE SA, bảo vệ chính việc trao đổi điều khiển, và cái thứ hai là CHILD SA, mang lưu lượng của bạn qua ESP. Mỗi cái có danh sách đề xuất riêng, và một bên có thể chấp nhận cái này và từ chối cái kia.

Cách tách đó giải thích một nhầm lẫn phổ biến: IKE SA hoạt động chỉ chứng minh rằng các thuật toán của kênh điều khiển đã khớp. Nếu đề xuất CHILD thất bại, đường hầm không mang một gói nào, dù giai đoạn một đã xong và nhật ký trông khỏe ở phần trên.

Thứ tự bên trong mỗi danh sách cũng quan trọng. Bên trả lời chọn từ các chào hàng đã sắp xếp của bên khởi tạo, nên chuyển một mục tương thích rộng lên trên một mục hẹp sẽ thay đổi bộ nào được cài đặt mà không đổi bất kỳ tên thuật toán nào. Hãy ghim thứ tự đó trong cấu hình thay vì dựa vào giá trị mặc định. Một thứ tự ổn định cũng khiến việc so sánh nhật ký giữa các site có ý nghĩa.

Trường nào thuộc đề xuất nào

Bộ trường không nhiều, nhưng không giống hệt nhau trong hai cuộc thương lượng. Hãy đọc bảng theo từng dòng, vì một trường ở cột này có thể vắng ở cột kia. Cú pháp khác nhau tùy cách hiện thực; tài liệu về đề xuất của strongSwan là một tham chiếu cụ thể.

Trường mã hóa nêu tên thuật toán mã và, trong hầu hết cú pháp, độ dài khóa của nó. Trường toàn vẹn nêu hàm băm dùng để xác thực bản mã, và PRF nêu hàm dẫn xuất vật liệu khóa cho IKE SA. Nhóm DH thiết lập vật liệu bí mật dùng chung mới, vì thế nó xuất hiện ở cả hai phía nhưng cho mục đích khác nhau.

Số thứ tự mở rộng chỉ thuộc đường dữ liệu. Chúng mở rộng không gian thứ tự và được thương lượng như một phần của đề xuất CHILD, nên sự không khớp ở đó từ chối một chào hàng CHILD trong khi IKE SA vẫn nguyên vẹn.

Một lời chào hàng trọn vẹn được chọn như thế nào

Mỗi đề xuất là một tập, và bên trả lời tìm một tập mà mọi trường bắt buộc đều chấp nhận được. Hai danh sách có thể đều chứa AES và SHA-256 mà vẫn không có mục tương thích, vì độ dài khóa, PRF hoặc nhóm DH khác nhau. Việc so sánh diễn ra theo từng đề xuất, không theo từng thuật toán.

Khi không có gì khớp, bên trả lời gửi NO_PROPOSAL_CHOSEN kèm loại SA đã thất bại. Hãy đọc thông báo đó nhắm tới danh sách đề xuất nào trước khi sửa cấu hình; đổi thuật toán ESP khi đề xuất IKE bị từ chối chỉ làm mất một vòng gỡ lỗi.

Nên biết hành vi lựa chọn khi bạn tinh chỉnh một hồ sơ. Một số cách hiện thực ưu tiên thứ tự của bên khởi tạo, số khác sắp xếp lại theo chính sách cục bộ, vì thế một bộ chạy được giữa hai nhà cung cấp có thể biến mất khi bạn đảo phía khởi tạo kết nối.

AEAD loại bỏ một trường thay vì thêm vào

AES-GCM và ChaCha20-Poly1305 xác thực và mã hóa trong một phép toán. Khi một trong hai được chọn cho ESP, thuật toán toàn vẹn không được thương lượng riêng, vì cấu trúc AEAD đã bao trùm nó. Vì thế một đề xuất ghép AES-GCM với SHA-256 là dư thừa trong trường hợp tốt nhất và bị từ chối trong trường hợp xấu nhất.

PRF vẫn tách riêng ở phía IKE, vì nó dẫn xuất khóa cho kênh điều khiển chứ không bảo vệ tải trọng. Đó là lý do một đề xuất IKE có thể hợp lệ kết hợp một mã AEAD với PRF và một nhóm DH, trong khi đề xuất ESP tương ứng chỉ liệt kê mã AEAD và nhóm PFS tùy chọn.

Độ dài khóa là một phần của token mã hóa, nên AES-128-GCM và AES-256-GCM là hai chào hàng khác nhau. Một hồ sơ sao chép từ hướng dẫn giả định khóa 256-bit sẽ không khớp với một điểm cuối được cấu hình cho 128-bit, dù cả hai dòng đều ghi AES-GCM. Hai bên có thể đồng ý về họ mã hóa và vẫn từ chối nhau vì con số sau dấu gạch nối.

Hãy đọc SA đã cài đặt, không phải cấu hình

Danh sách đề xuất đã cấu hình là một lời chào hàng; SA đã cài đặt mới là kết quả. Trên strongSwan và nhân Linux, cả hai góc nhìn đều có sẵn:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas in ra các thuật toán đã thương lượng cho từng SA, kể cả việc CHILD có dùng AEAD hay không. ip xfrm state cho thấy nhân thực sự đã cài đặt gì, và đó là nơi xác nhận rằng một lần làm mới khóa không rơi về một bộ khác với bộ bạn đã ghi lại.

Hãy lưu đầu ra đó bên cạnh cấu hình sau khi sửa. Khi một bản cập nhật máy khách thay đổi giá trị mặc định, bộ đã ghi cho bạn một đường cơ sở để so sánh, và việc so sánh chỉ ra trường đã dịch chuyển thay vì bắt đầu lại cuộc điều tra từ đầu.