Maabot ang isang HTTPS site na available lang sa VPN sa pamamagitan ng SSH forward

May isang makina na may naaprubahang VPN access, ang ikalawang makina ay nangangailangan ng eksaktong isang pribadong HTTPS service, at ang isang lokal na SSH forward ay maaaring tumulay sa agwat na iyon nang hindi binibigyan ng tunnel ang ikalawang makina. Ang forward ay nagdadala ng isang TCP destinasyon sa halip na ang buong network, at ang limitasyong iyon mismo ang punto. Sundin ang limang hakbang sa ibaba nang sunod-sunod, dahil bawat isa ay nabibigo sa magkaibang dahilan at ang huling hakbang ay hindi kayang iligtas ang naunang agwat. Kung may kulang na paunang kondisyon, hindi ito nilulutas ng disenyong ito at walang pagsasaayos ng mga utos ang makakatulong.

Hakbang isa: kumpirmahin ang tatlong paunang kondisyon

Tatlong bagay ang dapat totoo na bago magkaroon ng kahulugan ang anumang utos. Kailangan mo ng pahintulot na gamitin ang unang makina bilang host ng forward, gumaganang SSH access dito, at patakaran ng server na nagpapahintulot sa nilalayong destinasyon. Ang isang SSH account na ginawa para sa paglilipat ng file ay maaaring may naka-disable na forward, at ang isang server na nagpapahintulot ng forward ay maaari pa ring limitahan kung aling mga destinasyon ang maabot sa pamamagitan nito. Magtanong bago mag-test, dahil ang paggamit ng workstation ng isang kasamahan bilang jump point nang walang kasunduan ay isang isyu sa patakaran, kahit gumagana nang maayos ang utos.

Dalawang utos ang tumatapos sa teknikal na kalahati ng listahang iyon. Ang una ay nagpapatunay na gumagana ang account at key nang walang interactive na prompt, at ang pangalawa ay nagpi-print ng aktwal na patakaran ng server sa halip na ang naka-comment na halimbawa sa configuration file.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Hakbang dalawa: i-bind ang isang loopback port at panatilihing buhay ang session

Sa makinang nagpapatakbo ng client application, magbukas ng lokal na forward patungo sa pribadong serbisyo. I-bind ito nang tahasan sa loopback upang hindi ito mailathala sa lokal na network, at pumili ng mataas na port na wala pang hawak na anumang lokal na serbisyo. Panatilihing tumatakbo ang session habang nagtatrabaho ka, dahil ang pagsasara nito ay isinasara ang listener. Ginagawang agarang paglabas ng ExitOnForwardFailure ang isang tinanggihang bind o okupadong port sa halip na isang session na nananatiling bukas nang walang forward, at iyon ang failure mode na pinakamaraming nasasayang na oras.

Ang pribadong koneksyon ay ginagawa mula sa jump host, kaya ang DNS, ruta, patakaran ng VPN at pag-access sa serbisyo ng host na iyon ay dapat gumana lahat. Ang SSH session ay hindi lumilikha ng maabot na wala ang jump host, at hindi nito kayang ayusin ang rutang hindi kailanman itinulak ng VPN. Kumpirmahin ang listener sa lugar kung saan ito talaga naroroon sa halip na umasa sa katahimikan ng utos.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Hakbang tatlo: panatilihin ang HTTPS name kapag lokal ang socket

Ang pag-browse sa https://127.0.0.1:9443/ ay nagbabago ng TLS server name at awtoridad ng application. Ang sertifikadong inisyu para sa portal.lab.example ay hindi mabe-validate laban sa isang loopback address, at ang resultang error ay mukhang sirang sertipiko sa halip na shortcut ng forward. Para sa pagsubok sa command line, panatilihin ang tunay na URL at baguhin lamang ang destinasyon ng socket. Iyon ang ginagawa ng --connect-to, at dokumentado ng manwal ng curl ang four-field form na ginagamit sa ibaba.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Ang pangalan ay nananatili sa URL, sa TLS handshake at sa Host header, habang ang TCP connection ay pumupunta sa lokal na listener. Ang opsyong walang proxy ay nagpapanatili ng pagsubok sa forward na ito sa halip na hayaang harangin ito ng naka-configure na HTTP proxy, at ang pagpapanatiling bukas ng certificate verification ang siyang gumagawa sa resulta na makabuluhan.

Hakbang apat: alamin kung ano ang hindi kayang saklawin ng isang forward

Ang isang TCP forward ay sumasaklaw sa isang destinasyong port. Ang isang pahinang nagre-redirect sa ikalawang hostname, naglo-load ng mga asset mula sa host sa loob ng pribadong network, o nagpapadala sa ibang port ay nangangailangan ng sarili nitong forward, at bawat isa sa kanila ay nangangailangan ng parehong pagsusuri ng patakaran tulad ng una. Ang mga workflow ng browser ay nagdaragdag ng sarili nilang mga pangangailangan, dahil kailangang sabihin sa browser na ipadala ang tunay na pangalan sa lokal na port sa pamamagitan ng proxy configuration o lokal na pagmamapa. Kaya ang isang matagumpay na pagsubok sa command line ay hindi nagpapatunay na magtatagumpay din ang browser, bagaman pinatutunayan nito ang landas.

Ang UDP, pagtuklas ng SMB at pag-sign in sa domain ay hindi dumadaan sa isang TCP forward. Kung ang tunay na pangangailangan ay pangkalahatang access sa network, ang disenyong ito ay maling kasangkapan at ang sinusuportahang remote-access gateway ang tama.

Hakbang lima: linisin at itala

Ihinto ang session kapag tapos na ang pagsubok at kumpirmahin na wala na ang listener. Kung ang napiling port ay okupado na, pumili ng isa pang hindi pa nagagamit na loopback port at i-update nang sabay ang URL, test command at tala, sa halip na ihinto ang isang walang kaugnayang lokal na serbisyo upang palayain ang numero. Ang pag-iiwan ng forward na bukas sa isang laptop ay ginagawang hindi pinamamahalaang serbisyo ang isang diagnosis.

Itala ang jump host, ang naipadalang destinasyon, ang lokal na port at kung sino ang nag-apruba ng kaayusan. Ang isang forward na umiiral lamang sa history ng shell ng isang tao ay isang restart ang layo mula sa paulit-ulit na imbestigasyon, at hindi malalaman ng susunod na tao kung alin sa tatlong paunang kondisyon ang nasuri na.