El ping funciona pero SSH falla por la VPN: ¿qué etapa se rompió?
Un solo intento detallado separa la accesibilidad TCP, el transporte SSH, la identidad del host, el inicio de sesión del usuario y el permiso de sesión, para que dejes de adivinar sobre el túnel.
Las respuestas de ping y un inicio de sesión SSH rechazado pueden ser ciertos a la vez, y el par no incrimina al túnel. Las respuestas de eco y una conexión TCP al puerto 22 son pruebas distintas con selectores distintos, políticas distintas y a menudo destinos distintos. Captura un intento SSH deliberado y luego nombra la última etapa que alcanzó. Ese único artefacto sustituye a una docena de cambios de configuración especulativos.
Captura un intento, no una sesión de toqueteos
Ejecuta el cliente una vez con diagnósticos detallados, uso compartido de conexión desactivado y un tiempo de espera de conexión acotado. Desactivar el uso compartido importa porque una conexión maestra autenticada previamente responderá por el nuevo intento y ocultará el fallo que persigues.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Conserva el destino, la familia de direcciones, la marca de tiempo y el error final no secreto. El indicador IPv4 también significa que este intento no dice nada sobre una ruta IPv6 hacia el mismo nombre, así que no generalices a partir de él. Anota desde dónde se hizo el intento. Una comprobación en la puerta de enlace VPN no es el mismo punto de vista que un portátil detrás de ella, y la mayoría de las contradicciones en estos tiques vienen de mezclar los dos.
Etapas uno y dos: TCP antes que SSH
La primera frontera es la accesibilidad del socket: una dirección, un puerto y una ruta que el paquete sigue de verdad. Si la conexión TCP nunca se completa, todavía no existe nada por encima, y las claves de host y las cuentas son irrelevantes.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'Correlaciona la captura con el intento del cliente. Un SYN que sale y nada que regresa apunta a filtrado, selectores o una ruta ausente en el otro extremo; una respuesta con un reset apunta a algo que rechaza activamente en lugar de descartar. La segunda frontera es el intercambio del protocolo SSH en sí. Una conexión TCP que se completa y luego se atasca ha pasado la accesibilidad y ha entrado en negociación, respuesta del servidor o manejo de paquetes. Eso es otra investigación, y es donde los problemas relacionados con el tamaño se vuelven plausibles por primera vez.
Etapa tres: qué clave respondió
Cuando el transporte está activo, el cliente verifica la clave de host del servidor. Un rechazo aquí es una afirmación sobre la identidad, no sobre la criptografía: el par presentó una clave que tu política no acepta. Trátalo como una condición de parada y verifica fuera de banda, contra la consola o el operador que reconstruyó el host. Borrar la entrada recordada para eliminar la advertencia es el único atajo que conviene rechazar, porque destruye la evidencia de que algo respondió de forma inesperada.
Si el host realmente se reconstruyó, elimina el registro obsoleto solo después de confirmar la nueva huella, y anota la fecha y el motivo. El siguiente ingeniero se encontrará con la misma advertencia y necesita ese contexto.
Etapas cuatro y cinco: cuenta frente a permiso
La autenticación es la cuarta frontera. Unas credenciales rechazadas significan que el servidor evaluó el intento y lo rechazó; revisa la cuenta, el tipo de credencial que acepta el servidor y la política propia del servidor en lugar de la contraseña de la VPN. La quinta frontera es la autorización tras un inicio de sesión correcto. A un usuario autenticado todavía se le puede negar un shell, un comando, un subsistema o un reenvío, y esas negativas parecen fallos a quien solo lee la última línea del cliente.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
Detente tras un par de intentos de contraseña fallidos. Las conjeturas repetidas producen bloqueos que luego parecen un segundo fallo no relacionado y cuestan más tiempo que el tique original.
Reversión y el registro que conservas
Cambia una cosa a la vez y anota qué cambiaste antes de volver a probar. Si un cambio empeora el intento, revíertelo de inmediato en lugar de apilar otra corrección encima. Repite la operación original desde el cliente y el contexto originales. Un inicio de sesión correcto desde otra máquina, en otra familia de direcciones, no es una reproducción y no demuestra la corrección.
Sanea lo que compartes. La salida detallada del cliente puede llevar nombres internos, etiquetas de cuenta, rutas de claves e identificadores de claves públicas, así que publica la conclusión por etapas en lugar de un rastro en bruto.