SSH por unha segunda ruta privada mentres a VPN segue activa

Unha máquina chega a outra por unha VPN, e agora alguén quere a mesma shell por unha rede privada dun provedor. A ruta existe, o ping funciona e SSH segue negándose. A causa habitual é que o daemon nunca escoitou no novo enderezo, así que non hai nada ao que conectarse. Este é un problema de ligazón de enderezos antes que un problema de cortalumes.

Por que unha ruta nova non crea un novo escoitador

Un socket en escoita créao un proceso que nomea os enderezos que aceptará. Unha ruta só indica aos paquetes por onde viaxar; non crea un escoitador no destino. Cando sshd se configura cun único ListenAddress, rexéitanse as conexións a calquera outro enderezo local aínda que a interface estea activa. O mesmo ocorre cunha unidade de socket que posúe o porto, e por iso a primeira comprobación sempre é que está escoitando realmente.

Compare as dúas rutas polo enderezo de destino en lugar do nome da interface. Un cliente conéctase a un enderezo, e ese enderezo debe estar ligado antes de que importe calquera regra de cortalumes.

Lista os enderezos e os escoitadores

Antes de editar nada, anota os enderezos do host e os sockets que existen agora.

ip -br addr
ss -ltnp | grep ':22'

A lista de enderezos mostra que enderezo privado é real e en que interface, mentres que a lista de sockets mostra se algo está ligado a el. Un escoitador en 0.0.0.0:22 xa acepta todos os enderezos, así que unha ligazón nova non engade nada. Un escoitador nun enderezo concreto explica o rexeitamento de inmediato. Se o porto pertence a unha unidade de socket e non ao daemon, a configuración do daemon non é toda a historia.

Engade a ligazón e mantén a antiga

OpenSSH acepta varias entradas ListenAddress, así que a ruta da VPN pode quedar mentres se engade a privada. Proba o ficheiro antes de recargalo.

sshd -t
systemctl reload sshd

Unha proba de configuración fallida deixa intacto o daemon en execución, e iso é xusto o que queres mentres estás conectado pola ruta que editas. Mantén a entrada existente, engade o novo enderezo local e confirma que o servizo se recarga sen perder a sesión actual. Nas instalacións activadas por socket, engade o enderezo á unidade de socket no seu lugar e recarga esa unidade. Despois volve ler a lista de escoitadores, porque unha ligazón que nunca apareceu significa que se editou o compoñente equivocado.

Verifica a sesión nova antes de pechar a antiga

Conéctate ao novo enderezo mentres a sesión orixinal segue aberta, usando saída detallada para ver que enderezo e que chave se usaron. Mantén a sesión orixinal aberta ata que a proba teña éxito dúas veces.

ssh -v [email protected]

Le as liñas de depuración do enderezo de destino e da chave de host que se presentou. Confirma a pegada da chave de host cun valor no que xa confías, en lugar de aceptar unha chave descoñecida porque a rede se describe como privada. O novo destino necesita a súa propia entrada en known_hosts, e iso é de esperar. Só cando funcione a ruta privada debería pecharse a sesión de xestión antiga.

SSH protexe o transporte, pero non fai que dúas redes sexan equivalentes por si só. Decide se a confianza do tránsito privado encaixa cos datos antes de depender dela.