Doneu al Pi remot un SOCKS proxy a través del vostre client SSH

Assumiu que un proxy SOCKS ha de córrer allà on ja existeix l'accés a la xarxa. OpenSSH pot col·locar l'oïdor en un lloc completament diferent. Un reenviament dinàmic remot obre el port SOCKS en un amfitrió remot i origina cada connexió des del vostre client SSH local, que porta el camí VPN aprovat del portàtil. El Pi obté un proxy limitat; no hereta el vostre túnel ni els vostres privilegis.

L'oïdor i el costat on s'origina la connexió poden ser diferents

Un ssh -D 1080 corrent executa l'oïdor a la vostra pròpia màquina i envia les connexions des d'allà. Un reenviament dinàmic remot ho inverteix: l'oïdor apareix a l'amfitrió remot i cada connexió que accepta s'obre des del costat local. El manual del client OpenSSH documenta -R sense una destinació fixa exactament com aquesta disposició SOCKS4/5.

Una ordre admesa des del portàtil té aquest aspecte, amb el compte, els amfitrions i el port tractats com a marcadors:

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

Tres detalls hi fan feina útil. -S none manté la sessió allunyada d'un mestre de control compartit, ExitOnForwardFailure falla de pressa en lloc de deixar-vos amb una sessió mig oberta, i PermitRemoteOpen limita què pot abastar l'oïdor remot. Feu servir un compte de Pi autoritzat i verifiqueu la clau de l'amfitrió abans d'afegir-hi res d'això.

Què exposa realment l'oïdor remot

Comproveu la política de reenviament del servidor abans de confiar en l'oïdor. Amb GatewayPorts no el reenviament remot queda lligat a loopback, que és l'exposició que voleu. Un servidor configurat per forçar el reenviament comodí publica el mateix port a cada interfície, cosa que converteix un proxy personal en una cosa a l'abast de la xarxa local.

Loopback tampoc no és una frontera per usuari. Un altre procés del Pi es pot connectar a 127.0.0.1:1080 si coneix el port, així que els comptes locals del Pi i tot el que hi corre formen part del vostre disseny d'accés. Això és un motiu per mantenir la llista de destinacions estreta, no un motiu per saltar-se la comprovació de la política.

Mantingueu la destinació permesa específica per a l'aplicació a què intenteu arribar. Substituir-la per un reenviament sense restriccions per fer funcionar un programa no relacionat eixampla el camí molt més enllà del problema amb què vau començar. La llista de destinacions també enregistra per a què servia la sessió, cosa que ajuda qui l'auditi més endavant. Apunteu-la al costat del compte que vau fer servir.

Envieu una aplicació a través del proxy

Un client del Pi que entén el proxy pot fer la petició. El prefix socks5h lliura el nom de destinació al proxy, de manera que la consulta i la connexió passen totes dues al costat del portàtil, i coincideix amb la destinació anomenada a PermitRemoteOpen:

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

Conserveu la validació normal de certificats i l'autenticació pròpia de l'aplicació. El proxy canvia on es fa la connexió TCP; no fa segur un servei sense autenticació ni converteix un extrem autosignat en un de fiable.

El portàtil encara necessita la seva pròpia ruta i accés al resolutor tant al servidor SSH com a l'aplicació. El trànsit del seu client SSH ha de ser seleccionat per la política VPN aprovada, i una exclusió de túnel dividit pot enviar aquest trànsit per un camí diferent del que heu provat.

Demostreu el camí i tanqueu-lo

Confirmeu que l'oïdor existeix on l'espereu i que només respon la destinació prevista:

$ 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 pot demostrar que el reenviament es va establir, i tot i així no pot certificar que l'inici de sessió a l'aplicació tingui èxit aigües avall. Proveu l'aplicació, no només el port. Un oïdor que accepta i després falla cada petició normalment vol dir que el nom de destinació o la ruta del portàtil són incorrectes, no que el túnel hagi fallat.

Aquesta disposició només transporta TCP. UDP, ICMP i els programes que ignoren la configuració de proxy en queden fora, i el reenviament acaba en el moment que acaba la sessió SSH. Atureu aquesta sessió quan hàgiu acabat i traieu la configuració de proxy que vau afegir a l'aplicació.

Per a un accés permanent, feu servir en el seu lloc l'alta compatible del propietari de la xarxa o una passarel·la gestionada. Un proxy invers és l'eina equivocada per eludir les restriccions de dispositiu o de recursos d'una VPN; usat dins d'aquestes, és simplement un camí d'aplicació autoritzat amb límits explícits.