SSH sa pangalawang pribadong landas habang nananatiling aktibo ang VPN

Naabot ng isang makina ang isa pa sa pamamagitan ng VPN, at ngayon may gustong makuha ang parehong shell sa pribadong network ng provider. Umiiral ang ruta, nagtagumpay ang ping, ngunit tumatanggi pa rin ang SSH. Ang karaniwang dahilan ay hindi kailanman nakinig ang daemon sa bagong address, kaya walang mapagkakabit. Ito ay problema sa pagtali ng address bago maging problema sa firewall.

Bakit ang bagong ruta ay hindi gumagawa ng bagong listener

Ang nakikinig na socket ay ginagawa ng isang prosesong nagpapangalan ng mga address na tatanggapin nito. Sinasabi lamang ng ruta sa mga packet kung saan sila pupunta; hindi ito gumagawa ng listener sa destinasyon. Kapag ang sshd ay naka-configure na may isang ListenAddress, ang mga koneksyon sa anumang ibang lokal na address ay tinatanggihan kahit aktibo ang interface. Ganoon din sa socket unit na nagmamay-ari ng port, kaya ang unang pagsusuri ay palaging kung ano talaga ang nakikinig.

Ihambing ang dalawang landas ayon sa destinasyong address, hindi sa pangalan ng interface. Kumokonekta ang client sa isang address, at ang address na iyon ay dapat nakatali bago maging mahalaga ang anumang firewall rule.

Ilista ang mga address at listener

Bago baguhin ang anuman, itala ang mga address sa host at ang mga socket na umiiral ngayon.

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

Ipinapakita ng listahan ng address kung aling pribadong address ang tunay at sa aling interface, habang ipinapakita ng listahan ng socket kung may nakatali rito. Ang listener sa 0.0.0.0:22 ay tumatanggap na ng bawat address, kaya walang idinadagdag ang bagong binding. Ang listener sa isang partikular na address ay agad na nagpapaliwanag ng pagtanggi. Kung ang port ay pag-aari ng socket unit at hindi ng daemon, ang configuration ng daemon ay hindi ang buong kuwento.

Idagdag ang binding at panatilihin ang luma

Tumatanggap ang OpenSSH ng maraming ListenAddress entry, kaya maaaring manatili ang VPN path habang idinadagdag ang pribado. Subukan ang file bago ito i-reload.

sshd -t
systemctl reload sshd

Ang nabigong configuration test ay iniiwan ang tumatakbong daemon na hindi ginalaw, at iyon ang eksaktong kailangan mo habang konektado sa landas na ine-edit mo. Panatilihin ang umiiral na entry, idagdag ang bagong lokal na address, at kumpirmahin na nag-reload ang serbisyo nang hindi pinuputol ang kasalukuyang session. Sa mga installation na naka-activate sa socket, idagdag ang address sa socket unit sa halip at i-reload ang unit na iyon. Pagkatapos ay basahin muli ang listahan ng listener, dahil ang binding na hindi kailanman lumitaw ay nangangahulugang maling bahagi ang na-edit.

I-verify ang bagong session bago isara ang luma

Kumonekta sa bagong address habang bukas pa ang orihinal na session, gamit ang detalyadong output upang makita kung aling address at key ang ginamit. Panatilihing bukas ang orihinal na session hanggang magtagumpay nang dalawang beses ang pagsubok.

ssh -v [email protected]

Basahin ang mga debug na linya para sa destinasyong address at ang iniharap na host key. Kumpirmahin ang fingerprint ng host key laban sa isang value na pinagkakatiwalaan mo na, sa halip na tanggapin ang hindi kilalang key dahil inilarawan ang network bilang pribado. Kailangan ng bagong destinasyon ang sarili nitong known_hosts entry, at inaasahan iyon. Dapat lang isara ang lumang management session kapag gumagana na ang pribadong landas.

Pinoprotektahan ng SSH ang transport, ngunit hindi nito ginagawang pantay ang dalawang network nang mag-isa. Magpasya kung tugma ang pagtitiwala ng pribadong transit sa data bago umasa dito.