Xoay vòng PSK của AWS VPN: đường hầm nào sập, và khi nào

Đường hầm sập ngay khi hai đầu không thống nhất về khóa chia sẻ trước, và nó vẫn sập cho đến khi cả hai phía mang giá trị mới. Phần đó là điều đã lường trước: AWS coi thay đổi này là một gián đoạn của đường hầm được chọn, và đầu đối tác sẽ không hoàn tất IKE khi các khóa còn khác nhau. Điều khiến người ta ngạc nhiên là nửa sau. Đường hầm còn lại không tự tiếp nhận lưu lượng trừ khi bạn đã kiểm tra rằng nó chịu được. Xoay theo thứ tự này và gián đoạn vẫn nằm trong một đường hầm.

Điều gì thực sự xảy ra khi khóa thay đổi

ModifyVpnTunnelOptions ghi lại các tùy chọn cho một đường hầm, được nhận diện bằng địa chỉ IP bên ngoài của nó. Đường hầm bị hạ và dựng lại, nên IKE và IPsec thương lượng lại từ đầu với khóa mới. AWS cho biết gián đoạn có thể kéo dài vài phút, đủ lâu để một giao thức định tuyến nhận ra. Đường hầm còn lại trong cùng kết nối không bị ảnh hưởng bởi lệnh gọi này.

Có một tác động thứ hai đáng biết trước khi gửi bất cứ thứ gì. Thao tác sửa đổi lấy toàn bộ tập tùy chọn của đường hầm, nên một trường bạn bỏ qua sẽ được ghi lại với giá trị mặc định của nó. Nếu bạn đã tinh chỉnh thời gian sống của pha 1 hoặc pha 2, hoặc cài đặt phát hiện đối tác chết, hãy truyền các giá trị hiện tại trong cùng yêu cầu hoặc dự định khôi phục chúng sau đó.

Đọc các giá trị hiện tại trước, rồi đổi một trường duy nhất. Trình tự đó là toàn bộ kỷ luật của việc này.

Khớp đường hầm AWS với đúng đối tác trước

Bảng điều khiển gắn nhãn các đường hầm theo thứ tự, và thiết bị của bạn không dùng nhãn đó. Nhận diện đường hầm bằng địa chỉ IP bên ngoài và khớp với phần đối tác trên cổng khách hàng. Đường hầm 1 trong cấu hình cục bộ không phải bằng chứng rằng bạn đang sửa đường hầm mà AWS gọi là đường hầm 1.

Hãy bắt đầu từ chính kết nối, nơi liệt kê cả hai đường hầm và khóa mà mỗi đường đang giữ:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

Khóa trả về là khóa đang được dùng hiện tại. Hãy so với cấu hình của đối tác trước khi đổi bất cứ thứ gì, vì sự không khớp đã tồn tại giải thích cho một đường hầm chưa bao giờ ổn định.

Trước tiên hãy để đường hầm kia chịu lưu lượng

Hai đường hầm trong một kết nối không chứng minh rằng thiết bị của bạn đã cấu hình cả hai, rằng cả hai quảng bá các tiền tố bạn cần, hay rằng lưu lượng đi giữa chúng. Hãy kiểm tra thương lượng của đường hầm dự phòng, các tuyến của nó và một luồng ứng dụng thật theo cả hai chiều. Với BGP, quan hệ lân cận còn sống là bằng chứng hữu ích nhưng không giống với việc xác nhận các tiền tố. Với định tuyến tĩnh, hãy xác nhận cách cổng chọn đường và điều nó làm khi đường ưu tiên biến mất.

Nếu đường dự phòng không chịu được khối lượng công việc, hãy lên lịch gián đoạn hoặc sửa đường hầm dự phòng trước khi chạm vào khóa. Đèn trạng thái trên một trang bảng điều khiển không phải lời hứa về dịch vụ không gián đoạn.

Xoay một đường hầm, rồi xác minh bằng lưu lượng thật

Khi đường dự phòng đã được chứng minh, trình tự rất ngắn. Ghi lại địa chỉ đường hầm, đối tác của nó và các cài đặt không bí mật, và giữ một đường quản trị tới cổng không phụ thuộc vào đường hầm bạn sắp cắt.

1. Cập nhật đối tác của cổng khách hàng cho địa chỉ bên ngoài đã chọn, hoặc chuẩn bị thay đổi để nó có hiệu lực vài giây sau lệnh gọi API.
2. Gửi lệnh gọi sửa đổi với khóa mới cùng thời gian sống và giá trị DPD hiện tại.
3. Chờ IKE và IPsec trở lại, rồi xác nhận các tuyến và các tiền tố cần thiết.
4. Cho một luồng ứng dụng đại diện đi qua đường hầm đó và theo dõi cả hai chiều.

Đường hầm không dùng được khi hai đầu chưa thống nhất và khi AWS đang áp dụng thay đổi, nên cập nhật đối tác phải theo ngay chứ không phải sau bữa trưa. Chỉ khi đường hầm đã đổi chịu lưu lượng thật thì bạn mới nên lặp lại quy trình trên đường còn lại.

Dừng lại nếu việc khôi phục hoặc định tuyến vẫn chưa chắc chắn sau đường hầm đầu tiên. Hai đường hầm nửa hoạt động tệ hơn một đường mà bạn biết là chạy được.

Khi việc khôi phục bị kẹt, hãy đọc phía IKE

Một đường hầm vẫn sập sau khi cả hai đầu giữ khóa mới thường là sự không khớp chính sách mà việc xoay vòng đã phơi ra chứ không tạo ra. Các đề xuất, danh tính mà đối tác gửi và các bộ chọn lưu lượng đều phải khớp với phía AWS, và một giá trị đã sống sót qua đường hầm đã thiết lập vẫn có thể bị từ chối trong một lần thương lượng mới. Hãy đọc trạng thái thương lượng và thông điệp kèm theo trước khi đổi khóa lần thứ hai.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Nếu phải hoàn tác thay đổi, đừng khôi phục khóa cũ chỉ vì nó từng chạy được. Hãy coi khóa đã bị xâm phạm là đã bị xâm phạm và sửa lại việc thương lượng thay vào đó. Kết thúc với cả hai đường hầm được xác minh và bản kiểm kê bí mật được cập nhật để mỗi đối tác ghi lại giá trị mình giữ, và giữ tài liệu về các tùy chọn đường hầm của AWS bên cạnh runbook.