SSH në një rrugë të dytë private ndërsa VPN mbetet aktiv

Një makinë arrin një tjetër përmes një VPN, dhe tani dikush dëshiron të njëjtin shell në rrjetin privat të një ofruesi. Rruga ekziston, ping-u ka sukses dhe SSH vazhdon të refuzojë. Shkaku i zakonshëm është që daemoni nuk ka dëgjuar kurrë në adresën e re, kështu që nuk ka asgjë për t'u lidhur. Ky është një problem i lidhjes së adresës përpara se të jetë problem i firewall-it.

Pse një rrugë e re nuk krijon një dëgjues të re

Një socket dëgjues krijohet nga një proces që emërton adresat në të cilat do të pranojë lidhje. Rruga vetëm u thotë paketave ku të shkojnë; ajo nuk krijon një dëgjues në destinacion. Kur sshd konfigurohet me një ListenAddress të vetëm, lidhjet drejt çdo adrese tjetër lokale refuzohen edhe pse ndërfaqja është aktive. E njëjta gjë vlen për një njësi socket që zotëron portën, prandaj kontrolli i parë është gjithmonë çfarë po dëgjon në të vërtetë.

Krahasoni dy rrugët sipas adresës së destinacionit, jo sipas emrit të ndërfaqes. Një klient lidhet me një adresë, dhe ajo adresë duhet të jetë e lidhur përpara se ndonjë rregull firewall të ketë rëndësi.

Listoni adresat dhe dëgjuesit

Përpara se të ndryshoni ndonjë gjë, regjistroni adresat në host dhe socket-et që ekzistojnë tani.

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

Lista e adresave tregon se cila adresë private është e vërtetë dhe në cilën ndërfaqe, ndërsa lista e socket-eve tregon nëse diçka është e lidhur me të. Një dëgjues në 0.0.0.0:22 tashmë pranon çdo adresë, kështu që një lidhje e re nuk shton asgjë. Një dëgjues në një adresë të vetme specifike e shpjegon refuzimin menjëherë. Nëse porta i përket një njësie socket dhe jo daemonit, konfigurimi i daemonit nuk është e gjithë historia.

Shtoni lidhjen dhe mbani atë të vjetër

OpenSSH pranon disa zëra ListenAddress, kështu që rruga VPN mund të mbetet ndërsa shtohet ajo private. Testoni skedarin përpara se ta ringarkoni.

sshd -t
systemctl reload sshd

Një test konfigurimi i dështuar e lë daemonin në punë të paprekur, dhe pikërisht këtë dëshironi ndërsa jeni i lidhur përmes rrugës që po ndryshoni. Mbani zërin ekzistues, shtoni adresën e re lokale dhe konfirmoni që shërbimi ringarkohet pa e ndërprerë sesionin aktual. Në instalimet e aktivizuara nga socket, shtoni adresën në njësinë socket dhe ringarkoni atë njësi. Pastaj lexoni përsëri listën e dëgjuesve, sepse një lidhje që nuk u shfaq kurrë do të thotë se është ndryshuar komponenti i gabuar.

Verifikoni sesionin e re përpara se të mbyllni atë të vjetër

Lidhuni me adresën e re ndërsa sesioni origjinal është ende i hapur, duke përdorur dalje të detajuar për të parë cilën adresë dhe çelës u përdorën. Mbani sesionin origjinal të hapur derisa testi të ketë sukses dy herë.

ssh -v [email protected]

Lexoni rreshtat e korrigjimit për adresën e destinacionit dhe çelësin e hostit të paraqitur. Konfirmoni gjurmën e gishtit të çelësit të hostit kundrejt një vlere që tashmë i besoni, në vend që të pranoni një çelës të panjohur sepse rrjeti përshkruhet si privat. Destinacioni i re ka nevojë për zërin e vet known_hosts, dhe kjo pritet. Sesioni i vjetër i administrimit duhet të mbyllet vetëm pasi rruga private të funksionojë.

SSH mbron transportin, por nuk i bën dy rrjete ekuivalente më vete. Vendosni nëse besimi i tranzitit privat përputhet me të dhënat përpara se të mbështeteni tek ai.