Oferiți unui Pi la distanță un proxy SOCKS prin clientul dumneavoastră SSH

O redirecționare dinamică la distanță pune ascultătorul SOCKS pe Pi și face conexiunea următoare din calea VPN aprobată a laptopului. Fără al doilea server SSH.

Presupuneți că un proxy SOCKS trebuie să ruleze acolo unde accesul la rețea există deja. OpenSSH poate plasa ascultătorul cu totul altundeva. O redirecționare dinamică la distanță deschide portul SOCKS pe o gazdă la distanță și pornește fiecare conexiune din clientul SSH local, care transportă calea VPN aprobată a laptopului. Pi primește un proxy limitat; nu moștenește tunelul sau privilegiile dumneavoastră.

Ascultătorul și partea din care pornește conexiunea pot fi diferite

Un ssh -D 1080 obișnuit rulează ascultătorul pe propria mașină și trimite conexiunile de acolo. O redirecționare dinamică la distanță inversează acest lucru: ascultătorul apare pe gazda aflată la distanță, iar fiecare conexiune pe care o acceptă este deschisă din partea locală. manualul clientului OpenSSH documentează -R fără o destinație fixă exact ca această aranjare SOCKS4/5.

O comandă acceptată de pe laptop arată astfel, cu contul, gazdele și portul tratate ca substituenți:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Trei detalii fac acolo o muncă utilă. -S none ține sesiunea departe de un master de control partajat, ExitOnForwardFailure eșuează rapid în loc să vă lase cu o sesiune pe jumătate deschisă, iar PermitRemoteOpen limitează până unde poate ajunge ascultătorul de la distanță. Folosiți un cont Pi autorizat și verificați cheia gazdei înainte de a adăuga ceva din toate acestea.

Ce expune de fapt ascultătorul de la distanță

Verificați politica de redirecționare a serverului înainte de a vă baza pe ascultător. Cu GatewayPorts no redirecționarea la distanță rămâne legată de loopback, și aceasta este expunerea pe care o doriți. Un server configurat să impună redirecționare wildcard publică același port pe fiecare interfață, ceea ce transformă un proxy personal în ceva ce rețeaua locală poate atinge.

Loopback nu este nici el o graniță pe utilizator. Un alt proces de pe Pi se poate conecta la 127.0.0.1:1080 dacă știe portul, așa că conturile locale ale Pi și tot ce rulează pe el fac parte din proiectarea dumneavoastră de acces. Acesta este un motiv să păstrați lista de destinații îngustă, nu un motiv să săriți peste verificarea politicii.

Păstrați destinația permisă specifică aplicației pe care încercați să o atingeți. Înlocuirea ei cu o redirecționare nerestricționată pentru ca un program fără legătură să funcționeze lărgește calea mult dincolo de problema cu care ați început. Lista de destinații înregistrează și pentru ce a fost sesiunea, ceea ce ajută pe cine o va audita mai târziu. Notați-o lângă contul pe care l-ați folosit.

Trimiteți o aplicație prin proxy

Un client de pe Pi care înțelege proxy poate face apoi cererea. Prefixul socks5h predă numele destinației proxy-ului, așa că interogarea și conexiunea au loc ambele pe partea laptopului, și corespunde destinației numite în PermitRemoteOpen:

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

Păstrați validarea normală a certificatelor și autentificarea proprie a aplicației. Proxy-ul schimbă unde este stabilită conexiunea TCP; nu face sigur un serviciu neautentificat și nu transformă un punct final auto-semnat într-unul de încredere.

Laptopul are în continuare nevoie de propria rută și de acces la resolver atât la serverul SSH, cât și la aplicație. Traficul clientului său SSH trebuie selectat de politica VPN aprobată, iar o excepție de tunel divizat poate trimite acel trafic pe o cale diferită de cea pe care ați testat-o.

Dovediți calea și închideți-o

Confirmați că ascultătorul există unde îl așteptați și că răspunde doar destinația prevăzută:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure poate dovedi că redirecționarea a fost stabilită și tot nu poate certifica faptul că autentificarea în aplicație reușește mai departe. Testați aplicația, nu doar portul. Un ascultător care acceptă și apoi eșuează fiecare cerere înseamnă de obicei că numele destinației sau ruta laptopului sunt greșite, nu că tunelul a eșuat.

Această aranjare transportă doar TCP. UDP, ICMP și programele care ignoră setările de proxy rămân în afara ei, iar redirecționarea se termină în momentul în care sesiunea SSH se termină. Opriți acea sesiune când ați terminat și eliminați setarea de proxy pe care ați adăugat-o aplicației.

Pentru acces permanent, folosiți în schimb înregistrarea acceptată a proprietarului rețelei sau o poartă administrată. Un proxy invers este instrumentul greșit pentru a ocoli restricțiile de dispozitiv sau de resurse ale unei VPN; folosit în interiorul lor, este pur și simplu o cale de aplicație autorizată cu limite explicite.

Articole similare