SSH oer in twadde privee paad wylst de VPN oan bliuwt

Ien masine berikt in oare fia in VPN, en no wol immen deselde shell fia in privee netwurk fan in leveransier. De rûte bestiet, de ping slagget, en SSH wegeret noch altyd. De gewoane oarsaak is dat de daemon nea op it nije adres harke, dat der is neat om mei te ferbinen. Dit is in adresbiningprobleem foardat it in firewallprobleem is.

Wêrom in nije rûte gjin nije harker makket

In harkjende socket wurdt makke troch in proses dat de adressen neamt dy't it akseptearje sil. In rûte fertelt pakketten allinnich wêr't se reizgje moatte; it makket gjin harker op 'e bestimming. As sshd konfigurearre is mei ien ListenAddress, wurde ferbiningen nei elk oar lokaal adres wegere, sels as it ynterface oan is. Itselde jildt foar in socket-ienheid dy't de poarte besit, en dêrom is de earste kontrôle altyd wat eins harket.

Fergelykje de twa rûtes op it bestimmingsadres ynstee fan de ynterfacenamme. In klant ferbynt mei in adres, en dat adres moat bûn wêze foardat in firewallregel fan belang is.

List de adressen en de harkers op

Foardat jo eat bewurkje, skriuw de adressen op 'e host en de sockets dy't no bestean.

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

De adreslist lit sjen hokker privee adres echt is en op hokker ynterface, wylst de socketlist lit sjen oft der eat oan bûn is. In harker op 0.0.0.0:22 akseptearret al elk adres, dus in nije bining foeget neat ta. In harker op ien spesifyk adres ferklearret de wegering daliks. As de poarte by in socket-ienheid heart ynstee fan by de daemon, is de daemonkonfiguraasje net it hiele ferhaal.

Foegje de bining ta en hâld de âlde

OpenSSH akseptearret ferskate ListenAddress-ynfieringen, dus it VPN-paad kin bliuwe wylst it privee paad tafoege wurdt. Test it bestân foardat jo it opnij lade.

sshd -t
systemctl reload sshd

In mislearre konfiguraasjetest lit de draaiende daemon ûnoantaast, en dat is krekt wat jo wolle wylst jo ferbûn binne fia it paad dat jo bewurkje. Hâld de besteande ynfiering, foegje it nije lokale adres ta en befêstigje dat de tsjinst opnij ladet sûnder de hjoeddeiske sesje te ferliezen. Op socket-aktivearre ynstallaasjes foegje jo it adres ynstee ta oan 'e socket-ienheid en lade dy ienheid opnij. Lês dan de harkerlist opnij, want in bining dy't nea ferskynde betsjut dat it ferkearde komponint bewurke is.

Ferifiearje de nije sesje foardat jo de âlde slute

Ferbyn mei it nije adres wylst de oarspronklike sesje noch iepen is, en brûk wiidweidige útfier om te sjen hokker adres en kaai brûkt binne. Hâld de oarspronklike sesje iepen oant de test twa kear slagget.

ssh -v [email protected]

Lês de debug-regels foar it bestimmingsadres en de hostkaai dy't presintearre is. Befêstigje de fingerôfdruk fan 'e hostkaai tsjin in wearde dy't jo al fertrouwe, ynstee fan in ûnbekende kaai te akseptearjen omdat it netwurk as privee beskreaun wurdt. De nije bestimming hat syn eigen known_hosts-ynfiering nedich, en dat is te ferwachtsjen. Pas as it privee paad wurket, moat de âlde beheersesje sletten wurde.

SSH beskermet it transport, mar it makket twa netwurken net op himsels gelykweardich. Beslis oft it fertrouwen fan 'e privee trochgong by de gegevens past foardat jo derop fertrouwe.