Por que un oínte de proxy SSH inverso só é accesible no servidor
Comprobe o enderezo de enlace do oínte remoto e o modo GatewayPorts antes de cambiar o protocolo do proxy ou as credenciais.
Un reenvío remoto pode funcionar desde o servidor SSH pero rexeitar conexións doutra máquina porque só escoita en loopback. Comprobe primeiro o enderezo real de escoita.
No lado do servidor GatewayPorts | Enlace do reenvío remoto |
|---|---|
no, o valor predeterminado | Restrinxe os oíntes a loopback |
yes | Forza o enlace comodín (wildcard) |
clientspecified | Permite ao cliente solicitar un enderezo de enlace concreto |
Para un oínte destinado a unha interface controlada, o servidor pode usar:
GatewayPorts clientspecifiedDespois o cliente solicita un enderezo axeitado na súa especificación -R. Ese enderezo debe existir na máquina remota e as demais restricións de reenvío seguen aplicándose. O -g do lado do cliente non é un control intercambiable para esta dirección.
Tres permisos seguen sendo distintos: a autorización SSH para crear o reenvío, o acceso de rede ao seu oínte e a política de acceso propia do servizo HTTP ou SOCKS. Un inicio de sesión SSH autentica o creador do túnel; non autentica cada chamador posterior dun oínte compartido nin engade un desafío de contrasinal SOCKS.
Se un chamador remoto aínda non pode conectarse, inspeccione o enderezo de enlace, as restricións de reenvío do servidor e a ruta do cortafuegos nesa orde. Unha vez que TCP chega ao oínte, unha negociación de proxy fallida é un problema posterior.