FortiGate Azure tái tạo khóa: đề xuất peer SA không khớp với chính sách cục bộ
Một đường hầm IKEv2 đang hoạt động vẫn có thể từ chối CHILD SA thay thế. Hãy so sánh đề xuất mà lần gia hạn thực sự thương lượng, không phải đề xuất mà ping đầu tiên đã dùng.
Đường hầm dựng lên, lưu lượng chảy, và sau đó nhật ký ghi peer SA proposal not match local policy. Hầu hết mọi người đọc dòng đó như bằng chứng rằng hai cấu hình chưa bao giờ khớp nhau. Thường thì nó có nghĩa hẹp hơn: chúng khớp cho CHILD SA đầu tiên và ngừng khớp ở lần gia hạn đầu tiên, bởi vì hiệp hội đầu tiên chưa bao giờ cần đến trao đổi mà các hiệp hội sau thực hiện. Chính sự khác biệt đó quyết định nơi bạn cần xem.
CHILD SA đầu tiên kế thừa, các lần sau thương lượng
Trong IKEv2, CHILD SA ban đầu được tạo trong IKE_AUTH và khóa của nó được dẫn xuất từ vật liệu khóa của IKE SA. Tại thời điểm đó không có trao đổi Diffie-Hellman riêng, nên một nhóm PFS mà một peer không thể chấp nhận đơn giản là chưa được thử. Đường hầm trông khỏe mạnh vì yêu cầu mà sau này bạn sẽ thất bại chưa bao giờ được kiểm tra.
Tái tạo khóa CHILD_SA là một chuỗi thông điệp khác. Khi PFS được cấu hình, các peer thực hiện trao đổi khóa mới và phải đồng ý về một nhóm mà cả hai bên chấp nhận, cùng với đề xuất ESP cho hiệp hội mới. Đó là thời điểm sự không khớp trở nên hữu hình, và đó là lý do lỗi nêu tên một đề xuất chứ không phải một tuyến.
Vậy “hôm qua nó chạy được” không cho bạn biết gì về đề xuất. Nó cho biết trao đổi ban đầu đã thành công, điều bạn đã biết.
Đọc trao đổi thất bại, không phải ping đầu tiên
Trước khi thay đổi bất cứ điều gì, hãy thu thập từ cả hai đầu xác thực IKE thành công, CHILD SA ban đầu và bản thay thế thất bại. Sau đó gọi tên thao tác cho chính xác: tái tạo khóa IKE SA, xác thực lại IKE và tái tạo khóa CHILD SA là ba sự kiện khác nhau, và “giai đoạn 2” bao trùm tất cả trong lời nói thông thường.
So sánh các trường dưới đây cho kết nối đã thất bại, không phải cho đường hầm nói chung.
| Lớp | Giá trị cần so sánh |
|---|---|
| IKE | Phiên bản, mã hóa và toàn vẹn hoặc bố trí PRF, nhóm DH |
| IPsec / CHILD | Mã hóa và toàn vẹn ESP, nhóm PFS hoặc trao đổi khóa dự kiến |
| Lưu lượng được bảo vệ | Bộ chọn cục bộ và từ xa, cùng mọi thiết lập bộ chọn dựa trên chính sách |
Trên FortiGate, mở đề xuất giai đoạn-2, thiết lập PFS và các nhóm DH được chấp nhận cho đường hầm đó. Đọc các giá trị đã nạp thay vì suy ra từ một kết nối đã thiết lập trước đó. Ảnh chụp trang GUI là bằng chứng yếu hơn cấu hình đang chạy, vì hai thứ có thể khác nhau sau khi nâng cấp. Xuất phần bạn đã sửa và lưu nó cùng phiếu.
Chính sách mặc định của Azure vẫn là một chính sách
Việc không có chính sách tùy chỉnh nào gắn vào kết nối không có nghĩa Azure không áp dụng chính sách nào. Kết nối quay về bộ đề xuất mặc định của cổng, bộ này có thể rộng hơn hoặc hẹp hơn những gì FortiGate của bạn cung cấp. Nếu hai bộ trùng nhau cho IKE nhưng không trùng cho ESP với PFS, bạn sẽ nhận đúng kiểu thất bại này.
Chế độ chỉ đọc này hiển thị chính sách thực sự được gắn, mà không tiết lộ bí mật:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesHãy dùng tên tài nguyên thật của bạn. Khi cần một chính sách rõ ràng, hãy đặt nó trên tài nguyên kết nối. Đó không phải công tắc toàn cổng, và nó không âm thầm áp dụng cho các đường hầm khác trên cùng cổng.
Trong cổng thông tin, trang Configuration của kết nối đó là nơi đặt chính sách IPsec/IKE tùy chỉnh. Hướng dẫn của Microsoft về chính sách tùy chỉnh liệt kê các tham số được hỗ trợ và yêu cầu SKU. Azure nhận một tổ hợp đầy đủ cho mỗi kết nối, nên bạn chỉ định các trường IKE và các trường IPsec cùng nhau, không phải từng cái một.
PFS là một yêu cầu, không phải công tắc để gạt
Nếu đường cơ sở bảo mật của bạn yêu cầu PFS, giải pháp là một nhóm mà cả hai peer chấp nhận ở cả hai phía, được biểu đạt qua một chính sách khớp. Tắt PFS để lỗi biến mất sẽ thay đổi thuộc tính bảo mật mà bạn đang cố giữ, và nó thường xuất hiện lại sau đó như một sự không khớp khác.
Một cái bẫy riêng của Azure: khi bạn chọn GCM cho ESP, các lựa chọn mã hóa và toàn vẹn phải nêu cùng một thuật toán GCM và cùng một độ dài khóa. Trộn một mật mã GCM với một thuật toán toàn vẹn riêng tạo ra tổ hợp mà dịch vụ từ chối, và điều đó trông như không khớp giữa các peer cho đến khi bạn đọc kỹ chính sách.
Chọn tổ hợp mạnh nhất mà cả hai đầu hỗ trợ và yêu cầu của bạn cho phép, rồi ghi nó vào hồ sơ thay đổi. Người tiếp theo sẽ so với hồ sơ đó, không phải với ký ức về một đường hầm từng chạy. Đưa nhóm PFS và đề xuất ESP vào đó, không chỉ tên chính sách. Khi ai đó hỏi sau này tại sao một cuộc kiểm toán thất bại hoặc tại sao việc tái tạo khóa chậm, dòng đó trả lời cả hai câu hỏi.
Xác minh trao đổi đã thất bại
Lên kế hoạch thay đổi kèm đường khôi phục, vì việc sửa chính sách có thể làm gián đoạn đường hầm bạn đang cố sửa. Sau khi lưu lượng trở lại, hãy chờ hoặc kích hoạt gia hạn CHILD_SA và xác nhận hiệp hội mới được thiết lập với nhóm PFS dự kiến. Sau đó xác nhận lưu lượng ứng dụng tiếp tục đi qua nó.
Hai manh mối sai đáng được nêu tên. Thời hạn sống của SA là các đặc tả cục bộ, nên các giá trị không bằng nhau là bình thường và thay đổi chúng chỉ dịch chuyển thời điểm vấn đề xuất hiện. DPD phát hiện một peer còn sống hay không; nâng thời gian chờ của nó không làm khớp các lựa chọn ESP hay PFS.
Ghi lại kết quả đã thương lượng và sự kiện tiếp theo sau thay đổi. Nếu kết nối giờ thất bại trước khi xác thực IKE hoàn tất, bạn đang xem các thiết lập IKE vừa sửa, không phải lỗi gia hạn CHILD ban đầu.