SSH antruoju privačiu keliu, kai VPN lieka įjungtas

Vienas kompiuteris pasiekia kitą per VPN, o dabar kažkas nori tos pačios apvalkalo prieigos per tiekėjo privatų tinklą. Maršrutas yra, ping pavyksta, bet SSH vis tiek atsisako. Įprasta priežastis yra ta, kad demonas niekada neklausė naujuoju adresu, todėl nėra prie ko prisijungti. Tai adreso priskyrimo problema, dar ne ugniasienės problema.

Kodėl naujas maršrutas nesukuria naujo klausytojo

Klausantį lizdą sukuria procesas, kuris nurodo adresus, kuriais priims jungtis. Maršrutas tik pasako paketams, kur keliauti; jis nesukuria klausytojo paskirties vietoje. Kai sshd sukonfigūruotas su vienu ListenAddress, jungtys į bet kurį kitą vietinį adresą atmetamos, nors sąsaja veikia. Tas pats galioja lizdo vienetui, kuriam priklauso prievadas, todėl pirmasis patikrinimas visada yra tai, kas iš tikrųjų klausosi.

Palyginkite du kelius pagal paskirties adresą, o ne pagal sąsajos pavadinimą. Klientas jungiasi prie adreso, ir tas adresas turi būti priskirtas prieš tai, kai bet kokia ugniasienės taisyklė tampa svarbi.

Išvardykite adresus ir klausytojus

Prieš ką nors redaguodami, užrašykite pagrindinio kompiuterio adresus ir šiuo metu esančius lizdus.

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

Adresų sąrašas rodo, kuris privatus adresas yra tikras ir kurioje sąsajoje, o lizdų sąrašas rodo, ar kas nors prie jo prijungta. Klausytojas, veikiantis 0.0.0.0:22 adresu, jau priima visus adresus, todėl naujas priskyrimas nieko neprideda. Klausytojas vienu konkrečiu adresu iš karto paaiškina atsisakymą. Jei prievadas priklauso lizdo vienetui, o ne demonui, demono konfigūracija nėra visa istorija.

Pridėkite priskyrimą ir palikite senąjį

OpenSSH priima kelis ListenAddress įrašus, todėl VPN kelias gali likti, kol pridedamas privatusis. Išbandykite failą prieš jį įkeldami iš naujo.

sshd -t
systemctl reload sshd

Nepavykęs konfigūracijos testas palieka veikiantį demoną nepakeistą, ir būtent to norite būdami prisijungę per tą kelią, kurį redaguojate. Palikite esamą įrašą, pridėkite naują vietinį adresą ir patvirtinkite, kad paslauga įkeliama iš naujo neprarandant dabartinės sesijos. Lizdo aktyvuojamuose įdiegimuose adresą pridėkite prie lizdo vieneto ir įkelkite tą vienetą iš naujo. Tada dar kartą perskaitykite klausytojų sąrašą, nes priskyrimas, kuris taip ir nepasirodė, reiškia, kad buvo redaguotas netinkamas komponentas.

Patikrinkite naują sesiją prieš uždarydami senąją

Prisijunkite prie naujo adreso, kol pradinė sesija dar atvira, ir naudokite išsamią išvestį, kad pamatytumėte, kuris adresas ir raktas buvo naudojami. Palikite pradinę sesiją atvirą, kol patikrinimas pavyks du kartus.

ssh -v [email protected]

Perskaitykite derinimo eilutes apie paskirties adresą ir pateiktą pagrindinio kompiuterio raktą. Palyginkite pagrindinio kompiuterio rakto pirštų atspaudą su jau patikima reikšme, o ne priimkite nežinomą raktą todėl, kad tinklas apibūdintas kaip privatus. Naujai paskirčiai reikia atskiro known_hosts įrašo, ir tai tikėtina. Seną valdymo sesiją uždarykite tik tada, kai privatus kelias veikia.

SSH apsaugo perdavimą, bet atskirai jis nepadaro dviejų tinklų lygiaverčiais. Nuspręskite, ar privataus tranzito pasitikėjimas atitinka duomenis, prieš juo pasikliaudami.