Dálle a un Pi remoto un proxy SOCKS a través do teu cliente SSH

Un reenvío dinámico remoto coloca o oínte SOCKS no Pi e fai a conexión seguinte desde a ruta VPN aprobada do teu portátil. Sen un segundo servidor SSH.

Das por feito que un proxy SOCKS ten que executarse onde xa existe o acceso á rede. OpenSSH pode colocar o oínte nun lugar completamente distinto. Un reenvío dinámico remoto abre o porto SOCKS nun host remoto e orixina cada conexión desde o teu cliente SSH local, que transporta a ruta VPN aprobada do teu portátil. O Pi obtén un proxy limitado; non herda o teu túnel nin os teus privilexios.

O oínte e o lado do que nace a conexión poden ser distintos

Un ssh -D 1080 normal executa o oínte na túa propia máquina e envía as conexións desde alí. Un reenvío dinámico remoto invirte iso: o oínte aparece no host remoto e cada conexión que acepta ábrese desde o lado local. O manual do cliente OpenSSH documenta -R sen un destino fixo exactamente como esta disposición SOCKS4/5.

Un comando admitido desde o portátil ten este aspecto, coa conta, os hosts e o porto tratados como marcadores:

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

Tres detalles fan traballo útil alí. -S none mantén a sesión lonxe dun mestre de control compartido, ExitOnForwardFailure falla rápido en vez de deixarte cunha sesión medio aberta, e PermitRemoteOpen limita ata onde pode chegar o oínte remoto. Usa unha conta de Pi autorizada e verifica a clave do host antes de engadir calquera cousa disto.

Que expón realmente o oínte remoto

Comproba a política de reenvío do servidor antes de confiar no oínte. Con GatewayPorts no o reenvío remoto queda ligado a loopback, que é a exposición que queres. Un servidor configurado para forzar reenvío comodín publica o mesmo porto en cada interface, o que converte un proxy persoal en algo que a rede local pode acadar.

Loopback tampouco é unha fronteira por usuario. Outro proceso no Pi pode conectarse a 127.0.0.1:1080 se coñece o porto, así que as contas locais do Pi e todo o que se executa nel forman parte do teu deseño de acceso. Iso é un motivo para manter estreita a lista de destinos, non un motivo para saltar a comprobación da política.

Mantén o destino permitido específico para a aplicación que intentas acadar. Substituílo por un reenvío sen restricións para que funcione un programa alleo amplía o camiño moito máis alá do problema co que comezaches. A lista de destinos tamén rexistra para que servía a sesión, o que axuda a quen a audite despois. Apúntaa xunto á conta que usaches.

Envía unha aplicación a través do proxy

Un cliente do Pi que entende de proxy pode entón facer a petición. O prefixo socks5h entrega o nome de destino ao proxy, así que a consulta e a conexión ocorren ambas no lado do portátil, e coincide co destino nomeado en PermitRemoteOpen:

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

Conserva a validación normal de certificados e a autenticación propia da aplicación. O proxy cambia onde se establece a conexión TCP; non fai seguro un servizo sen autenticación nin converte un extremo autoasinado nun de confianza.

O portátil segue necesitando a súa propia ruta e acceso ao resolutor tanto ao servidor SSH como á aplicación. O tráfico do seu cliente SSH ten que ser seleccionado pola política VPN aprobada, e unha exclusión de túnel dividido pode enviar ese tráfico por un camiño distinto do que probaches.

Demostra o camiño e péchao

Confirma que o oínte existe onde o esperas e que só responde o destino previsto:

$ 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 pode demostrar que o reenvío se estableceu, e aínda así non pode certificar que o inicio de sesión na aplicación teña éxito augas abaixo. Proba a aplicación, non só o porto. Un oínte que acepta e despois falla cada petición normalmente significa que o nome de destino ou a ruta do portátil son incorrectos, non que o túnel fallase.

Esta disposición só transporta TCP. UDP, ICMP e os programas que ignoran a configuración de proxy quedan fóra, e o reenvío remata no momento en que remata a sesión SSH. Detén esa sesión cando remates e quita a configuración de proxy que engadiches á aplicación.

Para un acceso permanente, usa no seu lugar a alta compatible do propietario da rede ou unha pasarela xestionada. Un proxy inverso é a ferramenta equivocada para eludir as restricións de dispositivo ou de recursos dunha VPN; usado dentro delas, é simplemente unha ruta de aplicación autorizada con límites explícitos.

Artigos relacionados