Kateri promet aplikacij v resnici prenaša posredovanje SSH?

Lupina, lokalno posredovanje, SOCKS in način tunelske naprave ponujajo različne vmesnike. Poimenujte tistega, ki ga lahko uporabi vaša aplikacija, preden ga primerjate z usmerjenim VPN.

Terminal se poveže, poziv se prikaže in vsi se strinjajo, da dostop SSH deluje. Nato odjemalec podatkovne zbirke na prenosniku še vedno ne doseže zasebnega gostitelja in seja je kriva. Kar je bilo zgrajeno, je bila lupina, in to je eden od štirih precej različnih vmesnikov, ki jih lahko ponudi SSH. Najprej poimenujte vmesnik, nato preizkusite, ali aplikacija res uporablja prav tega. Vrstni red je pomemben, ker vsak vmesnik odpove na svoj način.

Poimenujte vmesnik, preden karkoli primerjate

priročnik odjemalca OpenSSH razlikuje štiri mehanizme, ki jih je lahko zamenjati. Lupina ali oddaljeni ukaz se izvaja na gostitelju SSH. Lokalno posredovanje odpre vtičnico, ki posluša na odjemalcu, in nadaljnjo povezavo vzpostavi z oddaljene strani. Oddaljeno posredovanje naredi obratno in posluša na strani strežnika. Dinamično posredovanje izpostavi končno točko SOCKS programom, ki jo znajo uporabljati.

  • Lupina: program teče na oddaljenem stroju, lokalno nič ne posluša.
  • Lokalno posredovanje: vaš prenosnik ima vrata, oddaljeni gostitelj vzpostavi odhodno povezavo.
  • Oddaljeno posredovanje: oddaljena stran ima vrata, promet se vrača proti vam.
  • Dinamično: posrednik SOCKS na odjemalcu, uporabljajo ga le aplikacije, ki ga razumejo.

Nobeno od tega ne namesti poti. Program, ki ignorira nastavitve posrednika, ali govori UDP, ali sam razrešuje imena, ni prizadet z aktivno sejo SSH. To ni napaka v SSH; to je obseg vmesnika, ki ste ga izbrali.

Lokalno, oddaljeno in dinamično posredovanje se razlikujejo po tem, kdo posluša

Razlika, ki odloči večino primerov, je, kdo ima v lasti poslušajočo vtičnico. Pri lokalnem posredovanju posluša odjemalec in oddaljeni konec pokliče cilj, zato se naslov cilja razreši z vidika strežnika. Pri oddaljenem posredovanju posluša strežnik in povezava se prenese nazaj na vašo stran, in tako izpostavite lokalno storitev, ne da bi jo neposredno objavili.

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

Prvi ukaz veže vrata 5432 na prenosniku in jih posreduje v podatkovno zbirko, kot je vidna z bastiona. Drugi ustvari posrednika SOCKS na vratih 1080. Tretji ukaz potrdi, kateri procesi v resnici poslušajo, in to je edini dokaz, da posredovanje obstaja, namesto da bi tiho spodletelo zaradi spora vrat.

Dinamično posredovanje si zasluži lastno opozorilo: pokriva le aplikacije, ki spoštujejo SOCKS. Brskalnik je mogoče usmeriti nanj, orodju ukazne vrstice je mogoče reči, naj ga uporablja, gonilnik podatkovne zbirke z lastnim skladom povezav pa tega običajno ne more. Domneva, da vsak program na stroju zdaj uporablja tunel, je najpogostejša napaka na celem tem področju.

Način tunelske naprave je edina resnična omrežna izjema

OpenSSH podpira tudi posredovanje tunelske naprave -w, ki prepušča vmesnik od točke do točke namesto poslušalca TCP. To je resničen omrežni tunel in se konfigurira namerno, ni stranski učinek odpiranja lupine.

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

Potrebuje ustrezne številke vmesnikov, ki so na voljo na obeh koncih, pravilno konfiguracijo na strežniku in dovolj pravic na odjemalcu za ustvarjanje naprave. Potrebuje tudi načrt naslavljanja in usmerjanja, ker goli vmesnik ne nosi nobene politike o tem, kateri cilji naj ga uporabljajo.

Tudi takrat se tunel konča na oddaljenem gostitelju. Kakršna koli zaščita, ki jo je zagotovil transport SSH, se tam konča, nadaljnja povezava pa je ločen skok. Prehod VPN ima enako obliko meje, zato bi morala primerjava biti o obsegu in koncu, ne o tem, katero orodje je močnejše. Če to mejo izgovorimo na glas, razrešimo tudi spor o tem, ali tunel «šifrira vse», ker očitno ne.

Preizkusite, da vaša aplikacija uporablja vmesnik, ki ste ga zgradili

Preverjanje je za vsako aplikacijo, ne za sejo. Delujoče posredovanje dokazuje, da so vrata vezana in da oddaljena stran lahko pokliče; ne dokazuje, da se je program, ki vam je pomemben, povezal skozi njega.

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'

Prvi ukaz pošlje zahtevo skozi končno točko SOCKS z imenom gostitelja, razrešenim na daljavo, drugi pa preizkusi posredovana vrata podatkovne zbirke, pri čemer je TLS še vedno zahtevan. Zaženite iste preizkuse z ustavljenim posredovanjem, da potrdite, da spodletijo, ker preizkus, ki uspe na oba načina, tunela ni nikoli uporabil.

Nato primerjajte z usmerjenim VPN le v razsežnostih, ki so pomembne: kateri cilji so pokriti, kateri protokoli delujejo, kje se zaščita konča in kdo mora odobriti dostop. Posredovanje ene storitve je lahko ožji in boljši odgovor, medtem ko je VPN prava oblika, ko veliko aplikacij potrebuje isto omrežno pot. Nobeno od obeh ne daje vsega, kar je dosegljivo z njegove oddaljene končne točke.

Sorodni članki