Chạy các tác vụ sau VPN từ dispatcher, không phải từ if-up
Một hook giao diện cũ sẽ không thấy kết nối VPN. Khớp vpn-up với UUID của hồ sơ, giữ tác vụ có thể lặp lại và lên kế hoạch cho một lần ngắt kết nối không bao giờ xảy ra.
Một script phải chạy sau khi VPN khởi lên cần một sự kiện từ thành phần sở hữu kết nối. Một tệp đặt trong thư mục hook mạng cũ không phải là callback cho mọi VPN mà NetworkManager, pppd hoặc một tiến trình OpenVPN độc lập có thể tạo ra. Mỗi chủ sở hữu đó báo một sự kiện khác nhau với môi trường khác nhau, vì vậy phải xác định chủ sở hữu trước khi chọn hook. Nếu không, script đúng mà đơn giản là không bao giờ chạy.
Với VPN do NetworkManager quản lý, dispatcher là đúng chỗ, và vpn-up là đúng hành động.
Dùng vpn-up, không dùng sự kiện giao diện
Dispatcher phân biệt up với vpn-up. Cái đầu báo một giao diện đã kích hoạt; cái sau báo một kết nối VPN đã kích hoạt. Wi-Fi lên chỉ có nghĩa là liên kết bên dưới tồn tại; đường hầm có thể vẫn đang thương lượng, hoặc có thể không bao giờ xác thực.
Script nhận giao diện và hành động, còn chi tiết kết nối đến qua môi trường, bao gồm UUID của hồ sơ và giao diện IP của VPN. Hãy đọc các biến đó thay vì suy ra danh tính từ tên thiết bị.
Giới hạn khớp nối trong một kết nối
Khớp theo UUID của kết nối, hoặc theo danh tính khác mà dispatcher cung cấp, thay vì tiền tố tun hay ppp0. Tên giao diện không ổn định, có thể tồn tại nhiều hơn một đường hầm cùng lúc, và hai hồ sơ có thể mang cùng tên hiển thị. Khớp tiền tố tun nghĩa là script cuối cùng sẽ chạy cho một kết nối mà không ai định chạm vào. Nó cũng có thể chạy hai lần cho một hồ sơ khi việc kết nối lại dựng lại thiết bị.
Làm cho tác vụ có tính idempotent. Một callback thêm tuyến đường ở mỗi lần gọi cuối cùng sẽ làm bảng đầy bản trùng, và chính bản sao thứ hai là thứ phá hỏng việc định tuyến.
Biết điều mà việc kích hoạt không chứng minh
vpn-pre-up chạy trước khi NetworkManager báo VPN đã kích hoạt hoàn toàn, và trình quản lý chờ các script đó. Chỉ dùng giai đoạn chặn khi tác vụ thực sự thuộc về đó, vì một kiểm tra chậm sẽ trì hoãn việc kích hoạt mà mọi thành phần khác đang chờ thấy.
Sự tồn tại của tuyến đường không chứng minh rằng một ứng dụng đang lắng nghe, một tên riêng đang được phân giải, hay có một phiên người dùng. Hãy kiểm tra riêng với thời gian chờ có giới hạn, và báo lớp nào đã hỏng thay vì thử lại toàn bộ chuỗi.
Tôn trọng ngữ cảnh mà script chạy trong đó
Script của dispatcher chạy với quyền root, bên ngoài mọi phiên người dùng. Đừng giả định rằng môi trường của người dùng đã đăng nhập, phiên đồ họa hay chùm khóa đã mở khóa là sẵn có. Không ai nên đáp lại việc thiếu ngữ cảnh máy tính để bàn bằng cách làm cho mọi thông tin đăng nhập đều đọc được bởi mọi tiến trình. Hãy giữ công việc của phiên người dùng trong một dịch vụ người dùng hoặc một trợ lý phiên mà callback có thể gửi tín hiệu mà không mạo danh người dùng.
Quyền sở hữu và quyền truy cập trên script cũng quan trọng. Một tệp được chạy với quyền root mà bất kỳ người dùng nào cũng có thể thay thế là một con đường leo thang đặc quyền, và đó là một phát hiện độc lập với việc logic VPN có đúng hay không.
Lên kế hoạch cho lần ngắt kết nối không bao giờ xảy ra
NetworkManager ghi nhận rằng vpn-pre-down không được phát ra cho các lần ngắt kết nối cưỡng bức như kết thúc bất ngờ hoặc mất kết nối. Vì vậy, việc dọn dẹp chỉ dựa vào một pre-down êm ái là không đầy đủ về mặt cấu trúc. Bất kỳ trạng thái chia sẻ nào mà script thay đổi đều cần một chủ sở hữu khác có thể khôi phục nó sau khi sập, và đường khôi phục đó phải được kiểm tra chứ không phải giả định.
Hãy thử hook với một kết nối bình thường, một lần kết nối lại, một lần ngắt kết nối có chủ đích và một sợi cáp bị rút. Ghi lại UUID, hành động và giao diện đã chạy, không ghi bí mật. Bản ghi đó là bằng chứng đáng tin cậy duy nhất rằng hook đã chạy cho kết nối bạn định, và chính nó làm cho thay đổi tiếp theo an toàn.