Ba kiểu chuyển đổi dự phòng OpenVPN trên pfSense, ba cơ chế

„OpenVPN failover“ trên pfSense bao gồm ít nhất ba thiết kế không liên quan đến nhau, và mỗi thiết kế cần một cơ chế khác. Giữ một đường hầm sống qua một liên kết internet dự phòng, kết nối lại với một máy chủ khác và đưa lưu lượng LAN vào một đường hầm đã thiết lập khác không phải là các biến thể của cùng một tính năng. Hãy chọn sự cố mà bạn đang phòng ngừa trước khi dựng một nhóm cổng. Nhóm khắc phục được một trong số đó không làm gì cho hai cái còn lại.

Gọi tên sự cố trước khi dựng nhóm

Hãy viết câu bạn muốn đúng trong lúc có sự cố. „Đường hầm kết nối lại qua WAN dự phòng“ và „chi nhánh vẫn đến được ứng dụng qua đường hầm kia“ là hai câu khác nhau. Chỉ câu đầu nói về vận chuyển.

Sau đó ghép nó với một cơ chế. Mất WAN cục bộ là vấn đề chọn giao diện, một điểm cuối từ xa đã chết là vấn đề danh sách kết nối, và một đường đi không dùng được bên trong đường hầm đã thiết lập là vấn đề định tuyến và chính sách.

WAN cục bộ: di chuyển phần vận chuyển

Với một máy khách OpenVPN trên pfSense, cách bố trí đa WAN được hỗ trợ chọn một nhóm cổng phù hợp làm giao diện mà máy khách gắn vào. Đó là thứ cho phép kết nối bên ngoài đi ra qua liên kết dự phòng khi liên kết chính hỏng. Bản thân nó không thay đổi cách lưu lượng bên trong được định tuyến.

Phía máy chủ của cùng thiết kế là riêng biệt. Một máy chủ OpenVPN cần truy cập được qua nhiều địa chỉ công cộng cần một trình lắng nghe và một chính sách đầu vào cho từng mục đó, không chỉ một máy khách biết quay số qua hai liên kết. Một mục công cộng đang chạy không phải bằng chứng rằng mục thứ hai đã được cấu hình.

Một quy tắc định tuyến dựa trên chính sách cho các gói LAN được chuyển tiếp không phải là thiết lập di chuyển một kết nối vận chuyển VPN được tạo cục bộ. Đó là hai lần tra cứu khác nhau, và đổi cái này không đổi cái kia.

Điểm cuối từ xa: một máy chủ khác

Một remote thay thế là tính năng của danh sách kết nối. Máy khách thử mục tiếp theo khi mục hiện tại không trả lời, điều này hữu ích khi một máy chủ cụ thể đã chết chứ không phải khi liên kết lên của bạn chết. Hai sự cố trông giống nhau từ bàn làm việc của người dùng và cần cách khắc phục khác nhau.

Mỗi ứng viên phải là một thứ thay thế thật: xác thực tương thích, chính sách máy khách tương thích và quyền truy cập vào cùng các tài nguyên riêng. Một tên máy chủ thứ hai phân giải đến cùng hạ tầng hỏng không phải là dự phòng. Một máy chủ thiếu tuyến đường cần thiết cũng không, dù bắt tay của nó trông khỏe đến đâu.

Cơ chế này cũng không làm hai đường hầm chuyển tiếp cùng lúc. Nó thay kết nối này bằng kết nối khác, tuần tự, và khoảng trống giữa chúng hiện ra với mọi thứ đang chạy.

Đường đi của hầm: chọn một lối ra khác

Khi hai đường hầm đã dựng và lưu lượng nên dùng cái khỏe hơn, cơ chế là một giao diện VPN được gán với cổng riêng của nó, cộng một quy tắc chính sách rõ ràng gửi đúng lưu lượng đến đó. Một nhóm cổng trên các giao diện được gán đó có thể diễn đạt ưu tiên và giám sát.

Thiết kế đó nói về lựa chọn, không phải về phục hồi. Chuyển các kết nối mới sang đường hầm thứ hai không nói gì về các phiên đã thiết lập trên đường hầm thứ nhất, và không nói gì về việc phía xa có chấp nhận địa chỉ nguồn mới hay không. Coi nó là cơ chế phục hồi chính là cách đặt kỳ vọng quá cao.

Nếu yêu cầu là các phiên hiện có phải sống sót, hãy nói rõ điều đó. Hầu hết các triển khai không di chuyển một luồng đang sống giữa các đường hầm, và thiết kế như thể chúng làm vậy tạo ra một cơ chế chuyển đổi trông đúng trên sơ đồ và trên thực tế làm rơi mọi kết nối đang mở.

Bộ giám sát, NAT và quy tắc fail-closed

Một bộ giám sát nên kiểm tra thứ mà đường hầm phải cung cấp. Một mục tiêu trả lời từ phía đối tác của hầm nhưng không từ mạng ứng dụng phía sau nó sẽ báo khỏe trong khi người dùng không thấy gì. Một mục tiêu chẩn đoán không đến được sẽ báo chết trong khi đường đi vẫn tốt. Hãy chọn địa chỉ một cách có chủ đích và xác nhận rằng nó chỉ đến được qua đúng đường hầm dự định.

Kiểm tra NAT đi ra cho cả hai lối ra. Một phép dịch chạy được trên lối chính không mô tả địa chỉ nguồn của bản dự phòng, và mạng riêng phía xa cần một tuyến về khớp với nguồn bạn trình ra. Một phép dịch đúng trên đường này có thể sai một cách âm thầm trên đường kia.

Sau đó quyết định điều gì xảy ra với lưu lượng không bao giờ được dùng WAN. pfSense có hành vi xác định cho các quy tắc mà cổng được chọn đã chết, và một quy tắc cho phép rộng về sau hoặc một tuyến mặc định có thể vô hiệu ý định của bạn. Hãy viết kết quả bị chặn như một yêu cầu, rồi kiểm chứng bằng cách hạ đường đi xuống.

Hãy kiểm tra mất mát và phục hồi riêng rẽ, với lưu lượng mà bạn được phép tạo ra, và theo dõi ba thứ cùng lúc: WAN mang kết nối bên ngoài, đường hầm mang yêu cầu ứng dụng và đường đi mà phản hồi chọn. Một cặp chỉ báo cổng xanh không phải là một trong ba thứ đó. Hướng dẫn đa WAN của Netgate mô tả việc gắn kết vận chuyển và các lựa chọn máy khách được xuất ra mà điều này dựa vào.