Bakit ang Reverse SSH Proxy Listener ay Maabot Lamang sa Server
Suriin ang bind address ng remote listener at ang GatewayPorts mode bago baguhin ang proxy protocol o mga kredensyal.
Ang remote forward ay maaaring gumana mula sa SSH server ngunit tanggihan ang mga koneksyon mula sa ibang makina dahil nakikinig lamang ito sa loopback. Suriin muna ang aktwal na address ng pakikinig.
Sa panig ng server GatewayPorts | Bind ng remote forward |
|---|---|
no, ang default | Nililimitahan ang mga listener sa loopback |
yes | Pinipilit ang wildcard bind |
clientspecified | Pinapayagan ang client na humiling ng partikular na bind address |
Para sa isang listener na inilaan sa isang kontroladong interface, maaaring gamitin ng server ang:
GatewayPorts clientspecifiedPagkatapos ay humihiling ang client ng angkop na address sa -R specification nito. Dapat umiral ang address na iyon sa remote machine, at nalalapat pa rin ang iba pang paghihigpit sa forward. Ang -g sa panig ng client ay hindi mapagpapalit na kontrol para sa direksyong ito.
Tatlong pahintulot ang nananatiling magkakaiba: ang SSH authorization upang likhain ang forward, ang network access sa listener nito, at ang sariling patakaran sa pag-access ng serbisyong HTTP o SOCKS. Ang pag-log in sa SSH ay nagpapatotoo sa lumikha ng tunnel; hindi nito pinatotohanan ang bawat susunod na tumatawag ng ibinahaging listener at hindi nagdaragdag ng SOCKS password challenge.
Kung hindi pa rin makakonekta ang isang remote caller, siyasatin ang bind address, mga paghihigpit sa forward ng server at ang daan ng firewall sa ganoong pagkakasunod-sunod. Kapag naabot na ng TCP ang listener, ang nabigong proxy handshake ay susunod na problema.