SSH remoto sobre unha VPN: o que o túnel non fai

Unha VPN dálle a un servidor SSH unha ruta privada e elimina a necesidade dun oínte público no porto 22. Non autentica o host, non autoriza o usuario nin decide que contas poden iniciar sesión. Iso segue a ser tarefa de SSH. Que unha VPN sexa a forma correcta de chegar ao servidor depende de tres condicións, e o túnel é só unha das respostas posibles.

Que cambia o túnel e que segue decidindo SSH

O túnel cambia a accesibilidade: que enderezos se poden alcanzar e desde onde. Non cambia o que ocorre despois de que chega a conexión TCP, onde o servidor presenta unha clave de host e pide unha identidade de usuario.

Mantén as dúas capas separadas na túa cabeza e na túa documentación. Un inicio de sesión VPN demostra quen pode usar a rede. Non di nada sobre que contas existen no obxectivo, e non é permiso para iniciar sesión en cada máquina accesible.

Os modos de fallo tamén son separados, e iso é o que fai útil a separación durante un incidente.

Tres condicións que deciden o modelo de acceso

Primeiro, o servidor necesita ser accesible por persoas fóra da túa rede? Se non, unha ruta privada máis un bastión ou unha malla é o deseño máis pequeno. Segundo, a poboación de clientes pode executar realmente o cliente VPN, incluídos os que están en dispositivos xestionados con restricións?

Terceiro, necesitas control por servizo ou control por usuario? Unha VPN outorga alcance de rede; SSH outorga acceso á conta. Se o requisito é que un contratista chegue a un host e a nada máis, iso é un requisito de autorización e o túnel por si só non pode expresalo.

Responde esas tres e o modelo elíxese só. Pásalas por alto e acabarás expoñendo SSH publicamente para evitar o despregamento do cliente.

Confirma a ruta privada antes de culpar SSH

Conecta a VPN aprobada e usa o nome ou o enderezo privado documentado do obxectivo. Despois comproba a ruta seleccionada, o permiso da pasarela e a ruta de volta ao cliente. Un nome que se resolve correctamente non é proba de que o enderezo tome o túnel previsto, porque os prefixos locais e remotos superpostos poden enviar a petición a outro lugar por completo. Esa distinción merece escribirse no runbook.

Se a conexión nunca chega, confirma que o servidor escoita na interface que esperas e que o seu firewall de host permite a orixe que realmente ve. Un NAT de pasarela pode reescribir esa orixe, así que unha lista de permitidos escrita para o enderezo do túnel do cliente pode non coincidir nunca.

Esa discrepancia é o fallo de SSH autoinxerido máis común sobre unha VPN.

Le a etapa de fallo, non o erro combinado

Tres etapas producen tres mensaxes diferentes, e só unha delas trata de credenciais.

Usa o erro exacto e o rexistro propio do servidor en lugar de restablecer xuntas as credenciais de VPN e SSH. Restablecer ambas é como un diagnóstico de cinco minutos se converte nun incidente de identidade de dous días.

A saída detallada mostra a que etapa chegaches:

ssh -vv [email protected]

Mantén intactas as claves de host e a autorización

Valida a clave de host mediante o proceso de confianza previsto, especialmente despois de substituír un servidor. Un aviso inesperado de clave cambiada é a única mensaxe que non debes descartar só porque a VPN se conectou, porque un túnel privado non fai que o destino sexa a máquina que cres. Comproba a pegada contra unha fonte na que confíes independentemente da conexión.

No lado do servidor, confirma que a conta está autorizada e que o método de autenticación que configuraches é o que se ofrece. Unha clave presente pero ignorada adoita ser un problema de permisos ou de configuración, non de rede.

Limita o acceso aos servizos ás identidades necesarias e mantén unha ruta de recuperación autorizada para os cambios de rede.