Cách xây dựng chính sách chuyển đổi dự phòng VPN trên router mà không rò rỉ
Quyết định xem lưu lượng nên làm gì khi đường hầm ưu tiên sập: đường hầm dự phòng, WAN thường hay chặn. Sau đó xây dựng và kiểm tra trên router.
Cơ chế chuyển đổi dự phòng hoạt động đúng như đã cấu hình, và đó chính là vấn đề. Khi đường hầm chính sập, router chuyển tuyến mặc định sang modem cáp, laptop vẫn lướt web và không ai gọi điện. Hai ngày sau có người nhận ra thư mục tài chính đã có thể truy cập qua đường internet mở suốt sáu giờ. Chính sách chuyển đổi dự phòng VPN trên router không phải là một mẹo định tuyến; đó là quyết định về việc lưu lượng nên làm gì khi đường đi ưu tiên biến mất, và quyết định đó phải tồn tại trước khi đường đi biến mất.
Quyết định kết quả trước khi chọn bộ phát hiện
Thường có ba kết quả trên bàn: đưa các máy khách bị ảnh hưởng qua đường hầm dự phòng, để chúng dùng WAN thường hoặc chặn hoàn toàn. Ghi ra kết quả nào áp dụng cho VLAN, SSID hoặc loại thiết bị nào. Một quy tắc phẳng «chuyển sang WAN» chính là cách thư mục tài chính ở trên rơi vào đường công khai.
Ba lựa chọn này không thay thế cho nhau. Quay về WAN giữ cho bộ phận hỗ trợ trả lời điện thoại nhưng lại để lộ tên nội bộ cho bộ phân giải cục bộ. Đường hầm dự phòng giữ nguyên chính sách nhưng có thể hạ cánh ở địa chỉ đầu ra mà phía xa không chấp nhận. Chặn là đúng cho VLAN lương bổng và sai cho mạng khách chưa bao giờ dùng đường hầm.
| Outcome | Right for | What breaks |
|---|---|---|
| Backup tunnel | Policy must hold, remote access required | New exit address, return route, slower rekey |
| Plain WAN | Guest or public-only traffic | Internal names, DNS and IPv6 exposure |
| Block | Payroll, admin, anything VPN-only | Users lose all access and call you |
Ghép bộ phát hiện với sự cố mà bạn thực sự lo sợ
Trạng thái bắt tay, trạng thái giao diện và chuyển tiếp khả dụng là ba tín hiệu khác nhau, và người dùng chỉ quan tâm tín hiệu cuối. Một peer WireGuard có thể hiển thị lần bắt tay gần đây trong khi mạng thượng nguồn của nhà cung cấp đang thả gói. Một máy khách OpenVPN có thể nằm ở trạng thái «đã kết nối» sau khi tuyến mà nó đẩy xuống không còn phân giải được.
Trên pfSense, cách bố trí thực dụng là một nhóm cổng do dpinger cấp dữ liệu, thăm dò một địa chỉ giám sát và đánh dấu cổng là hỏng khi mất gói hoặc độ trễ vượt ngưỡng. Hướng bộ giám sát đó ra ngoài đường hầm, ví dụ một máy chủ trong LAN xa hoặc một địa chỉ công khai bạn tới được qua đường hầm. Nhắm nó vào chính địa chỉ peer của đường hầm chỉ đo phần mà bạn đã biết là còn sống.
Xây dựng nhóm để phương án dự phòng vẫn là lựa chọn cuối
Dùng các tầng thay vì một danh sách thành viên phẳng. Chính ở tầng 1, đường hầm dự phòng ở tầng 2, WAN ở tầng 3 chỉ cho những VLAN mà chính sách cho phép. Trên pfSense điều này nằm trong System > Routing > Gateway Groups: thêm cả hai cổng, gán tầng khác nhau, đặt Trigger Level thành thành viên hỏng cộng mất gói, lưu lại, rồi áp dụng nhóm làm mặc định của giao diện hoặc trong trường Gateway của các quy tắc tường lửa cần đến nó.
Với một phiên bản máy khách OpenVPN trên pfSense 2.5 trở lên, thiết lập Default Gateway của phiên bản quyết định đường hầm có thay thế tuyến mặc định của hệ thống hay không. Định tuyến theo quy tắc chỉ hoạt động như bạn mong đợi khi tuyến bạn giả định thực sự được cài đặt. Sau khi thay đổi, hãy kiểm tra Status > Gateways thay vì tin vào biểu tượng trạng thái đường hầm.
Hai thiết lập gây ra phần lớn việc nhấp nháy. Một là khoảng thăm dò ngắn hơn thời gian hội tụ lại của chính nhà cung cấp. Hai là nhóm mà chính và dự phòng dùng chung một tầng, nên cả hai luôn đủ điều kiện. Thêm độ trễ trễ qua các ngưỡng mất gói và độ trễ trước khi người dùng tự cảm nhận các lần chuyển.
Đóng những đường mà đường hầm chưa bao giờ sở hữu
Đầu tiên là rò rỉ DNS. Bộ phân giải vẫn trả lời trên WAN và chuyển tiếp ra ngoài đó, nên tên vẫn được phân giải qua ISP trong khi lưu lượng bị ghim vào đường hầm. Giới hạn các giao diện đi ra của bộ phân giải, đẩy bộ phân giải nội bộ tới máy khách và chặn cổng 53 cho mọi thứ khác trên các VLAN chỉ dùng VPN.
IPv6 cần quyết định riêng. Một LAN hai ngăn xếp có thể mất đường hầm mà vẫn giữ tuyến mặc định IPv6 toàn cầu đang hoạt động, nên trình duyệt ưu tiên IPv6 và đi ra qua WAN trong khi IPv4 trông như được kiểm soát hoàn hảo. Hoặc định tuyến IPv6 vào đường hầm, hoặc ngừng quảng bá tiền tố toàn cầu khi đường hầm sập. Nửa chính sách còn tệ hơn không có, vì nó trông như đang hoạt động.
Tiếp theo là đường quay về. Nếu đầu ra dự phòng dùng địa chỉ nguồn khác, phía xa phải biết cách gửi lưu lượng trở lại đó, và mọi trạng thái gắn với địa chỉ cũ đều đã chết. Các phiên mở khi đường hầm chính sập không di chuyển; chúng đứng yên cho đến khi hết thời gian chờ và ứng dụng quyết định làm gì.
Kiểm tra sự cố sập, nhấp nháy và đường quay vào
Rút đường hầm chính khi lưu lượng vô hại đang chạy, rồi đọc bốn thứ: Status > Gateways cho trạng thái các thành viên nhóm, pfctl -ss cho các trạng thái vẫn ghim vào cổng cũ, traceroute từ một máy khách cho đường ra và một truy vấn bộ phân giải để xem máy chủ nào đã trả lời.
Giờ hãy làm nó nhấp nháy. Bật chính lên ba mươi giây, tắt ba mươi giây, hai lần. Nếu lưu lượng chạy theo mọi lần chuyển, các ngưỡng quá chặt hoặc các tầng sai. Hãy sửa theo lịch của bạn, vì nếu không một nhà cung cấp sẽ làm theo lịch của họ.
Cuối cùng, xác nhận bạn vẫn quản trị được router. Giữ một đường ngoài băng như cáp console, VLAN quản trị hoặc modem di động. Một bài kiểm tra chuyển đổi dự phòng khóa bạn ở ngoài là bài kiểm tra bạn không thể hoàn thành, và một router không thể với tới thì không thể tự quay lại.
Trước khi tuyên bố chính sách hoàn tất, bạn phải trả lời được bốn câu hỏi mà không mở terminal: VLAN nào được dùng WAN khi đường hầm sập, bộ phát hiện theo dõi gì và chờ bao lâu, máy chủ tên và tuyến IPv6 nào di chuyển theo đường đi, và bạn quay vào bằng cách nào nếu dự phòng cũng hỏng. Nếu bất kỳ câu trả lời nào là «cái gì mặc định thì giữ», chính sách vẫn thuộc về router chứ không phải bạn.