Redirecció local per SSH a un proxy HTTP existent: dues adreces de loopback

El vostre proxy aprovat s’executa en un amfitrió de salt on només escolta a loopback, així que res fora d’aquesta màquina no hi pot arribar. No us cal una VPN ni un proxy nou; us cal un port d’aquesta màquina portat a un port vostre. Una redirecció local fa exactament això, i només requereix una ordre i un paràmetre de l’aplicació. La confusió sol venir de barrejar quina adreça de loopback pertany a quina màquina.

Decidiu si ja existeix un proxy fix

Aquesta tècnica redirigeix un servei que ja s’executa. Si l’amfitrió remot només té un dimoni SSH i cap proxy, cap quantitat de redirecció no en crearà un, i la connexió serà rebutjada des del costat remot. Confirmeu que el proxy està lligat, el seu port i si escolta a 127.0.0.1 o en una adreça d’interfície concreta, perquè aquesta adreça és la que ha d’apuntar la redirecció.

Confirmar-ho primer us estalvia de depurar un túnel que mai no va estar connectat a res.

Construïu la redirecció i llegiu l’ordre

La forma que voleu lliga un port de loopback al vostre portàtil i el connecta, des del costat del servidor, a l’adreça del proxy tal com la veu el servidor.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N suprimeix una ordre remota i -T suprimeix l’assignació de termios, perquè voleu un túnel i no una shell. La primera adreça de loopback és on escolta el portàtil; la segona es resol des del servidor SSH, així que 127.0.0.1 allà vol dir el proxy d’aquella màquina. ExitOnForwardFailure fa que l’ordre falli sorollosament si el port local ja està ocupat, en lloc d’iniciar una sessió que no redirigeix res. Escriviu l’adreça de destinació tal com la resol el servidor, perquè un nom que només el vostre portàtil pot resoldre fallarà a l’altre costat.

La política del mateix servidor s’aplica abans que res d’això funcioni. AllowTcpForwarding ho ha de permetre, i PermitOpen pot restringir a quines destinacions i ports pot arribar una sessió, així que una redirecció que el client accepta encara pot ser rebutjada pel servidor. El rebuig apareix com una errada de redirecció o de canal al client, i llegir aquest missatge és més ràpid que editar l’ordre.

Apunteu una aplicació a la redirecció

Configureu l’aplicació perquè faci servir un proxy HTTP a http://127.0.0.1:13128, amb credencials si el proxy remot les requereix. Mantingueu la verificació de certificats pròpia de l’aplicació per a destinacions HTTPS, ja que el túnel del proxy no la substitueix. Aquesta és una redirecció fixa d’un sol servei, així que cal dir a l’aplicació que hi ha un proxy en lloc de deixar que el descobreixi.

Una comprovació ràpida abans de configurar res permanent: curl -x http://127.0.0.1:13128 -I https://example.com, que exerceix el mètode HTTP CONNECT que el proxy ha de suportar.

Mantingueu l’autoritat on era

El proxy remot encara decideix quines destinacions i mètodes permet, i un inici de sessió SSH no hauria de concedir silenciosament un relé web general a cada compte. Lligar a 127.0.0.1 al portàtil evita publicar el port a la vostra xarxa local, i no fa el port privat davant altres processos de la mateixa màquina. Substituir aquest lligam per una adreça wildcard per compartir el proxy és com es crea un relé obert no gestionat.

El transport SSH protegeix el salt fins al servidor. Més enllà d’aquest punt el proxy obre la seva pròpia connexió, així que una petició HTTP simple a una destinació continua sent simple més enllà del servidor, encara que el primer tram fos xifrat.

Verifiqueu els dos extrems i netegeu

La configuració del túnel local i l’èxit del servei remot són resultats diferents, i l’estat de sortida de l’ordre només us parla del primer. Comproveu que l’oient existeix amb ss -ltn, i després feu una petició permesa de l’aplicació i una petició que el proxy hauria de rebutjar. Si tots dos es comporten com s’espera, el camí és real; si el túnel està actiu i tota petició falla, el proxy rebutja o no pot arribar a la destinació.

Quan acabeu, atureu el procés SSH que el posseeix, traieu el paràmetre del proxy de l’aplicació i confirmeu que el port local ha desaparegut en lloc de deixar un oient que sobrevisqui a la tasca.