Millist rakenduse liiklust SSH-edastus tegelikult kannab?

Kest, kohalik edastus, SOCKS ja tunneliseadme režiim pakuvad erinevaid liideseid. Nimetage see, mida teie rakendus saab kasutada, enne kui võrdlete seda marsruuditud VPN-iga.

Terminal ühendub, viip ilmub ja kõik nõustuvad, et SSH juurdepääs töötab. Seejärel ei saa sülearvuti andmebaasiklient endiselt privaatset hosti kätte ja süüdistatakse seanssi. Ehitatud oli kest, mis on üks neljast üsna erinevast liidesest, mida SSH pakkuda suudab. Nimetage esmalt liides ja seejärel kontrollige, et rakendus seda tõesti kasutab. Järjekord on oluline, sest iga liides ebaõnnestub omal moel.

Nimetage liides enne, kui midagi võrdlete

OpenSSH kliendi käsiraamat eristab nelja mehhanismi, mida on lihtne segi ajada. Kest või kaugkäsk täidetakse SSH hostil. Kohalik edastus avab kliendil kuulava sokli ja teeb edasise ühenduse kaugemalt poolt. Kaugedastus teeb vastupidist, kuulates serveri poolel. Dünaamiline edastus pakub SOCKS-i lõpp-punkti programmidele, mis oskavad seda kasutada.

  • Kest: programm töötab kaugmasinal, kohapeal ei kuula miski.
  • Kohalik edastus: teie sülearvutil on port, kaugem host teeb väljuva ühenduse.
  • Kaugedastus: kaugemal poolel on port, liiklus tuleb tagasi teie poole.
  • Dünaamiline: SOCKS-proksü kliendil, mida kasutavad ainult proksiteadlikud rakendused.

Ükski neist ei paigalda marsruuti. Programm, mis eirab proksiseadeid, või räägib UDP-d, või lahendab nimesid ise, ei mõjuta aktiivne SSH seanss. See ei ole SSH viga; see on teie valitud liidese ulatus.

Kohalik, kaug- ja dünaamiline edastus erinevad selle poolest, kes kuulab

Erinevus, mis otsustab enamiku juhtumite, on see, kellele kuulub kuulav sokkel. Kohaliku edastuse puhul kuulab klient ja kaugem ots valib sihtkoha, seepärast lahendatakse sihtkoha aadress serveri vaatepunktist. Kaugedastuse puhul kuulab server ja ühendus kantakse tagasi teie poole, ja nii paljastate kohaliku teenuse ilma seda otse avaldamata.

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

Esimene käsk seob sülearvutil pordi 5432 ja edastab selle andmebaasile nii, nagu seda bastionist nähakse. Teine loob SOCKS-proksü pordil 1080. Kolmas käsk kinnitab, millised protsessid tegelikult kuulavad, ja see on ainus tõestus, et edastus on olemas, mitte ei ebaõnnestunud vaikselt pordikonflikti tõttu.

Dünaamiline edastus väärib oma hoiatust: see katab ainult rakendusi, mis austavad SOCKS-i. Brauseri saab sellele suunata, käsureatööriistale saab öelda, et see seda kasutaks, kuid andmebaasidraiver oma ühenduspaketiga tavaliselt ei saa. Eeldus, et iga programm masinas kasutab nüüd tunnelit, on kõige levinum viga kogu selles valdkonnas.

Tunneliseadme režiim on ainus tõeline võrguerand

OpenSSH toetab ka -w tunneliseadme edastust, mis annab edasi punkt-punkti liidese, mitte TCP kuulaja. See on tõeline võrgust tunnel ja see seatakse teadlikult, mitte kesta avamise kõrvalmõjuna.

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

See nõuab vastavaid liidesenumbreid mõlemas otsas, õiget seadistust serveris ja piisavat õigust kliendis seadme loomiseks. See nõuab ka adresseerimis- ja marsruutimisplaani, sest paljas liides ei kanna poliitikat selle kohta, millised sihtkohad peaksid seda kasutama.

Isegi siis lõpeb tunnel kaugemal hostil. Missuguse kaitse SSH transport pakkus, see lõpeb seal, ja edasine ühendus on eraldi hüpe. VPN-lüüsil on sama kuju piir, seepärast peaks võrdlus olema ulatuse ja lõppemise kohta, mitte selle kohta, milline tööriist on tugevam. Selle piiri valjusti nimetamine lahendab ka vaidluse, kas tunnel «krüpteerib kõike», sest ilmselgelt ei tee ta seda.

Kontrollige, et teie rakendus kasutab liidest, mille te ehitasite

Kontroll toimub rakenduse, mitte seansi kaupa. Töötav edastus tõestab, et port on seotud ja kaugem pool saab valida; see ei tõesta, et teile oluline programm ühendus selle kaudu.

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'

Esimene käsk saadab päringu SOCKS-i lõpp-punkti kaudu, kusjuures hostinimi lahendatakse kaugelt, ja teine proovib edastatud andmebaasiporti, kus TLS on endiselt nõutav. Käivitage samad testid peatatud edastusega, et kinnitada, et need ebaõnnestuvad, sest test, mis läbib mõlemal viisil, ei kasutanud tunnelit kunagi.

Seejärel võrrelge marsruuditud VPN-iga ainult neis mõõtmetes, mis loevad: millised sihtkohad on kaetud, millised protokollid töötavad, kus kaitse lõpeb ja kes peab juurdepääsu kinnitama. Ühe teenuse edastus võib olla kitsam ja parem vastus, samas kui VPN on õige kuju, kui paljud rakendused vajavad sama võrguteed. Kumbki ei anna kõike, mis on kättesaadav selle kaugemast lõpp-punktist.

Seotud artiklid