Creează un proxy SOCKS local cu SSH

Cu acces SSH autorizat la un server, OpenSSH poate crea un ascultător SOCKS pe calculatorul tău. Conexiunea SSH transportă traficul redirecționat, iar serverul distant face conexiunea la destinație.

Un ascultător doar pe loopback

ssh -N -T -o ControlPath=none -o ForkAfterAuthentication=no -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]

Înlocuiește contul și numele gazdei. Serverul SSH trebuie să permită redirecționarea; administratorul poate limita redirecționarea și destinațiile independent de conectarea la cont.

-D creează redirecționare dinamică, iar adresa loopback explicită limitează ascultătorul la această mașină. -N omite o comandă distantă; -T omite un pseudoterminal. ControlPath=none evită un master de partajare existent, iar ForkAfterAuthentication=no păstrează această invocare în prim-plan.

Ține procesul pornit când folosești proxy-ul. Dacă portul 1080 e ocupat, alege alt port înalt liber și actualizează clientul. ExitOnForwardFailure=yes face SSH să iasă dacă nu poate crea ascultătorul.

Folosirea punctului SOCKS

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' --connect-timeout 5 --max-time 15 https://example.com/

Această cerere deleagă gestionarea numelui destinației prin SOCKS5. Alte aplicații au nevoie de configurare SOCKS proprie; un câmp de proxy HTTP nu poate vorbi SOCKS cu acest ascultător.

Pentru a verifica procesul care deține portul:

ss -ltnp 'sport = :1080'

Procesul SSH dorit ar trebui să dețină un ascultător loopback. O cerere prin el verifică dacă și serverul distant poate atinge ținta. Folosește o destinație controlată când trebuie să inspectezi ieșirea observată.

Durata sesiunii

Ctrl-C închide procesul SSH, ascultătorul și conexiunile redirecționate. O conexiune SSH căzută face și proxy-ul indisponibil.

ExitOnForwardFailure verifică pregătirea inițială. Nu încheie SSH la fiecare eșec ulterior de conexiune la destinație; diagnostichează separat sesiunea, portul local și cererea la țintă.