Ce trafic de aplicații transportă de fapt un forwarding SSH?

Terminalul se conectează, promptul apare și toată lumea este de acord că accesul SSH funcționează. Apoi un client de baze de date de pe laptop tot nu ajunge la gazda privată, iar sesiunea este învinovățită. Ce s-a construit a fost un shell, iar acesta este una dintre cele patru interfețe destul de diferite pe care SSH le poate oferi. Numiți mai întâi interfața, apoi verificați că aplicația o folosește într-adevăr. Ordinea contează, pentru că fiecare interfață eșuează în felul ei.

Numiți interfața înainte de a compara orice

manualul clientului OpenSSH distinge patru mecanisme ușor de confundat. Un shell sau o comandă la distanță se execută pe gazda SSH. Un forwarding local deschide un socket de ascultare pe client și face conexiunea următoare din partea îndepărtată. Un forwarding la distanță face invers, ascultând pe partea serverului. Forwardingul dinamic expune un punct final SOCKS pentru programele care știu să îl folosească.

• Shell: programul rulează pe mașina îndepărtată, nimic nu ascultă local.
• Forwarding local: laptopul dumneavoastră are un port, gazda îndepărtată face conexiunea de ieșire.
• Forwarding la distanță: partea îndepărtată are un port, traficul se întoarce spre dumneavoastră.
• Dinamic: un proxy SOCKS pe client, folosit doar de aplicațiile care îl înțeleg.

Niciuna dintre acestea nu instalează o rută. Un program care ignoră setările de proxy, sau vorbește UDP, sau rezolvă singur numele, nu este afectat de o sesiune SSH activă. Aceasta nu este o eroare în SSH; este sfera interfeței pe care ați ales-o.

Forwardingul local, la distanță și dinamic diferă prin cine ascultă

Distincția care decide majoritatea cazurilor este cine deține socketul de ascultare. La un forwarding local, clientul ascultă, iar capătul îndepărtat apelează destinația, de aceea adresa destinației este rezolvată din perspectiva serverului. La un forwarding la distanță, serverul ascultă, iar conexiunea este dusă înapoi spre partea dumneavoastră, și astfel expuneți un serviciu local fără a-l publica direct.

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

Prima comandă leagă portul 5432 pe laptop și îl redirecționează către baza de date așa cum este văzută din bastion. A doua creează un proxy SOCKS pe portul 1080. A treia comandă confirmă ce procese ascultă într-adevăr, și aceasta este singura dovadă că forwardingul există, în loc să fi eșuat în tăcere din cauza unui conflict de porturi.

Forwardingul dinamic merită propriul avertisment: acoperă doar aplicațiile care respectă SOCKS. Un browser poate fi îndreptat spre el, unei unelte de linie de comandă i se poate spune să îl folosească, dar un driver de baze de date cu propriul stivă de conexiuni de obicei nu poate. Presupunerea că fiecare program de pe mașină folosește acum tunelul este cea mai frecventă greșeală din tot acest domeniu.

Modul dispozitiv de tunel este singura excepție de rețea reală

OpenSSH acceptă și forwardingul de dispozitiv de tunel -w, care transmite o interfață punct la punct în locul unui ascultător TCP. Acesta este un tunel de rețea veritabil și este configurat deliberat, nu un efect secundar al deschiderii unui shell.

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

Necesită numerele de interfață corespunzătoare disponibile la ambele capete, configurația corectă pe server și privilegii suficiente pe client pentru a crea dispozitivul. Necesită și un plan de adresare și rutare, pentru că o interfață goală nu poartă nicio politică despre ce destinații ar trebui să o folosească.

Chiar și atunci, tunelul se termină la gazda îndepărtată. Orice protecție oferită de transportul SSH se termină acolo, iar conexiunea următoare este un salt separat. O poartă VPN are aceeași formă de frontieră, de aceea comparația ar trebui să fie despre sferă și terminare, nu despre care unealtă este mai puternică. Numele acestei frontiere cu voce tare închide și dezbaterea despre dacă un tunel «cifrează tot», pentru că evident nu o face.

Verificați că aplicația dumneavoastră folosește interfața pe care ați construit-o

Verificarea este pe aplicație, nu pe sesiune. Un forwarding funcțional dovedește că portul este legat și că partea îndepărtată poate apela; nu dovedește că programul care vă interesează s-a conectat prin el.

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'

Prima comandă trimite o cerere prin punctul final SOCKS cu numele gazdei rezolvat de la distanță, iar a doua exersează portul de baze de date redirecționat, cu TLS încă obligatoriu. Rulați aceleași teste cu forwardingul oprit pentru a confirma că eșuează, pentru că un test care trece în ambele feluri nu a folosit niciodată tunelul.

Apoi comparați cu un VPN rutat doar în dimensiunile care contează: ce destinații sunt acoperite, ce protocoale funcționează, unde se termină protecția și cine trebuie să aprobe accesul. Un forwarding pentru un singur serviciu poate fi răspunsul mai îngust și mai bun, în timp ce un VPN este forma corectă când multe aplicații au nevoie de aceeași cale de rețea. Niciunul nu acordă tot ce este accesibil de la capătul său îndepărtat.