Mantén o SSH local cando o servidor usa unha VPN de saída

Un pequeno servidor Linux executa unha VPN de saída para a aplicación que aloxa, e o administrador aínda quere chegar a el por SSH desde o escritorio de ao lado. É un requisito razoable, e normalmente non necesita nin redirección de portos, nin enderezo do provedor, nin un burato no túnel. O que necesita é un camiño de xestión deseñado a propósito en lugar de herdado do que o cliente VPN fixo coa táboa de encamiñamento.

Os pasos seguintes asumen que o administrador está na mesma LAN.A administración remota é outro problema con outra resposta.

Vincula o SSH ao enderezo que usan os administradores

Comeza polo oínte.ss -ltnp | grep :22 mostra a que está ligado sshd, e un oínte en 0.0.0.0 acepta conexións de todas as interfaces, incluído o túnel. Ligarse ao enderezo da LAN é máis estreito e fai visible a intención:ListenAddress 192.168.10.20 en sshd_config, seguido dunha proba de configuración e unha recarga. Unha errata nese enderezo é máis visible que un comodín, porque sshd négase a arrincar cando o enderezo non existe.

Mantén a comprobación de clave de servidor e a autenticación por usuario exactamente como están. «Só é a rede local» non é un método de autenticación, e unha canle de xestión que salta a verificación de clave porque a ruta é curta é unha canle de xestión que espera ser abusada. Unha reserva DHCP ou un enderezo estático fai previsible o obxectivo sen convertelo na identidade pública do servidor.

Mantén a ruta da LAN fóra do túnel

Un servidor cun enderezo en 192.168.10.0/24 ten unha ruta conectada para ese prefixo, e unha ruta máis específica gana á predeterminada da VPN dentro da mesma táboa. Por iso o SSH local adoita seguir funcionando só cando o túnel sobe. Verifícao en lugar de asumilo:ip route get 192.168.10.50 nomea a interface e o enderezo de orixe que usaría o núcleo, e a resposta debería ser o dispositivo da LAN, non o túnel. Repite a comprobación tamén desde a máquina do administrador, porque a súa propia táboa decide se os paquetes chegan algunha vez. Dous servidores no mesmo cable poden discrepar sobre que dirección é alcanzable.

A suposición rompe en dous lugares. Unha regra de encamiñamento por política pode enviar tráfico a unha táboa cuxa predeterminada apunta ao túnel antes de que se consulte a táboa principal. Un cliente VPN con función de bloqueo ou kill-switch tamén pode bloquear tráfico que non entra no túnel, independentemente do que diga a táboa de encamiñamento.

As VLAN de xestión encamiñadas son o outro caso. Se o administrador está en 192.168.50.0/24 detrás do router local, o servidor necesita unha ruta explícita para ese prefixo a través de 192.168.10.1, e esa ruta ten que sobrevivir a unha reconexión. Mantén a excepción específica para o prefixo de xestión; unha excepción ampla para rangos privados anula o propósito do túnel.

Fai a excepción do cortalumes tan estreita como a regra

Se o servidor executa un cortalumes, permite SSH só desde a orixe de xestión e só na interface da LAN. Unha regra que permite o porto 22 desde calquera lugar é máis ampla que o requisito e máis difícil de xustificar nunha revisión. Nun servidor nftables a regra vai na cadea de entrada coa interface e a orixe coincidentes; nun servidor iptables o equivalente é un par de coincidencias en -i e -s. Comenta a regra co grupo de administradores ao que serve, para que a próxima auditoría non teña que adiviñar por que o porto 22 está aberto.

Comproba tamén o filtro propio do cliente VPN. Algúns clientes instalan regras que descartan tráfico local por deseño, e unha regra de cortalumes correcta por riba dun descarte a nivel de cliente non cambia nada. Le a configuración do cliente antes de editar o cortalumes do servidor, porque dous filtros en serie producen un fallo que non se parece a ningún dos dous.

Proba os dous estados

Executa a proba dúas veces: unha co túnel conectado e outra co túnel desconectado. En cada estado, confirma o oínte, a ruta e un inicio de sesión SSH real desde a máquina do administrador. Un camiño que só funciona mentres o túnel está levantado non é un camiño de xestión local; é unha coincidencia.

Despois reinicia o túnel mentres hai unha sesión SSH aberta. Unha sesión que sobrevive demostra que o encamiñamento é estable; unha sesión que cae diche que o cliente reescribe rutas ou filtros ao reconectar, o que paga a pena saber antes dun incidente máis que durante un.

Anota o enderezo de orixe desde o que probaches, porque unha regra escrita para 192.168.10.50 falla en silencio cando o portátil do administrador se move a outra subrede.

Escribe o camiño de recuperación no runbook

Decide agora que pasa se a VPN de saída rompe o camiño local. O acceso por consola, un segundo enderezo de xestión ou un procedemento documentado para deter o cliente son todas respostas lexítimas, e calquera delas é mellor que descubrir o problema no momento en que necesitas iniciar sesión. Se o servidor é remoto, o camiño local non existe, e o deseño correcto é unha ruta de acceso remoto aprobada e separada ou un bastión en lugar dun porto público exposto.

Mantén os dous papeis separados na documentación: o SSH local para o administrador que está preto, e o túnel de saída para o tráfico da aplicación. Cando eses papeis están escritos, un cambio futuro en calquera dos dous ten un lugar obvio onde ser comprobado, e a seguinte persoa non ten que redescubrir por que un servidor cunha VPN segue respondendo no seu enderezo da LAN.