Remote na SSH sa VPN: ang hindi ginagawa ng tunnel
Ginagawang maabot ng VPN ang isang SSH server at wala nang iba pa. Tatlong kondisyon ang nagpapasya kung angkop ito, at ang yugto ng pagpalya ang nagsasabi kung aling layer ang may kasalanan.
Binibigyan ng VPN ang isang SSH server ng pribadong landas at inaalis ang pangangailangan ng pampublikong tagapakinig sa port 22. Hindi nito pinapatunayan ang host, hindi nito awtorisado ang user, at hindi nito pinapasya kung aling mga account ang makakapasok. Trabaho pa rin iyon ng SSH. Kung ang VPN ang tamang paraan para marating ang server ay nakasalalay sa tatlong kondisyon, at ang tunnel ay isa lamang sa mga posibleng sagot.
Ano ang binabago ng tunnel at ano ang pinapasya pa rin ng SSH
Binabago ng tunnel ang maabot: aling mga address ang maaaring marating, at mula saan. Hindi nito binabago ang nangyayari pagkatapos ng koneksyong TCP, kung saan ipinapakita ng server ang host key at humihingi ng pagkakakilanlan ng user.
Panatilihing hiwalay ang dalawang layer sa isip mo at sa dokumentasyon. Ang pag-login sa VPN ay nagpapatunay kung sino ang maaaring gumamit ng network. Wala itong sinasabi tungkol sa kung aling mga account ang umiiral sa target, at hindi ito pahintulot na pumasok sa bawat maabot na makina.
Hiwalay din ang mga paraan ng pagpalya, at iyon ang dahilan kung bakit kapaki-pakinabang ang paghihiwalay sa panahon ng insidente.
Tatlong kondisyon na nagpapasya sa modelo ng pag-access
Una, kailangan bang maabot ang server ng mga taong nasa labas ng iyong network? Kung hindi, ang pribadong landas kasama ang isang bastion o isang mesh ang mas maliit na disenyo. Ikalawa, kayang patakbuhin ng populasyon ng kliyente ang kliyente ng VPN, kasama ang mga nasa pinamamahalaang aparato na may mga paghihigpit?
Ikatlo, kailangan mo ba ng kontrol kada serbisyo o kada user? Ang VPN ay nagbibigay ng abot ng network; ang SSH ay nagbibigay ng access sa account. Kung ang pangangailangan ay maabot ng isang kontratista ang isang host at wala nang iba, iyon ay pangangailangan sa awtorisasyon at ang tunnel lamang ay hindi ito maipapahayag.
Sagutin ang tatlong iyon at pipiliin ng modelo ang sarili nito. Laktawan mo ang mga iyon at magtatapos ka sa pampublikong paglalantad ng SSH para maiwasan ang pag-deploy ng kliyente.
Tiyakin ang pribadong landas bago sisihin ang SSH
Kumonekta sa aprubadong VPN at gamitin ang dokumentadong pribadong pangalan o address ng target. Pagkatapos ay suriin ang napiling ruta, ang pahintulot ng gateway at ang pabalik na landas patungo sa kliyente. Ang pangalang tamang nare-resolve ay hindi patunay na ang address ay dumadaan sa nilalayong tunnel, dahil ang magkapatong na lokal at malayong prefix ay maaaring magpadala ng kahilingan sa ibang lugar nang tuluyan. Sulit isulat ang pagkakaibang iyon sa runbook.
Kung hindi kailanman nangyari ang koneksyon, tiyakin na nakikinig ang server sa interface na inaasahan mo at pinapayagan ng firewall ng host ang source na aktwal nitong nakikita. Maaaring isulat muli ng NAT ng gateway ang source na iyon, kaya ang listahan ng pinapayagan na isinulat para sa address ng tunnel ng kliyente ay maaaring hindi kailanman tumugma.
Ang pagkakaibang iyon ang pinakakaraniwang SSH na pagpalya na dulot ng sarili sa ibabaw ng VPN.
Basahin ang yugto ng pagpalya, hindi ang pinagsamang error
Tatlong yugto ang gumagawa ng tatlong magkakaibang mensahe, at isa lamang sa kanila ang tungkol sa mga kredensyal.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
Gamitin ang eksaktong error at ang sariling log ng server sa halip na i-reset ang mga kredensyal ng VPN at SSH nang sabay. Ang pag-reset sa dalawa ay kung paano nagiging dalawang araw na insidente sa pagkakakilanlan ang limang minutong pagsusuri.
Ipinapakita ng detalyadong output kung aling yugto ang naabot mo:
ssh -vv [email protected]Panatilihing buo ang mga host key at awtorisasyon
Patunayan ang host key sa pamamagitan ng nilalayong pinagkakatiwalaang proseso, lalo na pagkatapos ng pagpapalit ng server. Ang hindi inaasahang babala ng nabagong key ay ang mensaheng hindi mo dapat balewalain dahil lang sa kumonekta ang VPN, dahil ang pribadong tunnel ay hindi ginagawang ang destinasyon ang makinang inaakala mo. Suriin ang fingerprint laban sa isang mapagkakatiwalaang source na independiyente sa koneksyon.
Sa panig ng server, tiyakin na awtorisado ang account at ang paraan ng pagpapatotoo na inayos mo ang siyang inaalok. Ang key na naroroon ngunit binabalewala ay karaniwang isyu ng pahintulot o konfigurasyon, hindi ng network.
Limitahan ang access sa serbisyo sa mga kinakailangang pagkakakilanlan at panatilihin ang awtorisadong landas ng pagbawi para sa mga pagbabago sa network.