Từ strongSwan đến AWS Site-to-Site: vì sao Child SA không chọn gì cả

Bảng điều khiển hiển thị up, strongSwan báo cáo một hiệp hội IKE đã thiết lập, mà gói tin vẫn không đến. Thứ tiếp theo cần so sánh không phải khóa chia sẻ trước, mà là cặp tiền tố mà mỗi bên tin rằng đường hầm đang bảo vệ. Hãy lần lượt thực hiện các kiểm tra bên dưới, vì hai mục đầu quyết định đường hầm có thể chở lưu lượng của bạn hay không.

Dịch tên của AWS sang thuật ngữ của strongSwan

AWS mô tả kết nối từ phía khách hàng: địa chỉ cổng khách hàng và CIDR cục bộ thuộc về bạn, còn CIDR từ xa thuộc về VPC. strongSwan gọi hai đầu là left và right, tiền tố của bạn nằm trong leftsubnet và tiền tố của VPC nằm trong rightsubnet. Đảo một cặp sẽ tạo ra đường hầm thương lượng và chọn sai lưu lượng.

Tải xuống cấu hình mà AWS tạo cho kết nối và coi đó là tham chiếu cho chính kết nối ấy, bao gồm địa chỉ và tiền tố đường hầm. Nếu để cả hai trường CIDR trống khi tạo, dịch vụ dùng giá trị mặc định 0.0.0.0/0 ở mỗi bên. Bộ định tuyến được cấu hình với tiền tố hẹp sẽ không bao giờ khớp, nên hãy điền các trường hoặc cố ý mở rộng bộ chọn.

Sự không khớp ở đây trông như lỗi định tuyến nhưng không phải.

Ghim địa chỉ mà AWS thực sự nhìn thấy

Một bộ định tuyến sau NAT có thể gửi IKE từ giao diện mà bên kia chưa từng biết. Địa chỉ cổng được ghi trong AWS phải là địa chỉ mà AWS quan sát trên mạng, và bộ định tuyến phải được ghim vào cùng địa chỉ cục bộ thay vì đi theo tuyến mặc định.

conn %default
    local_addrs = 203.0.113.10

Trong strongSwan, local_addrs chọn địa chỉ nguồn cho IKE, và các cấu hình OpenSwan cũ ghi ý tưởng tương tự là left. Hãy trỏ nó vào giao diện có địa chỉ công cộng, sau đó kiểm tra trên chính thiết bị NAT rằng UDP 500 và 4500 đến được máy chủ đó, vì một quy tắc còn sót từ bộ định tuyến trước sẽ âm thầm loại bỏ chúng. Một cặp bộ chọn đúng nhưng địa chỉ nguồn sai vẫn thất bại, và nhật ký sẽ đổ lỗi cho đề xuất. Chính sự đánh lạc hướng đó là lý do địa chỉ nguồn đáng được kiểm tra riêng.

Hãy xác nhận quy tắc chuyển tiếp thay vì giả định, vì quy tắc từng đúng cho bộ định tuyến trước thường còn sót lại.

Xử lý pha 1 và pha 2 riêng biệt

AWS hiển thị tùy chọn IKE và ESP thành hai danh sách riêng. Bộ IKE mà hai bên chấp nhận không nói gì về đề xuất ESP, vì hai danh sách độc lập. Hãy đọc cả hai từ cấu hình đã tạo và so sánh từng mục một.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Cú pháp không di chuyển giữa các cách triển khai. Một cặp chạy được trong OpenSwan, chẳng hạn phase2alg=aes_gcm với ike=aes256-sha1;modp1024, cần được dịch sang dạng esp= và ike= của strongSwan, và tên thuật toán cũng khác. Vì GCM xác thực trong khi mã hóa, nó không cần một phép biến đổi toàn vẹn riêng, khác với bộ CBC ghép với SHA. Một dòng pha 2 dán từ daemon này sang daemon khác mà không dịch sẽ tạo ra lời từ chối đọc như sự không khớp của bộ chọn.

Kiểm tra hiệp hội con, không phải chỉ báo đường hầm

Nếu kết nối tải lên nhưng không có hiệp hội con nào xuất hiện, thì đề xuất hoặc bộ chọn đã bị từ chối. Nếu có hiệp hội con và bộ chọn của nó loại trừ tiền tố của bạn, gói tin bị lọc trước khi đến đường hầm. Chỉ báo của bảng điều khiển chỉ bao quát mức IKE, nên không thể cho biết điều nào trong hai đã xảy ra.

ipsec statusall

Tìm hiệp hội an ninh con và đọc các bộ chọn lưu lượng in bên cạnh, sau đó so sánh với tiền tố từ cấu hình đã tạo.

Thử từ một máy chủ trong tiền tố cục bộ đến một máy chủ trong tiền tố VPC, và kiểm tra đường trở về cùng mọi nhóm bảo mật hoặc ACL mạng ở phía AWS. Bộ chọn đúng không bảo vệ gói tin khỏi bị loại bỏ sau đó.

Khi vẫn thất bại sau khi bộ chọn khớp

Xác nhận tuyến ở cả hai bên trỏ tới đường hầm, sau đó xác nhận thiết bị NAT không viết lại lưu lượng theo cách chính sách không mong đợi. Đường hầm dựa trên chính sách khớp địa chỉ gói tin, nên một bản dịch áp dụng sau quyết định chính sách sẽ thay đổi kết quả.

Ghi nhật ký một gói vào và một gói ra ở mỗi bên trước khi thay đổi đề xuất khác.

Ghi vào phiếu các bộ chọn, đề xuất pha 1 và pha 2 cùng địa chỉ nguồn. Bốn giá trị này giải thích phần lớn lỗi site-to-site mà không cần gọi điện.