Redirecționare dinamică SSH ca proxy SOCKS peste VPN-ul dvs.

O aplicație care vorbește doar SOCKS nu are cu cine vorbi pe un VPN obișnuit, pentru că tunelul transportă pachete, iar aplicația vrea un punct final de proxy. OpenSSH poate furniza acel punct final atunci când proprietarul accesului permite, deoarece redirecționarea dinamică transformă o sesiune SSH într-un proxy local. Apoi sunt două salturi care trebuie ținute separat: tunelul care ajunge la gazda SSH și conexiunea pe care acea gazdă o deschide mai departe. Separarea lor explică atât de ce funcționează aranjamentul, cât și ce nu va face niciodată.

În ce se transformă și în ce nu se transformă ascultătorul SSH

Redirecționarea dinamică face clientul SSH să asculte local și să vorbească SOCKS4 sau SOCKS5 cu tot ce se conectează. Fiecare cerere numește o destinație, iar serverul SSH deschide conexiunea următoare, de aceea căutarea destinației poate avea loc în partea cealaltă. Acesta este forwarding TCP la nivel de aplicație, nu un VPN pentru întregul dispozitiv. Nu transportă nicio asociere UDP, nici ICMP, nici nimic pentru aplicațiile care ignoră complet setările de proxy. Nici saltul de la serverul SSH la aplicație nu este în interiorul tunelului dumneavoastră, ceea ce contează când destinația acceptă trafic doar din rețele cunoscute.

Condițiile prealabile sunt reale: o rută către gazda SSH, un cont autorizat, o cheie de gazdă a serverului verificată și permisiunea de a redirecționa. Niciuna nu este creată de proxy, iar ultima lipsește de obicei prima. Confirmați toate patru înainte de a depana orice altceva, pentru că din partea clientului eșecul arată la fel, oricare ar lipsi.

Porniți-l pe loopback cu un port explicit

Alegeți un port local neutilizat și legați-l explicit de loopback în loc să omiteți adresa. Cele trei opțiuni de mai jos există fiecare pentru un motiv.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N omite comanda la distanță, iar -T omite pseudo-terminalul, așa că sesiunea există doar pentru redirecționare. ExitOnForwardFailure face clientul să iasă atunci când ascultătorul nu poate fi creat, în loc să ruleze fără redirecționarea cerută. ControlPath=none ține sesiunea în afara unei conexiuni multiplexate existente care ar putea adăuga propriile redirecționări. Loopback ține ascultătorul în afara LAN-ului, dar pe o mașină partajată nu este o graniță de autorizare, pentru că și alte procese locale îl pot atinge. Referința clientului OpenSSH documentează toate aceste opțiuni, iar avertismentul despre loopback decurge din ce este un socket care ascultă.

Trimiteți numele prin proxy, nu pe lângă el

Un client SOCKS5 poate rezolva destinația singur sau poate cere proxy-ului să o facă, iar această alegere decide care resolver răspunde. Cu socks5h, curl trimite numele gazdei prin proxy, așa că rezolvarea are loc pe serverul SSH. Cu socks5 simplu, laptopul rezolvă mai întâi și călătorește doar conexiunea, ceea ce anulează în tăcere scopul când numele este intern. Cererea de mai jos golește și lista fără proxy, astfel încât o valoare NO_PROXY moștenită să nu o poată duce pe lângă proxy.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

Validarea certificatului și autentificarea proprie a aplicației se aplică în continuare, pentru că proxy-ul nu înlocuiește niciuna. Rămân două rezolvări: laptopul trebuie să ajungă la gazda SSH pe calea permisă de VPN și DNS, iar serverul SSH trebuie să rezolve singur numele aplicației. A doua poate fi testată separat înainte ca vreun trafic să treacă prin proxy.

ssh [email protected] getent hosts app.corp.example

Dovediți o destinație permisă, apoi închideți sesiunea

Testați o destinație pe care politica o permite și una pe care ar trebui să o respingă, pentru că o redirecționare funcțională dovedește doar că ascultătorul funcționează și nimic mai mult. Aplicația vede adresa de sursă pe care o alege serverul SSH, iar aceasta nu este adresa tunelului laptopului dvs. Acolo unde capătul îndepărtat înregistrează conexiunile după sursă, acea diferență este primul lucru de verificat când o cerere este respinsă.

Opriți sesiunea prin procesul care o deține, nu prin a ucide un shell nelegat. Apoi confirmați că ascultătorul a dispărut, pentru că un port care încă răspunde este o sesiune pe care nu ați închis-o cu adevărat. Eliminați doar setarea de proxy introdusă de acest exercițiu și lăsați restul configurației aplicației în pace. Un terminal nesupravegheat care ține o regulă de redirecționare nu este un serviciu, iar un proxy permanent are nevoie de un ciclu de viață aprobat, nu de o fereastră uitată.

ss -ltn | grep 1080

Defecțiuni pe care acest aranjament nu le poate remedia

Unele simptome indică direct limitele de mai sus, iar recunoașterea lor devreme economisește o după-amiază de depanare a proxy-ului. Tabelul leagă ceea ce vedeți de ceea ce înseamnă de obicei. Orice din ultima coloană este o chestiune de proiectare, nu o eroare de configurare.

Primele trei rânduri sunt cele pe care oamenii le diagnostichează greșit, pentru că fiecare produce o încercare de conectare în loc de o eroare despre proxy în sine. Un nume care se rezolvă pe laptop nu spune nimic despre resolverul serverului, iar eșecul este citit în schimb ca o problemă de certificat sau de expirare. Aplicațiile doar cu UDP stau în afara proiectării, nu stricate în interiorul ei, iar nicio opțiune ssh suplimentară nu schimbă asta. Rândul despre browser este reamintirea obișnuită că setările de proxy sunt per aplicație. Ultimul rând este motivul pentru care există verificarea la închidere: un port care încă ascultă înseamnă că acum îl deține altceva.