Executa as tarefas posteriores á VPN desde o despachador, non desde if-up

Un script que debe executarse despois de que a VPN suba necesita un evento do compoñente que posúe a conexión. Un ficheiro deixado nun directorio antigo de ganchos de rede non é unha chamada de retorno para cada VPN que NetworkManager, pppd ou un proceso OpenVPN independente poidan crear. Cada un deses propietarios informa dun evento distinto cunha contorna distinta, así que hai que identificar o propietario antes de escoller o gancho. Se non, o script é correcto e simplemente nunca se executa.

Para unha VPN xestionada por NetworkManager, o despachador é o lugar correcto, e vpn-up é a acción correcta.

Usa vpn-up, non o evento da interface

O despachador distingue up de vpn-up. O primeiro informa dunha interface activada; o segundo informa dunha conexión VPN activada. Que o Wi-Fi suba só significa que o enlace subxacente existe; o túnel pode seguir negociando, ou pode non autenticarse nunca.

O script recibe a interface e a acción, mentres que os detalles da conexión chegan pola contorna, incluídos o UUID do perfil e a interface IP da VPN. Le esas variables en lugar de inferir a identidade a partir dos nomes dos dispositivos.

Limita a coincidencia a unha conexión

Fai coincidir polo UUID da conexión, ou por outra identidade que proporcione o despachador, en lugar dun prefixo tun ou ppp0. Os nomes de interface non son estables, pode existir máis dun túnel á vez, e dous perfís poden levar o mesmo nome visíbel. Facer coincidir un prefixo tun significa que o script acabará disparándose para unha conexión que ninguén quería tocar. Tamén pode dispararse dúas veces para un perfil cando unha reconexión reconstrúe o dispositivo.

Fai a tarefa idempotente. Unha chamada de retorno que engade unha ruta en cada invocación acaba enchendo a táboa de duplicados, e a segunda copia é a que rompe o encamiñamento.

Saber que non demostra a activación

vpn-pre-up execútase antes de que NetworkManager informe de que a VPN está completamente activada, e o xestor espera eses scripts. Usa unha etapa bloqueante só cando a tarefa pertenza de verdade aí, porque unha comprobación lenta atrasa a activación que todos os demais compoñentes esperan ver.

Que existan rutas non demostra que unha aplicación estea escoitando, que un nome privado se resolva ou que exista unha sesión de usuario. Compróbao por separado cun tempo de espera limitado, e informa de que capa fallou en lugar de reintentar toda a cadea.

Respecta o contexto no que se executa o script

Os scripts do despachador execútanse como root, fóra de calquera sesión de usuario. Non supoñas que estean dispoñíbeis a contorna do usuario conectado, a súa sesión gráfica ou un chaveiro desbloqueado. Ninguén debería responder a un contexto de escritorio ausente facendo que cada credencial sexa lexíbel para cada proceso. Mantén o traballo da sesión de usuario nun servizo de usuario ou nun axudante de sesión ao que a chamada de retorno poida sinalar sen suplantar o usuario.

A propiedade e os permisos do script tamén importan. Un ficheiro executado como root que calquera usuario pode substituír é unha vía de escalada de privilexios, e é un achado independente de se a lóxica da VPN é correcta.

Planifica a desconexión que nunca se dispara

NetworkManager documenta que vpn-pre-down non se emite para desconexións forzadas como unha terminación inesperada ou unha perda de conectividade. Por iso, unha limpeza construída só arredor dun pre-down ordenado é incompleta por construción. Calquera estado compartido que o script cambie necesita outro propietario que poida restauralo tras unha caída, e esa ruta de recuperación debe probarse en lugar de supoñerse.

Proba o gancho cunha conexión normal, unha reconexión, unha desconexión intencionada e un cable arrincado. Rexistra o UUID, a acción e a interface que se disparou, sen rexistrar segredos. Ese rexistro é a única proba fiable de que o gancho se executou para a conexión que pretendías, e é o que fai seguro o seguinte cambio.