Aling trapiko ng app ang talagang dinadala ng isang SSH forward?

Kumokonekta ang terminal, lumilitaw ang prompt, at lahat ay sumasang-ayon na gumagana ang SSH access. Pagkatapos ay hindi pa rin maabot ng isang database client sa laptop ang pribadong host, at ang session ang sinisisi. Ang itinayo ay isang shell, at ito ay isa sa apat na lubos na magkakaibang interface na maaaring ialok ng SSH. Pangalanan muna ang interface, pagkatapos ay subukan na talagang ginagamit ito ng app. Mahalaga ang pagkakasunod-sunod, dahil bawat interface ay nabigo sa sarili nitong paraan.

Pangalanan ang interface bago ihambing ang anuman

manwal ng kliyente ng OpenSSH ay nagtatangi ng apat na mekanismong madaling mapagkamalan. Ang isang shell o malayong utos ay tumatakbo sa SSH host. Ang lokal na forward ay nagbubukas ng nakikinig na socket sa kliyente at ginagawa ang susunod na koneksyon mula sa malayong panig. Ang malayong forward ay gumagawa ng kabaligtaran, nakikinig sa panig ng server. Ang dynamic na forward ay naglalabas ng endpoint na SOCKS para sa mga programang marunong gumamit nito.

• Shell: tumatakbo ang programa sa malayong makina, walang nakikinig nang lokal.
• Lokal na forward: may port ang iyong laptop, ang malayong host ang gumagawa ng papuntang labas na koneksyon.
• Malayong forward: may port ang malayong panig, bumabalik sa iyo ang trapiko.
• Dynamic: isang proxy na SOCKS sa kliyente, ginagamit lamang ng mga app na nakakaunawa ng proxy.

Wala sa mga ito ang nag-iinstall ng ruta. Isang programang bale-wala sa mga setting ng proxy, o nagsasalita ng UDP, o nagreresolba ng mga pangalan nang mag-isa, ay hindi apektado ng aktibong session ng SSH. Hindi ito bug sa SSH; ito ang saklaw ng interface na pinili mo.

Ang lokal, malayo at dynamic na forward ay nagkakaiba sa kung sino ang nakikinig

Ang pagkakaibang nagpapasya sa karamihan ng kaso ay kung sino ang may-ari ng nakikinig na socket. Sa lokal na forward, ang kliyente ang nakikinig at ang malayong dulo ang nagda-dial ng destinasyon, kaya nga ang address ng destinasyon ay nireresolba mula sa pananaw ng server. Sa malayong forward, ang server ang nakikinig at ang koneksyon ay dinadala pabalik sa iyong panig, at ganoon mo inilalabas ang isang lokal na serbisyo nang hindi ito direktang inilalathala.

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

Ang unang utos ay nagbubuklod ng port 5432 sa laptop at nagfo-forward nito sa database ayon sa nakikita mula sa bastion. Ang pangalawa ay gumagawa ng proxy na SOCKS sa port 1080. Ang pangatlong utos ay nagpapatunay kung aling mga proseso ang talagang nakikinig, at iyon lamang ang patunay na umiiral ang forward sa halip na tahimik na nabigo dahil sa pagbangga ng port.

Ang dynamic na forward ay karapat-dapat sa sarili nitong babala: nasasaklaw lamang nito ang mga app na gumagalang sa SOCKS. Maaaring ituro ang browser dito, maaaring sabihan ang tool sa command line na gamitin ito, ngunit ang driver ng database na may sariling stack ng koneksyon ay karaniwang hindi kaya. Ang pag-aakalang ginagamit na ngayon ng bawat programa sa makina ang tunnel ay ang pinakakaraniwang pagkakamali sa buong larangang ito.

Ang tunnel-device mode ay ang tanging tunay na eksepsyon sa network

Sinusuportahan din ng OpenSSH ang forward na tunnel-device -w, na nagpapasa ng point-to-point na interface sa halip na TCP listener. Iyon ay tunay na tunnel ng network, at sadyang kinokonfigura ito, hindi side effect ng pagbukas ng shell.

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

Kailangan nito ang katumbas na mga numero ng interface na available sa magkabilang dulo, ang tamang konfigurasyon sa server, at sapat na pribilehiyo sa kliyente upang likhain ang device. Kailangan din nito ang plano sa pag-address at pagruruta, dahil ang hubad na interface ay walang dalang patakaran kung aling mga destinasyon ang dapat gumamit nito.

Kahit gayon, nagtatapos ang tunnel sa malayong host. Anumang proteksyong ibinigay ng transportasyon ng SSH ay nagtatapos doon, at ang susunod na koneksyon ay hiwalay na paglundag. Ang gateway ng VPN ay may parehong hugis ng hangganan, kaya ang paghahambing ay dapat tungkol sa saklaw at pagtatapos at hindi tungkol sa kung aling tool ang mas malakas. Ang pagsabi nang malakas sa hangganang iyon ay tumitiyak din sa pagtatalo kung «ini-encrypt ng tunnel ang lahat», dahil malinaw na hindi nito ginagawa.

Subukan na ginagamit ng iyong app ang interface na itinayo mo

Ang beripikasyon ay bawat app, hindi bawat session. Ang gumaganang forward ay nagpapatunay na nakabuklod ang port at kayang mag-dial ng malayong panig; hindi nito pinatutunayan na ang programang mahalaga sa iyo ay kumonekta sa pamamagitan nito.

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'

Ang unang utos ay nagpapadala ng kahilingan sa endpoint na SOCKS habang ang hostname ay nireresolba mula sa malayo, at ang pangalawa ay sumusubok sa na-forward na port ng database habang kailangan pa rin ang TLS. Patakbuhin ang parehong mga pagsubok na nakatigil ang forward upang kumpirmahing nabigo ang mga ito, dahil ang pagsubok na pumasa sa dalawang paraan ay hindi kailanman gumamit ng tunnel.

Pagkatapos ay ihambing sa routed VPN lamang sa mga dimensyong mahalaga: aling mga destinasyon ang saklaw, aling mga protocol ang gumagana, saan nagtatapos ang proteksyon, at sino ang dapat mag-apruba ng access. Ang forward para sa isang serbisyo ay maaaring ang mas makitid at mas mahusay na sagot, samantalang ang VPN ay ang tamang hugis kapag maraming app ang nangangailangan ng parehong landas ng network. Wala sa dalawa ang nagbibigay ng lahat ng maaabot mula sa malayong dulo nito.