Bastión SSH ou acceso directo por VPN: que política se aplica?

Se os usuarios de VPN poden chegar aos servidores sen cruzar un host de salto é unha cuestión de política disfrazada de rede. Se o bastión realiza un control obrigatorio, entón unirse á VPN debe levar a el e non rodealo. Se o host de salto só unía un segmento que antes era inalcanzable, un camiño directo estreito pode ser a substitución honesta. Faga as comprobacións seguintes en orde e detéñase na primeira que falle, porque esa resposta decide o resto.

Comprobe que controla realmente o bastión

Comece con probas sobre o presente, non cun diagrama do documento de deseño. Mire a configuración SSH e o filtro de paquetes do destino: se o porto 22 entrante só se acepta desde o enderezo do bastión, o host de salto é un control imposto. Se o mesmo porto acepta conexións de todo o conxunto de VPN, o bastión era unha comodidade e a aplicación vive noutro lugar por completo. O historial de tíckets adoita confirmar cal dos dous existiu primeiro.

Enuncie o achado nunha frase que nomee o control que achega o bastión: restrición de destino, un segundo paso de autenticación, gravación de sesión ou visibilidade operativa durante un incidente. Ese é o enunciado que a política de substitución debe preservar.

Comprobe se o destino pode distinguir os camiños

As regras de enderezo de orixe só funcionan mentres os dous camiños chegan con enderezos de orixe distintos. Unha pasarela VPN que enmascara o tráfico cara á subrede de servidores borra esa diferenza, e entón cada conexión ao porto 22 parece vir da pasarela. A comprobación é local no destino e leva un momento: liste as sesións SSH establecidas e lea o enderezo do par de cada unha.

Cando ambos os camiños colapsan nun só enderezo, a distinción debe facerse antes, polos destinos que a VPN pode empurrar e polos filtros propios da pasarela. Engadir unha regra no destino nesa situación crea a ilusión dunha fronteira sen cambiar o que chega.

Comprobe que garda realmente cada rexistro

Tres rexistros distintos describen tres eventos distintos, e ningún substitúe a outro. O rexistro de conexión da VPN mostra que unha identidade entrou no ámbito de rede. O rexistro de reenvío do bastión mostra unha canle TCP que sae del cara a un destino e un porto. O rexistro de autenticación do destino mostra que unha conta iniciou sesión por SSH. Lelos xuntos é o que produce unha cronoloxía; ler un só produce unha conxectura.

Ningún deses rexistros contén o que ocorreu dentro da sesión cifrada entre cliente e destino. Se a revisión a nivel de orde é un requisito, necesita un mecanismo de gravación despregado deliberadamente coas súas propias regras de tratamento de datos. Esperalo dos rexistros do host de salto é como un oco de auditoría queda oculto ata que importa.

Comprobe onde se aplica realmente a política

Un axuste de cliente como ProxyJump é unha petición, non unha restrición. OpenSSH abrirá de boa gana unha conexión directa cando o destino sexa alcanzable, así que os ficheiros de configuración dos portátiles describen a intención mentres os devasos deciden o resultado. A aplicación corresponde aos destinos permitidos da pasarela VPN e ás regras de acceso propias do destino, e o usuario non pode editar ningunha das dúas. Audite os camiños alternativos ao mesmo tempo: unha segunda interface, un oínte público, unha capa mesh ou un túnel antigo entre sedes poden cada un restaurar o atallo que acaba de pechar.

Configure ProxyJump de todos os xeitos, porque fai que a ruta aprobada sexa a fácil e evita que o traballo rutineiro xere excepcións. Confirme que resolve realmente o cliente antes de confiar nel.

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

Verifique cun intento directo deliberado

Unha política que nunca se probou é unha esperanza. Desde un cliente conectado á VPN, tente o camiño que agora debería rexeitarse, despois tente o aprobado e conserve ambos os resultados. O intento rexeitado é a proba de que o cambio surtiu efecto.

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

Un resultado limpo parécese a unha conexión directa rexeitada ou esgotada por tempo cara ao enderezo do destino, seguida dun inicio de sesión correcto no host de salto e dunha entrada de autenticación do lado do destino que nomee a orixe admitida. Calquera outra cousa significa que a fronteira segue a ser porosa, diga o que diga a documentación. Anote a data, a regra que se cambiou e os dous resultados, e despois déalle ao camiño de recuperación un responsable e unha data de caducidade para que o acceso de emerxencia non se converta en silencio na ruta cotiá.