Ինչու հակադարձ SSH-փրոքսիի լսիչը հասանելի է միայն սերվերում

Նախքան փրոքսիի արձանագրությունը կամ հավատարմագրերը փոխելը ստուգեք հեռավոր լսիչի bind հասցեն և GatewayPorts ռեժիմը։

Հեռավոր փոխանցումը կարող է աշխատել SSH սերվերից, բայց մերժել մեկ այլ մեքենայից եկող միացումները, որովհետև լսում է միայն loopback-ում։ Նախ ստուգեք լսելու իրական հասցեն։

Սերվերի կողմում GatewayPortsՀեռավոր փոխանցման bind
no, լռելյայնԼսիչները սահմանափակում է loopback-ով
yesՊարտադրում է wildcard bind
clientspecifiedԹույլ է տալիս հաճախորդին պահանջել կոնկրետ bind հասցե

Մեկ վերահսկվող ինտերֆեյսի համար նախատեսված լսիչի համար սերվերը կարող է օգտագործել՝

GatewayPorts clientspecified

Այնուհետև հաճախորդը պահանջում է համապատասխան հասցե իր -R ճշգրտման մեջ։ Այդ հասցեն պետք է գոյություն ունենա հեռավոր մեքենայում, և փոխանցման մյուս սահմանափակումները դեռ գործում են։ Հաճախորդի կողմի -g այս ուղղության համար փոխանակելի կառավարում չէ։

Երեք թույլտվություն մնում են առանձին՝ SSH լիազորումը փոխանցումը ստեղծելու համար, ցանցային հասանելիությունը դրա լսիչին, և HTTP կամ SOCKS ծառայության սեփական մուտքի քաղաքականությունը։ SSH մուտքը նույնականացնում է թունելի ստեղծողին, բայց չի նույնականացնում համօգտագործվող լսիչի յուրաքանչյուր հետագա կանչողի և SOCKS գաղտնաբառի մարտահրավեր չի ավելացնում։

Եթե հեռավոր կանչողը դեռ չի կարողանում միանալ, այս հերթականությամբ ստուգեք bind հասցեն, սերվերի փոխանցման սահմանափակումները և firewall-ի ուղին։ Երբ TCP-ն հասնի լսիչին, ձախողված փրոքսի ձեռքսեղմումը ավելի ուշ լուծվող խնդիր է։

Առնչվող հոդվածներ