Waarom 'n omgekeerde SSH-proxy-ontvanger slegs op die bediener bereikbaar is
Kontroleer die remote-ontvanger se bindadres en GatewayPorts-modus voordat jy die proxyprotokol of geloofsbriewe verander.
'n Remote forward kan vanaf die SSH-bediener werk terwyl dit verbindings van 'n ander masjien weier, omdat dit slegs op loopback luister. Kontroleer eers die werklike luisteradres.
Bedienerkant GatewayPorts | Remote-forward-binding |
|---|---|
no, die verstek | Beperk luisteraars tot loopback |
yes | Forseer wildcard-binding |
clientspecified | Laat die kliënt toe om 'n spesifieke bindadres te versoek |
Vir 'n luisteraar wat op een beheerde koppelvlak bedoel is, kan die bediener gebruik:
GatewayPorts clientspecifiedDie kliënt versoek dan 'n gepaste adres in sy -R-spesifikasie. Daardie adres moet op die remote masjien bestaan, en ander forwardbeperkings geld steeds. Kliëntkant -g is nie 'n uitruilbare beheer vir hierdie rigting nie.
Drie toestemmings bly afsonderlik: SSH-magtiging om die forward te skep, netwerktoegang tot sy luisteraar, en die HTTP- of SOCKS-diens se eie toegangsbeleid. 'n SSH-aanmelding verifieer die tonnelskepper; dit verifieer nie elke latere oproeper van 'n gedeelde luisteraar nie en voeg nie 'n SOCKS-wagwoorduitdaging by nie.
As 'n remote oproeper steeds nie kan verbind nie, ondersoek die bindadres, bedienerforwardbeperkings en vuurmuurpad in daardie volgorde. Sodra TCP die luisteraar bereik, is 'n mislukte proxy-handdruk 'n latere probleem.