SSH oor 'n tweede private roete terwyl die VPN aan bly

Een masjien bereik 'n ander oor 'n VPN, en iemand wil nou dieselfde dop oor 'n private netwerk van 'n verskaffer he. Die roete bestaan, die ping slaag, en SSH weier steeds. Die gewone oorsaak is dat die daemon nooit op die nuwe adres geluister het nie, so daar is niks om aan te koppel nie. Dit is 'n adresbindingprobleem voordat dit 'n firewallprobleem is.

Waarom 'n nuwe roete nie 'n nuwe luisteraar skep nie

'n Luisterende socket word deur 'n proses geskep wat die adresse benoem wat hy sal aanvaar. 'n Roete vertel net vir pakkette waarheen om te reis; dit skep nie 'n luisteraar by die bestemming nie. Wanneer sshd met 'n enkele ListenAddress opgestel is, word verbindings na enige ander plaaslike adres geweier, selfs al is die koppelvlak op. Dieselfde geld vir 'n socket-eenheid wat die poort besit, en daarom is die eerste kontrole altyd wat werklik luister.

Vergelyk die twee roetes aan die hand van die bestemmingsadres eerder as die koppelvlaknaam. 'n Kliënt verbind na 'n adres, en daardie adres moet gebind wees voordat enige firewallreel saak maak.

Lys die adresse en die luisteraars

Voordat jy enigiets wysig, teken die adresse op die gasheer en die sockets wat nou bestaan aan.

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

Die adreslys wys watter private adres werklik is en op watter koppelvlak, terwyl die socketlys wys of enigiets daaraan gebind is. 'n Luisteraar op 0.0.0.0:22 aanvaar reeds elke adres, so 'n nuwe binding voeg niks by nie. 'n Luisteraar op een spesifieke adres verduidelik die weiering dadelik. As die poort aan 'n socket-eenheid eerder as aan die daemon behoort, is die daemonkonfigurasie nie die hele storie nie.

Voeg die binding by en hou die oue

OpenSSH aanvaar verskeie ListenAddress-inskrywings, so die VPN-roete kan bly terwyl die private een bygevoeg word. Toets die leer voordat jy dit herlaai.

sshd -t
systemctl reload sshd

Mislukte konfigurasietoets laat die lopende daemon onaangeraak, en dit is presies wat jy wil he terwyl jy oor die roete verbind is wat jy wysig. Hou die bestaande inskrywing, voeg die nuwe plaaslike adres by en bevestig dat die diens herlaai sonder om die huidige sessie te laat val. Op socketgeaktiveerde installasies voeg jy die adres eerder by die socket-eenheid by en herlaai daardie eenheid. Lees dan weer die luisteraarlys, want 'n binding wat nooit verskyn het nie, beteken die verkeerde komponent is gewysig.

Verifieer die nuwe sessie voordat jy die oue sluit

Verbind na die nuwe adres terwyl die oorspronklike sessie nog oop is, en gebruik uitvoerige uitset om te sien watter adres en sleutel gebruik is. Hou die oorspronklike sessie oop totdat die toets twee keer slaag.

ssh -v [email protected]

Lees die ontfoutingsreels vir die bestemmingsadres en die gasheersleutel wat aangebied is. Bevestig die gasheersleutel se vingerafdruk teen 'n waarde wat jy reeds vertrou, eerder as om 'n onbekende sleutel te aanvaar omdat die netwerk as privaat beskryf word. Die nuwe bestemming het sy eie known_hosts-inskrywing nodig, en dit is te verwagte. Eers wanneer die private roete werk, moet die ou bestuursessie gesluit word.

SSH beskerm die transport, maar dit maak twee netwerke nie op sigself gelykwaardig nie. Besluit of die vertroue van die private deurgang by die data pas voordat jy daarop staatmaak.