Kwa nini msikilizaji wa proksi ya SSH iliyogeuzwa anapatikana kwenye seva pekee
Angalia anwani ya bind ya msikilizaji wa mbali na hali ya GatewayPorts kabla ya kubadilisha itifaki ya proksi au vitambulisho.
Usambazaji wa mbali unaweza kufanya kazi kutoka kwa seva ya SSH lakini ukakataa miunganisho kutoka kwa mashine nyingine kwa sababu husikiliza kwenye loopback pekee. Angalia kwanza anwani halisi ya kusikiliza.
Upande wa seva GatewayPorts | Bind ya usambazaji wa mbali |
|---|---|
no, chaguo-msingi | Huzuia wasikilizaji kwenye loopback |
yes | Hulazimisha bind ya wildcard |
clientspecified | Huruhusu mteja kuomba anwani maalum ya bind |
Kwa msikilizaji unaokusudiwa kwa kiolesura kimoja kinachodhibitiwa, seva inaweza kutumia:
GatewayPorts clientspecifiedKisha mteja huomba anwani inayofaa katika vipimo vyake vya -R. Anwani hiyo lazima iwepo kwenye mashine ya mbali, na vizuizi vingine vya usambazaji bado vinatumika. -g upande wa mteja si udhibiti unaobadilishana kwa mwelekeo huu.
Ruhusa tatu zinabaki tofauti: idhini ya SSH ya kuunda usambazaji, ufikiaji wa mtandao kwa msikilizaji wake, na sera ya ufikiaji ya huduma ya HTTP au SOCKS yenyewe. Kuingia kwa SSH kunathibitisha muundaji wa handaki; hakuthibitishi kila mpigaji simu wa baadaye wa msikilizaji unaoshirikiwa na haiongezi changamoto ya neno la siri la SOCKS.
Ikiwa mpigaji simu wa mbali bado hawezi kuunganisha, kagua anwani ya bind, vizuizi vya usambazaji vya seva na njia ya firewall kwa mpangilio huo. Baada ya TCP kufikia msikilizaji, kushindwa kwa makubaliano ya proksi ni tatizo la baadaye.