Editor VPN remoto via SSH: qual máquina está editando?

O encaminhamento X11 coloca a janela do editor no seu portátil enquanto o processo continua a correr no host remoto. Essa lacuna é toda a armadilha: está a olhar para uma janela local e a editar um perfil remoto, e uma suposição errada sobre qual máquina detém a alteração pode cortar a ligação SSH por onde trabalha. A lista de verificação abaixo fixa o host e o perfil antes de guardar qualquer coisa. Cada passo tem uma condição de paragem, por isso uma falha precoce é barata.

Passo 1: nomeie a máquina que detém o perfil

Execute os comandos de identidade na shell que vai configurar e leia a resposta em vez de a supor a partir do prompt. Um nome de host no prompt é uma cadeia impressa pela sua shell; o nome de host do kernel é aquele em que o resto desta lista confia. Se os dois discordarem, está na máquina errada ou o prompt está decorado pela sua shell local. Pare e volte a ligar-se ao host pretendido antes de continuar.

hostnamectl
hostname -f
ip -brief address

A pergunta seguinte é se esta máquina deve alojar a VPN de todo. Configurar o cliente do portátil e configurar o cliente do host remoto produzem rotas, DNS e modos de falha diferentes. Decida qual dos dois tem em mente antes de tocar num perfil, e registe a decisão onde a próxima pessoa a encontre.

Passo 2: leia o perfil por UUID, não por etiqueta

O NetworkManager identifica uma ligação por UUID, enquanto o nome é uma etiqueta que qualquer pessoa pode editar ou duplicar. Liste ambos e faça corresponder a entrada que realmente pretende, sobretudo num host onde foram importados vários perfis VPN ao longo dos anos.

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

As entradas guardadas e as ligações ativas respondem a perguntas diferentes: a primeira lista o que existe, a segunda lista o que está a transportar tráfego neste momento. A linha de permissões descreve a política local da sua sessão e não diz nada sobre se o gateway VPN aceitará a conta. Se o perfil de que precisa não estiver na lista guardada, pare aqui, porque editar a entrada errada é pior do que não editar nada.

Assim que tiver o UUID, coloque-o numa variável e use essa variável em cada comando posterior. Isso elimina uma classe de erros de copiar e colar e torna a transcrição reproduzível.

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

Passo 3: decida se um editor gráfico é a ferramenta certa

Um editor que precisa de um pedido polkit ou de um agente de segredos não o terá só porque a sua janela aparece no seu portátil. Esses componentes correm no contexto da sessão remota, e encaminhar um ecrã não os encaminha. Se o editor não conseguir guardar com um erro de autorização ou de segredo, o ecrã não é o problema.

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

O OpenSSH ativa o encaminhamento X11 com -X e documenta o cuidado que o acompanha: o host remoto pode alcançar o seu ecrã local, o que é uma verdadeira fronteira de confiança. O encaminhamento de confiança com -Y remove algumas dessas verificações e nunca deve ser a solução refleixa para uma aplicação que falha com a configuração predefinida. Se a sua organização publica um método de administração remota, use esse em vez de inventar uma variante. Na maioria dos casos, o editor de linha de comandos é a superfície mais pequena e a melhor resposta.

Pare aqui se o único caminho que funciona exigir -Y e não conseguir explicar porquê. É uma decisão de quem detém a política de segurança, não uma solução alternativa para guardar num script pessoal.

Passo 4: mantenha um caminho de recuperação antes de ativar o que quer que seja

Uma alteração de VPN pode remover a rota de que depende a sua sessão SSH, por isso prepare uma forma de voltar antes de ativar o perfil. O acesso à consola, um endereço de gestão fora de banda ou uma reversão agendada contam; a esperança de que a alteração funcione não conta.

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

Ative apenas o perfil pretendido e depois verifique a partir do host remoto: a rota predefinida, o caminho de retorno SSH e um recurso que deveria estar acessível pelo túnel. Uma verificação bem-sucedida a partir do seu portátil testa o caminho do portátil e não diz nada sobre o host remoto. Se a sessão cair, use o caminho de recuperação em vez de se ligar novamente às cegas. Guardar um perfil não é ativá-lo, e ativar não é verificar.

Anote o UUID, os valores de propriedade que alterou e os comandos que usou para os verificar. A próxima pessoa que tocar neste host precisará dos três, e uma transcrição vale mais do que um resumo que diga que a VPN foi reparada. Uma lista de verificação que termina sem uma nota de reversão é meia lista.