SSH-paikallinen edelleenohjaus olemassa olevaan HTTP-välityspalvelimeen: kaksi loopback-osoitetta
SSH-isännässä oleva välityspalvelin voi palvella yhtä sovellusta yhdellä paikallisella edelleenohjauksella. Pidä kaksi loopback-osoitetta ja välityspalvelimen protokolla erillään.
Hyväksytty välityspalvelimesi toimii hyppyisännässä, jossa se kuuntelee vain loopbackissa, joten mikään kyseisen koneen ulkopuolella ei pääse siihen. Et tarvitse VPN:ää tai uutta välityspalvelinta; tarvitset yhden portin siitä koneesta siirrettynä yhdelle omalle portillesi. Paikallinen edelleenohjaus tekee juuri sen, ja se vaatii yhden komennon sekä yhden sovellusasetuksen. Sekaannus syntyy yleensä siitä, että sekoitetaan, mikä loopback-osoite kuuluu millekin koneelle.
Päätä, onko kiinteä välityspalvelin jo olemassa
Tämä tekniikka ohjaa edelleen palvelua, joka on jo käynnissä. Jos etäkoneessa on vain SSH-demoni eikä välityspalvelinta, mikään määrä edelleenohjausta ei luo sellaista, ja yhteys hylätään etäpäästä. Varmista, että välityspalvelin on sidottu, mikä sen portti on ja kuunteleeko se osoitteessa 127.0.0.1 vai tietyllä liitännän osoitteella, koska juuri se osoite on edelleenohjauksen kohde.
Kun varmistat tämän ensin, säästyt sellaisen tunnelin vianetsinnältä, jota ei koskaan yhdistetty mihinkään.
Rakenna edelleenohjaus ja lue komento
Haluamasi muoto sitoo kannettavan tietokoneesi loopback-portin ja yhdistää sen palvelimen puolelta välityspalvelimen osoitteeseen sellaisena kuin palvelin sen näkee.
ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
-L 127.0.0.1:13128:127.0.0.1:3128 [email protected]-N vaimentaa etäkomennon ja -T vaimentaa termios-määrityksen, koska haluat tunnelin etkä kuorta. Ensimmäinen loopback-osoite on se, jossa kannettava kuuntelee; toisen ratkaisee SSH-palvelin, joten 127.0.0.1 siellä tarkoittaa kyseisen koneen välityspalvelinta. ExitOnForwardFailure saa komennon epäonnistumaan äänekkäästi, jos paikallinen portti on jo varattu, sen sijaan että aloitettaisiin istunto, joka ei ohjaa mitään. Kirjoita kohdeosoite niin kuin palvelin sen ratkaisee, koska nimi, jonka vain kannettavasi pystyy ratkaisemaan, epäonnistuu toisella puolella.
Palvelimen oma käytäntö pätee ennen kuin mikään tästä toimii. AllowTcpForwarding on sallittava se, ja PermitOpen voi rajoittaa, mihin kohteisiin ja portteihin istunto voi päästä, joten palvelin voi silti hylätä edelleenohjauksen, jonka asiakas hyväksyy. Hylkäys näkyy asiakkaassa edelleenohjaus- tai kanavavirheenä, ja tuon viestin lukeminen on nopeampaa kuin komennon muokkaaminen.
Kohdista yksi sovellus edelleenohjaukseen
Määritä sovellus käyttämään HTTP-välityspalvelinta osoitteessa http://127.0.0.1:13128, tunnistetietoineen jos etävälityspalvelin vaatii ne. Säilytä sovelluksen oma varmennevahvistus HTTPS-kohteille, sillä välityspalvelimen tunneli ei korvaa sitä. Tämä on yhden palvelun kiinteä edelleenohjaus, joten sovellukselle on kerrottava välityspalvelimesta sen sijaan, että se jätettäisiin löytämään sellainen itse.
Nopea tarkistus ennen mitään pysyvää määritystä: curl -x http://127.0.0.1:13128 -I https://example.com, joka harjoittaa HTTP CONNECT -menetelmää, jota välityspalvelimen on tuettava.
Pidä valta siellä, missä se oli
Etävälityspalvelin päättää edelleen, mitkä kohteet ja menetelmät se sallii, eikä SSH-kirjautumisen pitäisi hiljaa antaa jokaiselle tilille yleistä verkkoreleettä. Sitominen 127.0.0.1:een kannettavassa välttää portin julkaisemisen paikallisverkkoosi, eikä se tee portista yksityistä saman koneen muilta prosesseilta. Tuon sidonnan korvaaminen jokerimerkkiosoitteella välityspalvelimen jakamiseksi on tapa, jolla hallitsematon avoin relee syntyy.
SSH-siirto suojaa hypyn palvelimelle. Sen jälkeen välityspalvelin avaa oman yhteytensä, joten tavallinen HTTP-pyyntö kohteeseen pysyy tavallisena palvelimen jälkeenkin, vaikka ensimmäinen osuus oli salattu.
Vahvista molemmat päät ja siivoa sitten
Paikallisen tunnelin pystytys ja etäpalvelun onnistuminen ovat eri tuloksia, ja komennon poistumistila kertoo vain ensimmäisestä. Tarkista, että kuuntelija on olemassa komennolla ss -ltn, ja tee sitten sallittu sovelluspyyntö ja pyyntö, jonka välityspalvelimen pitäisi hylätä. Jos molemmat käyttäytyvät odotetusti, polku on todellinen; jos tunneli on pystyssä ja jokainen pyyntö epäonnistuu, välityspalvelin hylkää tai ei tavoita kohdetta.
Kun lopetat, pysäytä sen omistava SSH-prosessi, poista välityspalvelinasetus sovelluksesta ja varmista, että paikallinen portti on poissa, sen sijaan että jättäisit kuuntelijan, joka elää tehtävää pidempään.