SSH bigarren bide pribatu batetik VPN-a martxan dela

Makina batek bestea VPN bidez lortzen du, eta orain norbaitek shell bera nahi du hornitzailearen sare pribatu batetik. Ibilbidea badago, ping-ak arrakasta du, eta SSHk uko egiten jarraitzen du. Ohiko arrazoia da daemonak ez zuela sekula helbide berrian entzun, beraz ez dago ezer konektatzeko. Hau helbide-lotzearen arazoa da suebakiaren arazoa izan aurretik.

Zergatik ibilbide berri batek ez duen entzule berririk sortzen

Entzuten ari den socket bat prozesu batek sortzen du, eta prozesu horrek onartuko dituen helbideak izendatzen ditu. Ibilbideak paketeei nora joan behar duten bakarrik esaten die; ez du entzulerik sortzen helmugan. sshd ListenAddress bakarrarekin konfiguratuta dagoenean, beste edozein helbide lokaletarako konexioak ukatzen dira, interfazea martxan egon arren. Gauza bera gertatzen da portua duen socket unitate batekin, eta horregatik lehen egiaztapena beti da benetan zer ari den entzuten.

Konparatu bi bideak helmugako helbidearen arabera, ez interfazearen izenaren arabera. Bezero bat helbide batera konektatzen da, eta helbide hori lotuta egon behar da suebakiaren edozein arauk garrantzia izan aurretik.

Zerrendatu helbideak eta entzuleak

Ezer editatu aurretik, idatzi ostalariaren helbideak eta orain dauden socketak.

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

Helbide-zerrendak erakusten du zein den helbide pribatu erreala eta zein interfazetan, eta socket-zerrendak, berriz, ea zerbait lotuta dagoen. 0.0.0.0:22-eko entzule batek dagoeneko helbide guztiak onartzen ditu, beraz lotura berriak ez du ezer gehitzen. Helbide zehatz bateko entzule batek ukoa berehala azaltzen du. Portua daemonarena ez bada, socket unitate batena baizik, daemonaren konfigurazioa ez da istorio osoa.

Gehitu lotura eta mantendu zaharra

OpenSSHk hainbat ListenAddress sarrera onartzen ditu, beraz VPN bidea egon daiteke pribatua gehitzen den bitartean. Probatu fitxategia berriro kargatu aurretik.

sshd -t
systemctl reload sshd

Konfigurazio-proba huts batek martxan dagoen daemona ukitu gabe uzten du, eta horixe nahi duzu editatzen ari zaren bidetik konektatuta zauden bitartean. Mantendu lehendik dagoen sarrera, gehitu helbide lokal berria eta egiaztatu zerbitzua berriro kargatzen dela uneko saioa galdu gabe. Socket bidez aktibatutako instalazioetan, gehitu helbidea socket unitatera eta kargatu unitate hori berriro. Ondoren irakurri berriro entzuleen zerrenda, inoiz agertu ez den lotura batek osagai okerra editatu dela esan nahi baitu.

Egiaztatu saio berria zaharra itxi aurretik

Konektatu helbide berrira jatorrizko saioa oraindik irekita dagoela, eta erabili irteera zehaztua zein helbide eta gako erabili diren ikusteko. Mantendu jatorrizko saioa irekita probak bi aldiz arrakasta izan arte.

ssh -v [email protected]

Irakurri arazketa-lerroak helmugako helbideari eta aurkeztutako ostalari-gakoari buruz. Egiaztatu ostalari-gakoaren hatz-marka jada fidatzen zaren balio batekin, sare pribatua delako gako ezezaguna onartu beharrean. Helmuga berriak bere known_hosts sarrera behar du, eta hori espero da. Bide pribatuak funtzionatzen duenean soilik itxi beharko litzateke kudeaketa-saio zaharra.

SSHk garraioa babesten du, baina ez ditu bi sare baliokide egiten bere horretan. Erabaki trantsitu pribatuaren konfiantzak datuekin bat egiten duen horretan fidatu aurretik.