Programar un client VPN: trieu la capa abans de la contrasenya
La CLI del proveïdor, rasdial, una intenció d’aplicació o l’automatització d’interfície fallen cadascun de manera diferent. Trieu la capa, manteniu el secret fora d’argv i espereu l’estat, no els codis de sortida.
Els scripts engeguen clients VPN a la capa que l’autor va triar, i aquesta capa poques vegades és la que la feina necessitava. La línia d’ordres del proveïdor, el marcador del sistema operatiu i una intenció d’aplicació mòbil tornen tots en moments diferents de la vida de la connexió. També tracten el secret de manera diferent, i aquesta diferència decideix si la contrasenya és visible per a cada usuari de la màquina. Trieu la capa abans d’escriure la primera línia de l’script.
Capa 1: la línia d’ordres del proveïdor
La majoria de clients d’escriptori inclouen una línia d’ordres que accepta un nom de perfil i, massa sovint, una contrasenya. L’antic client de Cisco acceptava un verb connect amb arguments d’usuari i contrasenya; macOS exposa el servei integrat mitjançant networksetup; NetworkManager respon a nmcli. Aquestes crides tornen quan l’ordre acaba, cosa que no és el mateix moment en què el túnel esdevé utilitzable. Llegiu la documentació del proveïdor per a la versió que desplegueu, perquè aquestes interfícies canvien i algunes s’eliminen del tot.
nmcli connection up "Work VPN"
networksetup -connectpppoeservice "Work VPN"
L’avantatge és que el proveïdor coneix el seu propi magatzem de perfils, de manera que la crida fa servir la mateixa configuració que faria la GUI. L’inconvenient és que cada proveïdor inventa els seus propis verbs, i un script escrit per a un client no es trasllada a un altre. Considereu aquesta capa com el camí més curt quan el client és fix i la versió està fixada.
Capa 2: el servei propi del sistema operatiu
A Windows el marcador forma part del sistema operatiu i treballa contra una entrada de llibreta de telèfons en lloc del magatzem de perfils del proveïdor. Això el fa més portable entre clients i més fàcil de programar des d’un compte de servei. També vol dir que la connexió pot existir en un lloc i no en l’altre, cosa que confon les persones que miren la llista equivocada.
rasdial "Work VPN" user pass
Get-VpnConnection -Name "Work VPN" | Select-Object ConnectionStatus
Feu servir la superfície de PowerShell quan hàgiu de crear o suprimir l’entrada en lloc de marcar-la. Les capes WMI i cmdlet exposen els mateixos objectes amb noms diferents, i la supressió és una operació separada de la desconnexió. Un script que només marca deixarà entrades obsoletes després d’una migració. Comproveu a quin magatzem escriu la vostra automatització abans de prometre que la neteja es farà.
Remove-VpnConnection -Name "Old VPN" -Force
Get-VpnConnection
A macOS l’equivalent és la llista de serveis de xarxa, on un servei existent es connecta pel nom en lloc de crear-se sobre la marxa.
Les credencials es filtren a cada capa, així que trieu el canal
Tot el que passeu a la línia d’ordres apareix a la taula de processos per a cada usuari local, i normalment també sobreviu a l’historial de l’intèrpret d’ordres. L’alternativa suportada d’OpenVPN és llegir el secret des d’un fitxer amb --askpass, i el fitxer mateix necessita permisos que coincideixin amb la confiança que hi dipositeu. Un conducte amb nom evita escriure el secret al disc però deixa que qualsevol procés que el pugui obrir hi escrigui. A Windows, deseu el secret al gestor de credencials, o en un fitxer que només el compte de servei pugui llegir, i mai com a literal en un fitxer batch.
openvpn --config /etc/openvpn/work.conf --askpass /etc/openvpn/work.secret --auth-nocache --daemon
ls -l /etc/openvpn/work.secret
La mateixa regla s’aplica als testimonis i als codis d’un sol ús: si l’automatització els necessita, l’automatització necessita un canal que no sigui un argument de línia d’ordres. Roteu el secret quan canvieu el mecanisme, perquè el valor antic ha estat en un registre en algun lloc. Un script que funciona i que filtra no és un script que funciona.
Espereu l’estat i després supervisueu un sol propietari
Cadascuna d’aquestes crides torna abans que el túnel estigui a punt, així que consulteu l’estat que exposa el client o proveu una destinació a dins amb un temps d’espera. Copiar fitxers o obrir una connexió de base de dades just després de la crida de connexió és una cursa, i falla de manera intermitent d’una manera que sembla una fallada de xarxa.
ip link show tun0
nmcli -t -f GENERAL.STATE connection show "Work VPN"
curl -sS --max-time 5 https://app.internal.example/health -o /dev/null
La desconnexió té el mateix problema a l’inrevés: el procés pot acabar abans que les rutes hagin desaparegut. Feu servir els hooks del client on existeixin, com els scripts up i down de OpenVPN o l’ExecStartPost d’una unitat systemd, perquè s’executen en el punt que realment us importa. Els hooks s’executen amb els privilegis de qui els ha invocat, així que un hook que reinicia la xarxa necessita una regla explícita en lloc d’una suposició. Manteniu exactament un propietari durant la vida de la connexió.
Quan dos supervisors engeguen i aturen el mateix perfil, el resultat és un bucle de reconnexió que es llegeix com una caiguda del proveïdor. El runbook acaba quan la capa està documentada, el secret té un canal que no és argv, la condició d’espera és una comprovació d’estat amb temps d’espera, i un sol procés posseeix el cicle de vida.