OpenVPN en arrencar a Ubuntu: NetworkManager o systemd?

La majoria de guies presenten l’elecció com una cosa cosmètica: o deixeu que el NetworkManager aixequi el túnel, o activeu una instància de systemd i ja està. Els dos camins difereixen en una cosa que decideix el resultat en una màquina sense pantalla, i no té res a veure amb quina eina és més nova. El NetworkManager desbloqueja secrets mitjançant una sessió; una instància de systemd no té cap sessió per desbloquejar. Trieu la que el seu tractament dels secrets encaixi amb la màquina que teniu davant.

Tota la resta, des de la instal·lació de rutes fins al comportament de reconnexió, es deriva d’aquella primera decisió.

L’anell de claus és la diferència que ningú esmenta

Quan el NetworkManager posseeix un perfil de VPN, la contrasenya pot viure a l’anell de claus d’inici de sessió, que es desbloqueja quan un usuari inicia sessió. Això funciona bé en un portàtil: la persona hi és, l’anell s’obre, el túnel puja. En un servidor que arrenca sense supervisió no hi ha ningú per desbloquejar res, així que el perfil espera un secret que no arriba mai. La connexió sembla configurada i no s’activa mai.

La instància de systemd evita aquest problema llegint un fitxer de credencials del disc, cosa que fa del fitxer allò que protegiu. chmod 400 més la propietat de root és el mínim, i el fitxer hauria de quedar fora de les còpies de seguretat i de les plantilles d’imatge que no controleu.

Adjuntar la VPN a una connexió no garanteix l’arrencada

A nm-connection-editor, seleccioneu la connexió per cable o sense fil en lloc de la VPN, obriu la pestanya General, marqueu l’opció de connectar-vos automàticament a una VPN i poseu nom al perfil. Llavors el NetworkManager activa la VPN com a connexió secundària quan la primària arriba a l’estat connectat. Això és una dependència, no una regla de tallafoc. Els paquets encara poden sortir durant els segons previs que el túnel estigui aixecat, i un secret desat que no es desbloqueja deixa la màquina en línia sense el túnel.

Si el requisit és que res no surti sense el túnel, digueu-ho i construïu un interruptor d’emergència, perquè aquest paràmetre no us en donarà cap. Proveu també la suspensió i la represa, perquè la connexió secundària es torna a avaluar en el camí de tornada.

La instància de systemd necessita un nom de fitxer que coincideixi

Deixeu el perfil al directori de client que espera el paquet, com ara /etc/openvpn/client/office.conf, i referencieu-hi el fitxer de credencials amb auth-user-pass office.cred. El nom de la instància és el nom del fitxer sense el sufix, així que openvpn-client@office llegeix office.conf. Activeu-la amb sudo systemctl enable --now openvpn-client@office i confirmeu la correspondència amb systemctl cat openvpn-client@office en lloc de confiar en un exemple d’un blog.

Les rutes dins del perfil es resolen respecte del directori de treball de la unitat, no del perfil mateix, així que una línia relativa ca o auth-user-pass pot fallar en arrencar mentre funciona quan la proveu a mà. Feu servir rutes absolutes per a tot el que la unitat hagi de trobar. Després llegiu journalctl -u openvpn-client@office -b després d’una arrencada real; una unitat que informa d’activa sense túnel normalment anomena un fitxer que falta en aquest registre.

Els paquets més antics porten un nom de plantilla diferent, així que systemctl list-unit-files 'openvpn*' decideix quin existeix en aquest equip.

El comportament de reconnexió és una decisió a part

Un perfil amb ping-restart reconstrueix el túnel després que caigui, i una unitat amb una directiva de reinici fa una cosa similar a nivell de servei. Són polítiques que trieu, no valors per defecte que hereteu. Si la connexió només ha de pujar a demanda, traieu deliberadament el comportament de reinici i escriviu per què. Si la unitat s’inicia abans que la xarxa sigui utilitzable, necessita una política de reintents, perquè un intent fallit en arrencar no es repeteix sol.

Aturar és igual de literal: sudo systemctl disable --now openvpn-client@office atura la instància en marxa i elimina l’enllaç d’arrencada. Desactivar-ho sol deixa el túnel funcionant fins al proper reinici, cosa que sorprèn qualsevol que provi desactivant i mirant com la interfície continua aixecada.

Reinicieu, i després comproveu quatre coses per ordre

Reiniciar el servei prova el servei; reiniciar la màquina prova el camí d’arrencada. Després del reinici, confirmeu que la unitat ha pujat, després que hi ha una ruta per a la subxarxa remota, després quina adreça presenta la màquina a internet, i finalment que els noms es resolen a través del túnel. Aquestes quatre comprovacions fallen en aquest ordre quan alguna cosa va malament, cosa que fa que el primer fallo sigui el útil.

Una unitat activa sense ruta normalment vol dir que el perfil s’ha connectat però el servidor no ha empès cap ruta, o que la ruta es va instal·lar en una interfície que després va desaparèixer. Una ruta sense cerca de noms funcional apunta a la configuració de DNS, no al túnel mateix.

Decidiu per endavant què ha de passar quan el túnel no pot pujar. Tornar a la connectivitat simple és una política, i s’ha d’escriure en lloc de deixar-la al gestor que hagi arrencat primer.