Reenvío dinámico SSH como proxy SOCKS sobre a súa VPN

Unha aplicación que só fala SOCKS non ten con que falar nunha VPN corrente, porque o túnel transporta paquetes e a aplicación quere un extremo de proxy. OpenSSH pode fornecer ese extremo cando o propietario do acceso o permite, xa que o reenvío dinámico converte unha sesión SSH nun proxy local. Despois hai dous saltos que hai que manter separados: o túnel que chega ao host SSH e a conexión que ese host abre a continuación. Separares explica tanto por que funciona a disposición como que non fará nunca.

En que se converte o escoitador SSH e en que non

O reenvío dinámico fai que o cliente SSH escoite localmente e fale SOCKS4 ou SOCKS5 con todo o que se conecte. Cada solicitude nomea un destino e o servidor SSH abre a conexión seguinte, por iso a consulta do destino pode ocorrer no lado remoto. Iso é reenvío TCP a nivel de aplicación, non unha VPN para todo o dispositivo. Non transporta ningunha asociación UDP, nin ICMP, nin nada para aplicacións que ignoran por completo os axustes de proxy. O salto do servidor SSH á aplicación tampouco está dentro do seu túnel, o que importa cando o destino acepta tráfico só de redes coñecidas.

Os requisitos previos son reais: unha ruta ata o host SSH, unha conta autorizada, unha chave de host do servidor verificada e permiso para reenviar. Ningún o crea o proxy, e o último adoita ser o primeiro que falta. Confirme os catro antes de depurar calquera outra cousa, porque o fallo vese igual desde o cliente, falte o que falte.

Inícieo en loopback cun porto explícito

Escolla un porto local sen usar e lígueo explicitamente a loopback en lugar de deixar o enderezo sen especificar. As tres opcións de abaixo existen cada unha por un motivo.

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

-N omite o comando remoto e -T omite o pseudoterminal, así que a sesión existe só para reenviar. ExitOnForwardFailure fai que o cliente saia cando non se pode crear o escoitador, en lugar de executarse sen o reenvío que pediu. ControlPath=none mantén a sesión fóra dunha conexión multiplexada existente que podería engadir os seus propios reenvíos. Loopback mantén o escoitador fóra da LAN, pero nunha máquina compartida non é unha fronteira de autorización, porque outros procesos locais tamén poden alcanzalo. A referencia do cliente OpenSSH documenta todas estas opcións, e o aviso de loopback dedúcese de que é un socket que escoita.

Envíe os nomes a través do proxy, non ao seu redor

Un cliente SOCKS5 pode resolver o destino por si mesmo ou pedirlle ao proxy que o faga, e esa elección decide que resolvedor responde. Con socks5h, curl envía o nome de host a través do proxy, así que a consulta ocorre no servidor SSH. Con socks5 simple, o portátil resolve primeiro e só viaxa a conexión, o que anula en silencio o obxectivo cando o nome é interno. A solicitude de abaixo tamén baleira a lista de sen-proxy, así que un valor herdado de NO_PROXY non pode encaminala ao redor do proxy.

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

A validación do certificado e o inicio de sesión propio da aplicación seguen aplicándose, porque o proxy non substitúe ningún dos dous. Quedan dúas consultas: o portátil debe chegar ao host SSH pola ruta permitida de VPN e DNS, e o servidor SSH debe resolver por si mesmo o nome da aplicación. A segunda pódese probar por separado antes de que ningún tráfico pase polo proxy.

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

Demostre un destino permitido e despois peche a sesión

Probe un destino que a política permite e un que debería rexeitar, porque un reenvío que funciona só demostra que o escoitador funciona e nada máis. A aplicación ve o enderezo de orixe que escolle o servidor SSH, que non é o enderezo do túnel do seu portátil. Onde o extremo remoto rexistra as conexións por orixe, esa diferenza é o primeiro que hai que mirar cando se rexeita unha solicitude.

Deteña a sesión a través do proceso que a posúe en lugar de matar un shell non relacionado. Despois confirme que o escoitador desapareceu, porque un porto que aínda responde é unha sesión que non pechou de verdade. Retire só o axuste de proxy que introduciu este exercicio e deixe o resto da configuración da aplicación en paz. Un terminal desatendido cunha regra de reenvío non é un servizo, e un proxy permanente necesita un ciclo de vida aprobado, non unha xanela esquecida.

ss -ltn | grep 1080

Fallos que esta disposición non pode arranxar

Algúns síntomas apuntan directamente aos límites de arriba, e recoñecelos pronto aforra unha tarde de depuración do proxy. A táboa relaciona o que ve co que adoita significar. Calquera cousa da última columna é unha cuestión de deseño, non un erro de configuración.

As tres primeiras filas son as que a xente diagnostica mal, porque cada unha produce un intento de conexión en lugar dun erro sobre o propio proxy. Un nome que se resolve no portátil non di nada sobre o resolvedor do servidor, e o fallo lese en cambio como un problema de certificado ou de tempo de espera. As aplicacións só UDP quedan fóra do deseño, non rotas dentro del, e ningunha opción ssh adicional o cambia. A fila do navegador é o recordatorio habitual de que os axustes de proxy son por aplicación. A última fila é a razón pola que existe a comprobación de peche: un porto que segue escoitando significa que agora o posúe outra cousa.