Cili trafik aplikacioni bartet në të vërtetë nga një përcjellje SSH?

Terminali lidhet, prompti shfaqet dhe të gjithë bien dakord se aksesi SSH funksionon. Pastaj një klient i bazës së të dhënave në laptop ende nuk arrin te hosti privat, dhe sesioni fajësohet. Ajo që u ndërtua ishte një shell, dhe ai është një nga katër ndërfaqet mjaft të ndryshme që SSH mund të ofrojë. Emërtoni së pari ndërfaqen, pastaj provoni që aplikacioni vërtet e përdor atë. Rendi ka rëndësi, sepse çdo ndërfaqe dështon në mënyrën e vet.

Emërtoni ndërfaqen përpara se të krahasoni çdo gjë

manualin e klientit OpenSSH dallon katër mekanizma që ngatërrohen lehtë. Një shell ose komandë në distancë ekzekutohet në hostin SSH. Një përcjellje lokale hap një socket dëgjues në klient dhe e bën lidhjen e mëtejshme nga ana e largët. Një përcjellje në distancë bën të kundërtën, duke dëgjuar në anën e serverit. Përcjellja dinamike ekspozon një pikë fundore SOCKS për programet që dinë ta përdorin.

• Shell: programi ekzekutohet në makinën e largët, asgjë nuk dëgjon lokalisht.
• Përcjellje lokale: laptopi juaj ka një portë, hosti i largët bën lidhjen dalëse.
• Përcjellje në distancë: ana e largët ka një portë, trafiku kthehet drejt jush.
• Dinamike: një proxy SOCKS në klient, përdoret vetëm nga aplikacione që e kuptojnë proxy-n.

Asnjëra prej këtyre nuk instalon një rrugë. Një program që injoron cilësimet e proxy-t, ose flet UDP, ose i zgjidh vetë emrat, nuk ndikohet nga një sesion aktiv SSH. Ky nuk është defekt në SSH; ky është shtrirja e ndërfaqes që zgjidhët.

Përcjelljet lokale, në distancë dhe dinamike ndryshojnë në atë se kush dëgjon

Dallimi që vendos shumicën e rasteve është kush zotëron socket-in dëgjues. Me përcjellje lokale, klienti dëgjon dhe skaji i largët telefonon destinacionin, prandaj adresa e destinacionit zgjidhet nga këndvështrimi i serverit. Me përcjellje në distancë, serveri dëgjon dhe lidhja transportohet përsëri në anën tuaj, dhe kështu ekspozoni një shërbim lokal pa e publikuar drejtpërdrejt.

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

Komanda e parë lidh portën 5432 në laptop dhe e përcjell te baza e të dhënave siç shihet nga bastioni. E dyta krijon një proxy SOCKS në portën 1080. Komanda e tretë konfirmon cilat procese vërtet dëgjojnë, dhe kjo është prova e vetme se përcjellja ekziston në vend që të ketë dështuar në heshtje për një konflikt portash.

Përcjellja dinamike meriton paralajmërimin e vet: mbulon vetëm aplikacionet që respektojnë SOCKS. Një shfletues mund të drejtohet drejt saj, një mjeti të rreshtit të komandës mund t'i thuhet ta përdorë, por një drejtues i bazës së të dhënave me stivën e vet të lidhjeve zakonisht nuk mundet. Supozimi se çdo program në makinë tani përdor tunelin është gabimi më i zakonshëm në të gjithë këtë fushë.

Modaliteti i pajisjes së tunelit është përjashtimi i vetëm i vërtetë rrjetësor

OpenSSH mbështet gjithashtu përcjelljen e pajisjes së tunelit -w, e cila kalon një ndërfaqe pikë-për-pikë në vend të një dëgjuesi TCP. Ky është një tunel i vërtetë rrjeti, dhe konfigurohet me dashje, jo si efekt anësor i hapjes së një shell.

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

Kërkon numrat përkatës të ndërfaqeve të disponueshëm në të dy skajet, konfigurimin e saktë në server dhe privilegje të mjaftueshme në klient për të krijuar pajisjen. Kërkon gjithashtu një plan adresimi dhe rrugëzimi, sepse një ndërfaqe e zhveshur nuk mbart asnjë politikë se cilat destinacione duhet ta përdorin.

Edhe atëherë, tuneli përfundon në hostin e largët. Çfarëdo mbrojtjeje që ofroi transporti SSH përfundon atje, dhe lidhja e mëtejshme është një kërcim i veçantë. Një portë VPN ka të njëjtën formë kufiri, prandaj krahasimi duhet të jetë për shtrirjen dhe përfundimin, jo për atë se cili mjet është më i fortë. Emërtimi me zë i atij kufiri zgjidh gjithashtu debatin se a «kripton gjithçka» një tunel, sepse haptazi nuk e bën.

Provoni që aplikacioni juaj përdor ndërfaqen që ndërtuat

Verifikimi është për çdo aplikacion, jo për sesionin. Një përcjellje që funksionon dëshmon se porta është lidhur dhe skaji i largët mund të telefonojë; nuk dëshmon se programi që ju intereson u lidh përmes saj.

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'

Komanda e parë dërgon një kërkesë përmes pikës fundore SOCKS me emrin e hostit të zgjidhur në distancë, dhe e dyta ushtron portën e përcjellë të bazës së të dhënave me TLS ende të kërkuar. Ekzekutoni të njëjtat teste me përcjelljen e ndalur për të konfirmuar se dështojnë, sepse një test që kalon në të dyja mënyrat nuk e përdori kurrë tunelin.

Pastaj krahasoni me një VPN të rrugëzuar vetëm në dimensionet që kanë rëndësi: cilat destinacione mbulohen, cilat protokolle funksionojnë, ku përfundon mbrojtja dhe kush duhet të miratojë aksesin. Një përcjellje për një shërbim të vetëm mund të jetë përgjigjja më e ngushtë dhe më e mirë, ndërsa një VPN është forma e duhur kur shumë aplikacione kanë nevojë për të njëjtën rrugë rrjeti. Asnjëra nuk jep gjithçka që arrihet nga skaji i saj i largët.