SSH SOCKS: conexiune refuzată la deschiderea unui canal
Citiți erorile canalului de redirecționare dinamică SSH ca eșecuri ale conexiunii ulterioare solicitate, nu ca pe o dovadă că ascultătorul SOCKS local nu a pornit niciodată.
channel 5: open failed: connect failed: Connection refused se referă la o conexiune ulterioară deschisă de pe serverul SSH. Atât un ascultător SOCKS local, cât și o autentificare SSH reușită pot funcționa când acel canal eșuează.
Traseul are trei capete: aplicația contactează ascultătorul SOCKS local, sesiunea SSH duce cererea la server, iar serverul deschide conexiunea de destinație solicitată.
| Eșecul canalului | Următoarea verificare |
|---|---|
| Interdicție administrativă | Dacă serverul SSH permite operațiunea de redirecționare solicitată |
| Conexiune ulterioară refuzată | Gazda, portul și ascultătorul destinației solicitate, așa cum sunt accesibile de pe serverul SSH |
Un serviciu accesibil de pe laptop poate lipsi sau poate fi inaccesibil de pe acel server. O destinație loopback aparține tot mașinii care deschide conexiunea ulterioară; nu se referă automat la laptop.
Corelați evenimentul canalului cu cererea de care aveți nevoie. O pagină poate solicita multe destinații, iar refuzul unei resurse opționale nu înseamnă neapărat că întreaga pagină a eșuat.
Dacă octeții nu se potrivesc acestui traseu, verificați modul de redirecționare. O redirecționare fixă duce traficul la serviciul configurat; o redirecționare dinamică acceptă cereri de destinație SOCKS. HTTP trimis unui ascultător SOCKS, sau SOCKS trimis unei redirecționări fixe de server web, eșuează la o altă graniță de protocol.
Notați separat ascultătorul local, punctul final SSH și destinația solicitată. Asta arată care parte are nevoie de atenție; schimbarea portului local nu poate porni un serviciu la distanță lipsă.