Mitä sovellusliikennettä SSH-edelleenohjaus itse asiassa kuljettaa?

Pääte yhdistää, kehote ilmestyy ja kaikki ovat yhtä mieltä siitä, että SSH-yhteys toimii. Sitten kannettavan tietokoneen tietokanta-asiakasohjelma ei edelleenkään tavoita yksityistä isäntää, ja istuntoa syytetään. Se, mitä rakennettiin, oli kuori, ja se on yksi neljästä melko erilaisesta rajapinnasta, joita SSH voi tarjota. Nimeä rajapinta ensin ja testaa sitten, että sovellus todella käyttää sitä. Järjestys on tärkeä, koska jokainen rajapinta epäonnistuu omalla tavallaan.

Nimeä rajapinta ennen kuin vertaat mitään

OpenSSH-asiakasohjelman käsikirja erottaa neljä mekanismia, jotka on helppo sekoittaa. Kuori tai etäkomento suoritetaan SSH-isännällä. Paikallinen edelleenohjaus avaa kuuntelevan pistokkeen asiakasohjelmassa ja tekee jatkoyhteyden etäpuolelta. Etäedelleenohjaus tekee päinvastoin ja kuuntelee palvelinpuolella. Dynaaminen edelleenohjaus tarjoaa SOCKS-päätepisteen ohjelmille, jotka osaavat käyttää sitä.

• Kuori: ohjelma suoritetaan etäkoneella, mikään ei kuuntele paikallisesti.
• Paikallinen edelleenohjaus: kannettavassasi on portti, etäisäntä tekee lähtevän yhteyden.
• Etäedelleenohjaus: etäpuolella on portti, liikenne palaa sinua kohti.
• Dynaaminen: SOCKS-välityspalvelin asiakasohjelmassa, jota käyttävät vain välityspalvelimen ymmärtävät sovellukset.

Mikään näistä ei asenna reittiä. Ohjelma, joka jättää välityspalvelinasetukset huomiotta, puhuu UDP:tä tai selvittää nimet itse, ei ole aktiivisen SSH-istunnon vaikutuksen alainen. Se ei ole SSH:n virhe; se on valitsemasi rajapinnan laajuus.

Paikallinen, etä- ja dynaaminen edelleenohjaus eroavat siinä, kuka kuuntelee

Useimmat tapaukset ratkaiseva ero on se, kuka omistaa kuuntelevan pistokkeen. Paikallisessa edelleenohjauksessa asiakasohjelma kuuntelee ja etäpää valitsee kohteen, minkä vuoksi kohdeosoite selvitetään palvelimen näkökulmasta. Etäedelleenohjauksessa palvelin kuuntelee ja yhteys kuljetetaan takaisin sinun puolellesi, ja näin paljastat paikallisen palvelun julkaisematta sitä suoraan.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Ensimmäinen komento sitoo portin 5432 kannettavaan ja edelleenohjaa sen tietokantaan sellaisena kuin se näkyy bastionista. Toinen luo SOCKS-välityspalvelimen porttiin 1080. Kolmas komento vahvistaa, mitkä prosessit todella kuuntelevat, ja se on ainoa todiste siitä, että edelleenohjaus on olemassa sen sijaan että se olisi epäonnistunut hiljaisesti porttiristiriidan takia.

Dynaaminen edelleenohjaus ansaitsee oman varoituksensa: se kattaa vain sovellukset, jotka kunnioittavat SOCKS:ia. Selain voidaan ohjata siihen, komentorivityökalulle voidaan sanoa, että se käyttää sitä, mutta tietokanta-ajuri, jolla on oma yhteyspino, ei yleensä voi. Oletus, että jokainen koneen ohjelma käyttää nyt tunnelia, on yleisin virhe koko tällä alueella.

Tunnelilaitetila on ainoa todellinen verkkopoikkeus

OpenSSH tukee myös -w tunnelilaitteen edelleenohjausta, joka välittää pistevälisen rajapinnan TCP-kuuntelijan sijaan. Se on todellinen verkkotunneli, ja se määritetään tarkoituksella, ei kuoren avaamisen sivuvaikutuksena.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Se tarvitsee vastaavat rajapintanumerot molemmissa päissä, oikean kokoonpanon palvelimella ja riittävän oikeuden asiakasohjelmassa laitteen luomiseksi. Se tarvitsee myös osoite- ja reitityssuunnitelman, koska paljas rajapinta ei kanna käytäntöä siitä, mitkä kohteet sitä käyttävät.

Silloinkin tunneli päättyy etäisäntään. Mikä tahansa suojaus, jonka SSH-siirto tarjosi, päättyy siihen, ja jatkoyhteys on erillinen hyppy. VPN-portilla on saman muotoinen raja, minkä vuoksi vertailun pitäisi koskea laajuutta ja päättymistä eikä sitä, mikä työkalu on vahvempi. Tuon rajan ääneen nimeäminen ratkaisee myös väittelyn siitä, salaako tunneli kaiken, koska selvästikään se ei salaa.

Testaa, että sovelluksesi käyttää rakentamaasi rajapintaa

Varmennus tehdään sovelluskohtaisesti, ei istuntokohtaisesti. Toimiva edelleenohjaus todistaa, että portti on sidottu ja etäpuoli voi valita; se ei todista, että sinulle tärkeä ohjelma yhdisti sen kautta.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Ensimmäinen komento lähettää pyynnön SOCKS-päätepisteen kautta isäntänimi etänä selvitettynä, ja toinen harjoittaa edelleenohjattua tietokantaporttia TLS:n ollessa edelleen vaadittu. Aja samat testit edelleenohjaus pysäytettynä varmistaaksesi, että ne epäonnistuvat, koska testi, joka menee läpi molemmilla tavoilla, ei koskaan käyttänyt tunnelia.

Vertaa sitten reititettyyn VPN:ään vain niissä ulottuvuuksissa, joilla on merkitystä: mitkä kohteet katetaan, mitkä protokollat toimivat, mihin suojaus päättyy ja kenen on hyväksyttävä pääsy. Yhden palvelun edelleenohjaus voi olla kapeampi ja parempi vastaus, kun taas VPN on oikea muoto, kun moni sovellus tarvitsee saman verkkopolun. Kumpikaan ei myönnä kaikkea, mitä sen etäpäästä on tavoitettavissa.