Zergatik SSH alderantzizko proxy entzulea zerbitzarian bakarrik dagoen eskuragarri
Egiaztatu urruneko entzulearen bind helbidea eta GatewayPorts modua proxy protokoloa edo kredentzialak aldatu aurretik.
Urruneko birbidalketa SSH zerbitzaritik funtziona dezake, baina beste makina batetik datozen konexioak ukatzen ditu, loopback-en bakarrik entzuten duelako. Egiaztatu lehenengo benetako entzute-helbidea.
Zerbitzariaren aldean GatewayPorts | Urruneko birbidalketaren bind-a |
|---|---|
no, lehenetsia | Entzuleak loopback-era mugatzen ditu |
yes | Wildcard bind-a behartzen du |
clientspecified | Bezeroari bind helbide zehatza eskatzeko aukera ematen dio |
Interfaze kontrolatu baterako pentsatutako entzule batentzat, zerbitzariak hau erabil dezake:
GatewayPorts clientspecifiedOndoren bezeroak helbide egokia eskatzen du bere -R zehaztapenean. Helbide horrek urruneko makinan existitu behar du, eta beste birbidalketa-murrizketa batzuk oraindik aplikatzen dira. Bezeroaren aldeko -g ez da norabide honetarako kontrol trukagarria.
Hiru baimen bereizi behar dira: birbidalketa sortzeko SSH baimena, bere entzulearen sarbide sarekoa eta HTTP edo SOCKS zerbitzuaren beraren sarbide-politika. SSH saio-hasierak tunelaren sortzailea autentifikatzen du; ez du entzule partekatu baten geroagoko deitzaile bakoitza autentifikatzen ez eta SOCKS pasahitz erronkarik gehitzen.
Urruneko deitzaile batek oraindik konektatu ezin badu, bete hurrenkera honetan: bind helbidea, zerbitzariaren birbidalketa-murrizketak eta suebakiaren bidea. TCP entzulera iritsi ondoren, proxyaren eskuko soinketa huts egitea geroagoko arazoa da.