Editor VPN remot per SSH: quin ordinador esteu editant?

El reenviament X11 posa la finestra de l'editor al vostre portàtil mentre el procés continua executant-se a l'amfitrió remot. Aquesta escletxa és tota la trampa: mireu una finestra local i editeu un perfil remot, i una suposició errònia sobre quin ordinador posseeix el canvi pot tallar l'enllaç SSH pel qual treballeu. La llista de verificació següent fixa l'amfitrió i el perfil abans que es desi res. Cada pas té una condició d'aturada, de manera que un error primerenc surt barat.

Pas 1: anomeneu l'ordinador que posseeix el perfil

Executeu les ordres d'identitat al shell que esteu a punt de configurar i llegiu la resposta en lloc de suposar-la pel prompt. Un nom d'amfitrió al prompt és una cadena que ha imprès el vostre shell; el nom d'amfitrió del nucli és el que confia la resta d'aquesta llista. Si els dos no coincideixen, sou a l'ordinador equivocat o el prompt està decorat pel vostre shell local. Atureu-vos i torneu a connectar a l'amfitrió previst abans de continuar.

hostnamectl
hostname -f
ip -brief address

La pregunta següent és si aquest ordinador ha de tenir la VPN, si més no. Configurar el client del portàtil i configurar el client de l'amfitrió remot produeixen rutes diferents, DNS diferent i modes de fallada diferents. Decidiu quin dels dos voleu dir abans de tocar cap perfil, i escriviu la decisió on la trobarà la propera persona.

Pas 2: llegiu el perfil per UUID, no per etiqueta

NetworkManager identifica una connexió per UUID, mentre que el nom és una etiqueta que qualsevol pot editar o duplicar. Lliste-los tots dos i feu coincidir l'entrada que realment voleu, sobretot en un amfitrió on s'han importat diversos perfils VPN al llarg dels anys.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
nmcli general permissions

Les entrades desades i les connexions actives responen preguntes diferents: la primera llista què existeix, la segona llista què porta trànsit ara mateix. La línia de permisos descriu la política local de la vostra sessió i no diu res sobre si la passarel·la VPN acceptarà el compte. Si el perfil que necessiteu no és a la llista desada, atureu-vos aquí, perquè editar l'entrada equivocada és pitjor que no editar-ne cap.

Quan tingueu l'UUID, poseu-lo en una variable i feu servir aquesta variable a cada ordre posterior. Això elimina una classe d'errors de copiar i enganxar i fa que la transcripció sigui reproduïble.

UUID=$(nmcli -g UUID connection show 'Corp VPN')
nmcli connection edit uuid "$UUID"

Pas 3: decidiu si un editor gràfic és l'eina adequada

Un editor que necessita un avís de polkit o un agent de secrets no en tindrà només perquè la seva finestra aparegui al vostre portàtil. Aquests components s'executen en el context de la sessió remota, i reenviar una pantalla no els reenvia. Si l'editor no pot desar amb un error d'autorització o de secret, la pantalla no és el problema.

echo "$DISPLAY"
ssh -X you@vpn-host
xauth list

OpenSSH habilita el reenviament X11 amb -X i documenta la precaució que hi va associada: l'amfitrió remot pot arribar a la vostra pantalla local, cosa que és una frontera de confiança real. El reenviament de confiança amb -Y elimina algunes d'aquestes comprovacions i no hauria de ser mai la solució reflexa per a una aplicació que falla amb la configuració predeterminada. Si la vostra organització publica un mètode d'administració remota, feu servir aquest en lloc d'inventar una variant. En la majoria de casos, l'editor de línia d'ordres és la superfície més petita i la resposta millor.

Atureu-vos aquí si l'únic camí que funciona requereix -Y i no podeu explicar per què. Aquesta és una decisió de qui posseeix la política de seguretat, no una solució alternativa per guardar en un script personal.

Pas 4: manteniu un camí de recuperació abans d'activar res

Un canvi de VPN pot eliminar la ruta de què depèn la vostra sessió SSH, així que prepareu una manera de tornar abans d'activar el perfil. L'accés per consola, una adreça de gestió fora de banda o una reversió programada compten; l'esperança que el canvi funcioni no compta.

sudo systemctl status NetworkManager
ip route show default
ss -tn state established '( sport = :22 )'

Activeu només el perfil previst i després verifiqueu des de l'amfitrió remot: la ruta predeterminada, el camí de retorn SSH i un recurs que hauria de ser accessible pel túnel. Una comprovació correcta des del vostre portàtil prova el camí del portàtil i no diu res de l'amfitrió remot. Si la sessió cau, feu servir el camí de recuperació en lloc de reconnectar a cegues. Desar un perfil no és activar-lo, i activar-lo no és verificar-lo.

Anoteu l'UUID, els valors de propietat que heu canviat i les ordres que heu fet servir per verificar-los. La propera persona que toqui aquest amfitrió necessitarà les tres coses, i una transcripció val més que un resum que digui que la VPN s'ha arreglat. Una llista de verificació que acaba sense una nota de reversió és mitja llista.