SSH per una segona ruta privada mentre la VPN continua activa

Una màquina arriba a una altra per una VPN, i ara algú vol el mateix shell per una xarxa privada del proveïdor. La ruta existeix, el ping té èxit i SSH continua refusant. La causa habitual és que el dimoni mai no ha escoltat a l'adreça nova, així que no hi ha res a què connectar-se. Aquest és un problema de vinculació d'adreces abans que un problema de tallafoc.

Per què una ruta nova no crea un escoltador nou

Un socket d'escolta el crea un procés que anomena les adreces que acceptarà. La ruta només diu als paquets on han de viatjar; no crea cap escoltador a la destinació. Quan sshd es configura amb un sol ListenAddress, les connexions a qualsevol altra adreça local es refusen encara que la interfície estigui activa. El mateix passa amb una unitat de socket que posseeix el port, i per això la primera comprovació sempre és què està escoltant realment.

Compareu les dues rutes per l'adreça de destinació i no pel nom de la interfície. Un client es connecta a una adreça, i aquesta adreça ha d'estar vinculada abans que cap regla de tallafoc sigui rellevant.

Llista les adreces i els escoltadors

Abans d'editar res, anoteu les adreces de l'amfitrió i els sockets que existeixen ara.

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

La llista d'adreces mostra quina adreça privada és real i en quina interfície, mentre que la llista de sockets mostra si hi ha alguna cosa vinculada. Un escoltador a 0.0.0.0:22 ja accepta totes les adreces, així que una vinculació nova no hi afegeix res. Un escoltador en una adreça concreta explica el refús de seguida. Si el port pertany a una unitat de socket i no al dimoni, la configuració del dimoni no és tota la història.

Afegiu la vinculació i manteniu la vella

OpenSSH accepta diverses entrades ListenAddress, així que la ruta VPN pot quedar-se mentre s'afegeix la privada. Proveu el fitxer abans de recarregar-lo.

sshd -t
systemctl reload sshd

Una prova de configuració fallida deixa el dimoni en marxa intacte, i és exactament el que voleu mentre esteu connectat per la ruta que editeu. Manteniu l'entrada existent, afegiu l'adreça local nova i confirmeu que el servei es recarrega sense deixar caure la sessió actual. En instal·lacions activades per socket, afegiu l'adreça a la unitat de socket i recarregueu aquesta unitat. Després torneu a llegir la llista d'escoltadors, perquè una vinculació que no ha aparegut mai vol dir que s'ha editat el component equivocat.

Verifiqueu la sessió nova abans de tancar la vella

Connecteu-vos a l'adreça nova mentre la sessió original encara és oberta, fent servir sortida detallada per veure quina adreça i quina clau s'han utilitzat. Manteniu la sessió original oberta fins que la prova tingui èxit dues vegades.

ssh -v [email protected]

Llegiu les línies de depuració de l'adreça de destinació i de la clau d'amfitrió que s'ha presentat. Confirmeu l'empremta de la clau d'amfitrió amb un valor en què ja confieu, en lloc d'acceptar una clau desconeguda perquè la xarxa es descriu com a privada. La destinació nova necessita la seva pròpia entrada a known_hosts, i això és d'esperar. Només quan la ruta privada funcioni s'hauria de tancar la sessió de gestió antiga.

SSH protegeix el transport, però no fa que dues xarxes siguin equivalents per si soles. Decidiu si la confiança del trànsit privat encaixa amb les dades abans de confiar-hi.