Dois alias SSH, um servidor: VPN direta ou host de salto

Mantenha uma rota VPN aprovada e uma rota de bastião aprovada como alias e marcadores separados, para que nenhum atalho precise adivinhar qual rota é autorizada.

O mesmo servidor privado responde por uma VPN aprovada e por um bastião aprovado, e você quer um marcador do Emacs para cada um em vez de um atalho que adivinhe. A decisão não é qual rota é melhor; é qual rota está autorizada para o trabalho à sua frente. Mantenha as duas explícitas, nomeie-as separadamente e deixe o nome do arquivo dizer qual você escolheu.

Condição um: quais rotas são aprovadas?

Um host de salto não é uma alternativa automática a um requisito de VPN, e uma VPN não é uma licença para ignorar um bastião aprovado. Pergunte quais rotas estão autorizadas para a sua conta e para estes dados. Se ambas estiverem, você tem escolha; se só uma, o conjunto de marcadores tem uma entrada. Essa resposta vem do dono dos dados, não da rota que por acaso funciona hoje.

Anote a resposta, porque a distinção desaparece rápido durante um incidente.

As duas rotas também precisam da própria configuração de conta e identidade. Um alias compartilhado que funciona por uma rota pode falhar pela outra por motivos que nada têm a ver com a rede.

Condição dois: você consegue nomear cada rota de forma distinta?

Uma configuração de SSH pode conter dois alias de host para um endereço, cada um com comportamento de proxy diferente. Coloque os blocos específicos antes de qualquer curinga amplo, porque o primeiro valor obtido vence na maioria das opções.

Host proj-direct proj-bastion
    HostName 10.60.0.21
    User analyst
    ControlPath none

Host proj-direct
    ProxyJump none

Host proj-bastion
    ProxyJump gw.example.com

O endereço acima é um exemplo; substitua-o pelo que a sua equipe documenta. O alias de salto também precisa da conta aprovada do bastião, o que normalmente significa um segundo bloco Host para o próprio bastião. Desativar aqui o compartilhamento de conexões mantém a comparação de rotas honesta, já que uma conexão multiplexada reutilizada pode sobreviver à mudança de rota que você está tentando observar.

Então os nomes dos arquivos remotos continuam distintos e legíveis.

/ssh:proj-direct:/srv/project/README.md
/ssh:proj-bastion:/srv/project/README.md

Condição três: o editor conhece a diferença?

O TRAMP trata esses dois nomes de arquivo como destinos diferentes, que é exatamente o que você quer. Marque cada um com um nome que diga qual rota ele usa, e reabra o marcador em vez de editar o significado de um único destino. Dois marcadores também tornam a comparação visível: você pode abrir ambos e ver qual falha sem mudar nenhuma configuração.

Uma configuração merece atenção quando o ProxyJump está envolvido: o compartilhamento de conexões do TRAMP precisa estar desligado para as conexões relevantes, então defina tramp-use-connection-share como nil antes de abri-las. É uma configuração de compatibilidade, não uma correção para uma rota ausente, e não torna autorizada uma rota não autorizada. O FAQ do TRAMP documenta os marcadores como a forma suportada de encurtar esses nomes.

Um marcador que muda de rota em silêncio é pior que nenhum marcador.

Por que o ícone de rede não prova nada

O valor global de estado 70 do NetworkManager significa que a máquina tem conectividade global. Ele não nomeia nenhum perfil de VPN, e o Wi-Fi comum o satisfaz. Um túnel só para a rede privada que carrega exatamente a rota de que você precisa pode deixar esse valor agregado intacto. É por isso que um atalho vinculado ao ícone pode relatar prontidão para uma rota que nunca testou.

Leia o estado da conexão específica em vez do global.

Se você automatizar algo, consulte a conexão nomeada e depois verifique a rota de destino, a resposta do resolvedor e o alcance de SSH nessa ordem. Cada um deles pode falhar enquanto o anterior tem sucesso, e reduzi-los a um único booleano é como a automação acaba relatando sucesso para uma rota que nunca usou.

O que fazer quando uma rota deixa de funcionar

Salve os buffers antes de investigar, porque uma sessão TRAMP existente pode sobreviver a uma mudança de rota e então falhar na gravação seguinte. Feche-a pela limpeza suportada, reabra o marcador e compare as duas rotas em vez de supor que o servidor está fora do ar.

Mantenha a verificação de chave de host ativa tanto para o bastião quanto para o destino.

Uma rota diferente não lhe dá o direito de aceitar uma chave de servidor que você não esperava, nem torna aceitável uma rota não aprovada. As duas são decisões separadas da que você estava tomando.

Artigos relacionados