SSH tra dua privata vojo dum la VPN restas aktiva

Unu maŝino atingas alian tra VPN, kaj nun iu volas la saman ŝelon tra privata reto de provizanto. La vojo ekzistas, la ping sukcesas, kaj SSH tamen rifuzas. La kutima kaŭzo estas, ke la demono neniam aŭskultis sur la nova adreso, do mankas io, al kio konektiĝi. Ĉi tio estas problemo de adres-ligado antaŭ ol ĝi estas problemo de fajroŝirmilo.

Kial nova vojo ne kreas novan aŭskultanton

Aŭskultan soketon kreas procezo, kiu nomas la adresojn, kiujn ĝi akceptos. Vojo nur diras al pakaĵoj, kien ili vojaĝu; ĝi ne kreas aŭskultanton ĉe la celo. Kiam sshd estas agordita kun sola ListenAddress, konektoj al iu ajn alia loka adreso estas rifuzataj eĉ se la interfaco estas aktiva. La samo validas por soketa unuo, kiu posedas la pordon, kaj tial la unua kontrolo ĉiam estas, kio efektive aŭskultas.

Komparu la du vojojn laŭ la cela adreso, ne laŭ la nomo de la interfaco. Kliento konektiĝas al adreso, kaj tiu adreso devas esti ligita antaŭ ol iu ajn fajroŝirmila regulo gravas.

Listigu la adresojn kaj la aŭskultantojn

Antaŭ ol redakti ion ajn, notu la adresojn sur la gastiganto kaj la soketojn, kiuj ekzistas nun.

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

La adreslisto montras, kiu privata adreso estas reala kaj sur kiu interfaco, dum la soketlisto montras, ĉu io estas ligita al ĝi. Aŭskultanto sur 0.0.0.0:22 jam akceptas ĉiun adreson, do nova ligo aldonas nenion. Aŭskultanto sur unu specifa adreso tuj klarigas la rifuzon. Se la pordo apartenas al soketa unuo anstataŭ al la demono, la agordo de la demono ne estas la tuta rakonto.

Aldonu la ligon kaj konservu la malnovan

OpenSSH akceptas plurajn ListenAddress-erojn, do la VPN-vojo povas resti dum la privata aldoniĝas. Testu la dosieron antaŭ ol reŝargi ĝin.

sshd -t
systemctl reload sshd

Malsukcesa agorda testo lasas la kurantan demonon netuŝita, kaj tion vi ĝuste volas dum vi estas konektita tra la vojo, kiun vi redaktas. Konservu la ekzistantan eron, aldonu la novan lokan adreson kaj konfirmu, ke la servo reŝarĝiĝas sen perdi la nunan seancon. Ĉe soket-aktivigitaj instaloj aldonu la adreson anstataŭe al la soketa unuo kaj reŝargu tiun unuon. Poste relegu la aŭskultantliston, ĉar ligo, kiu neniam aperis, signifas, ke oni redaktis la malĝustan komponanton.

Kontrolu la novan seancon antaŭ ol fermi la malnovan

Konektiĝu al la nova adreso dum la origina seanco estas ankoraŭ malfermita, uzante detaleman eligon por vidi, kiun adreson kaj kiun ŝlosilon oni uzis. Konservu la originan seancon malfermita ĝis la provo sukcesos dufoje.

ssh -v [email protected]

Legu la sencimigajn liniojn pri la cela adreso kaj la prezentita gastiganta ŝlosilo. Konfirmu la fingrospuron de la gastiganta ŝlosilo kontraŭ valoro, kiun vi jam fidas, anstataŭ akcepti nekonatan ŝlosilon ĉar la reto estas priskribita kiel privata. La nova celo bezonas propran known_hosts-eron, kaj tio estas atendita. Nur post kiam la privata vojo funkcias, la malnova administra seanco fermiĝu.

SSH protektas la transporton, sed ĝi ne igas du retojn ekvivalentaj per si mem. Decidu, ĉu la fido de la privata trairo kongruas kun la datumoj, antaŭ ol fidi ĝin.