Chuyển đổi dự phòng VPN: khi đường về vẫn nằm trên đường hầm cũ

Đường hầm dự phòng khởi động, đường hầm chính sập, và ứng dụng vẫn hết thời gian chờ. Ở cả hai điểm, trạng thái đường hầm trông khỏe mạnh, và đó chính là điều gây khó hiểu. Một chuyển đổi chuyển yêu cầu sang dự phòng nhưng để phản hồi trên đường cũ không phải là chuyển đổi. Hướng dẫn dưới đây kiểm tra đường về, không chỉ bắt tay.

Trước tiên ghi lại tuyến ở cả hai đầu; góc nhìn từ một điểm không thể cho thấy tuyến không đối xứng. Đây cũng là bước thường bị bỏ qua nhất khi chịu áp lực thời gian.

Ghi lại tuyến của cả hai điểm trước khi kiểm tra

Với mỗi tiền tố được bảo vệ, hãy viết tuyến chính, tuyến dự phòng và ưu tiên chọn giữa chúng. Bao gồm cổng LAN phía sau mỗi điểm cuối VPN, vì điểm cuối hiếm khi là chặng cuối.

Các số đo tĩnh, tuyến được theo dõi và định tuyến động thể hiện mức phù hợp theo cách khác nhau. Biết thiết kế của bạn dùng loại nào, và cần gì để phương án thay thế trở nên hoạt động. Viết điều kiện bên cạnh tuyến, ví dụ số đo thấp hơn cho đến khi phép thử thất bại.

Làm điều này ở cả hai điểm. Một dự phòng được ưu tiên ở một bên và bị bỏ qua ở bên kia tạo ra đúng sự bất đối xứng mà bạn đang cố tránh.

Quan sát yêu cầu và phản hồi trong từng giai đoạn

Dùng một ứng dụng được phép và vô hại và quan sát ba giai đoạn: bình thường, sự cố tuyến chính và khôi phục. Trong mỗi giai đoạn, ghi lại đường hầm nào mang yêu cầu và đường hầm nào mang phản hồi. Một địa chỉ ngang hàng truy cập được không chứng minh rằng đường ứng dụng được bảo vệ hoạt động. Ghi lại ở cả hai điểm để thấy luồng một chiều.

Nếu yêu cầu di chuyển mà phản hồi thì không, hãy kiểm tra tuyến của điểm xa đến tiền tố máy khách và ưu tiên của nó cho dự phòng. Đó là quyết định định tuyến, không phải lỗi đường hầm.

Khôi phục điều kiện ban đầu sau khi kiểm tra và xác nhận tuyến chính lại được ưu tiên. Một tuyến chính được khôi phục mà không được ưu tiên là thiết kế chuyển đổi chưa hoàn tất.

Quản lý trạng thái phiên khi cổng thay đổi

Tường lửa và NAT có thể giữ trạng thái kết nối trên một cổng, và việc đổi tuyến sang cổng khác không mang theo trạng thái đó. Một số ứng dụng tự kết nối lại; số khác thất bại cho đến khi phiên được lập lại. Nếu dự phòng thay đổi nguồn công khai hoặc địa chỉ riêng đã dịch, các quy tắc truy cập từ xa cũng có thể phản ứng. Hãy ghi lại mọi lần khởi động lại phiên dự kiến thay vì hứa hẹn chuyển đổi không gián đoạn.

Giữ địa chỉ ổn định ở nơi ứng dụng yêu cầu. Một thiết kế chuyển đổi thay đổi địa chỉ nguồn cho mỗi phiên là một lựa chọn thiết kế, và nó nên được ghi lại. Lựa chọn đó quyết định người dùng thực sự nhận ra bao nhiêu gián đoạn.

Kiểm tra một ứng dụng giữ phiên dài, không chỉ một yêu cầu mới.

Khôi phục tuyến chính và kiểm tra dao động

Xác nhận rằng các quảng bá tuyến hoặc ưu tiên ổn định mà không dao động. Một tuyến chính dao động có thể gây rối hơn một sự cố rõ ràng, vì mỗi lần chuyển đổi đều đặt lại trạng thái.

Giữ quản trị cổng truy cập được qua một đường khôi phục để chính cuộc kiểm tra không khóa bạn ra ngoài. Ghi lại các giai đoạn, các tuyến quan sát được và thời gian khôi phục; bản ghi đó là thứ khiến lần chuyển đổi tiếp theo có thể dự đoán được. Ghi chú của strongSwan về chuyển tiếp hữu ích khi các điểm cuối là máy chủ Linux.