Kodėl atvirkštinio SSH tarpinio serverio klausytojas pasiekiamas tik serveryje
Prieš keisdami tarpinio serverio protokolą ar prisijungimo duomenis, patikrinkite nuotolinio klausytojo bind adresą ir GatewayPorts režimą.
Nuotolinis persiuntimas gali veikti iš SSH serverio, bet atmesti jungtis iš kitos mašinos, nes klausosi tik loopback. Pirmiausia patikrinkite tikrąjį klausymosi adresą.
Serverio pusėje GatewayPorts | Nuotolinio persiuntimo bind |
|---|---|
no, numatytasis | Apriboja klausytojus iki loopback |
yes | Priverčia naudoti wildcard bind |
clientspecified | Leidžia klientui prašyti konkretaus bind adreso |
Vienam valdomam sąsajai skirtam klausytojui serveris gali naudoti:
GatewayPorts clientspecified
Tada klientas prašo tinkamo adreso savo -R specifikacijoje. Tas adresas turi egzistuoti nuotolinėje mašinoje, o kiti persiuntimo apribojimai vis dar galioja. Kliento pusėje esantis -g nėra keičiama valdymo priemonė šiai krypčiai.
Trys leidimai išlieka atskiri: SSH įgaliojimas sukurti persiuntimą, tinklo prieiga prie jo klausytojo ir pačios HTTP ar SOCKS paslaugos prieigos politika. SSH prisijungimas autentifikuoja tunelio kūrėją; jis neautentifikuoja kiekvieno vėlesnio bendro klausytojo iškvietėjo ir neprideda SOCKS slaptažodžio iššūkio.
Jei nuotolinis iškvietėjas vis dar negali prisijungti, šia tvarka patikrinkite bind adresą, serverio persiuntimo apribojimus ir ugniasienės kelią. Kai TCP pasiekia klausytoją, nepavykęs tarpinio serverio rankos paspaudimas yra vėlesnė problema.