Bastión SSH o acceso directo por VPN: ¿qué política se aplica?

Si los usuarios de VPN pueden llegar a los servidores sin cruzar un host de salto es una cuestión de política disfrazada de red. Si el bastión realiza un control obligatorio, entonces unirse a la VPN debe llevar a él y no rodearlo. Si el host de salto solo unía un segmento que antes era inalcanzable, un camino directo estrecho puede ser la sustitución honesta. Haga las comprobaciones siguientes en orden y deténgase en la primera que falle, porque esa respuesta decide el resto.

Compruebe qué controla realmente el bastión

Empiece con pruebas sobre el presente, no con un diagrama del documento de diseño. Mire la configuración SSH y el filtro de paquetes del destino: si el puerto 22 entrante solo se acepta desde la dirección del bastión, el host de salto es un control impuesto. Si el mismo puerto acepta conexiones de todo el conjunto de VPN, el bastión era una comodidad y la aplicación vive en otro lugar por completo. El historial de tiques suele confirmar cuál de los dos existió primero.

Enuncie el hallazgo en una frase que nombre el control que aporta el bastión: restricción de destino, un segundo paso de autenticación, grabación de sesión o visibilidad operativa durante un incidente. Esa frase es lo que la política de sustitución debe preservar.

Compruebe si el destino puede distinguir los caminos

Las reglas de dirección de origen solo funcionan mientras los dos caminos llegan con direcciones de origen distintas. Una puerta de enlace VPN que enmascara el tráfico hacia la subred de servidores borra esa diferencia, y entonces cada conexión al puerto 22 parece venir de la puerta de enlace. La comprobación es local en el destino y tarda un momento: liste las sesiones SSH establecidas y lea la dirección del par de cada una.

Cuando ambos caminos colapsan en una sola dirección, la distinción debe hacerse antes, por los destinos que la VPN puede empujar y por los filtros propios de la puerta de enlace. Añadir una regla en el destino en esa situación crea la ilusión de una frontera sin cambiar lo que llega.

Compruebe qué guarda realmente cada registro

Tres registros distintos describen tres eventos distintos, y ninguno sustituye a otro. El registro de conexión de la VPN muestra que una identidad entró en el ámbito de red. El registro de reenvío del bastión muestra un canal TCP que sale de él hacia un destino y un puerto. El registro de autenticación del destino muestra que una cuenta inició sesión por SSH. Leerlos juntos es lo que produce una cronología; leer uno solo produce una conjetura.

Ninguno de esos registros contiene lo que ocurrió dentro de la sesión cifrada entre cliente y destino. Si la revisión a nivel de comando es un requisito, necesita un mecanismo de grabación desplegado deliberadamente con sus propias reglas de tratamiento de datos. Esperarlo de los registros del host de salto es como un hueco de auditoría queda oculto hasta que importa.

Compruebe dónde se aplica realmente la política

Un ajuste de cliente como ProxyJump es una petición, no una restricción. OpenSSH abrirá de buen grado una conexión directa cuando el destino sea alcanzable, así que los archivos de configuración de los portátiles describen la intención mientras los cortafuegos deciden el resultado. La aplicación corresponde a los destinos permitidos de la puerta de enlace VPN y a las reglas de acceso propias del destino, y el usuario no puede editar ninguna de las dos. Audite los caminos alternativos al mismo tiempo: una segunda interfaz, un oyente público, una capa mesh o un túnel antiguo entre sedes pueden cada uno restaurar el atajo que acaba de cerrar.

Configure ProxyJump de todos modos, porque hace que la ruta aprobada sea la fácil y evita que el trabajo rutinario genere excepciones. Confirme qué resuelve realmente el cliente antes de confiar en él.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Verifique con un intento directo deliberado

Una política que nunca se ha probado es una esperanza. Desde un cliente conectado a la VPN, intente el camino que ahora debería rechazarse, después intente el aprobado y conserve ambos resultados. El intento rechazado es la prueba de que el cambio surtió efecto.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Un resultado limpio se parece a una conexión directa rechazada o agotada por tiempo hacia la dirección del destino, seguida de un inicio de sesión correcto en el host de salto y de una entrada de autenticación del lado del destino que nombre el origen admitido. Cualquier otra cosa significa que la frontera sigue siendo porosa, diga lo que diga la documentación. Anote la fecha, la regla que se cambió y los dos resultados, y luego dé al camino de recuperación un responsable y una fecha de caducidad para que el acceso de emergencia no se convierta en silencio en la ruta cotidiana.