Redirecționarea SSH SOCKS este separată de erorile dispozitivului TUN
Recunoaște un ascultător SOCKS stabilit chiar și atunci când aceeași sesiune SSH nu reușește ulterior să creeze un dispozitiv TUN separat.
Aceste două observații pot coexista într-un singur jurnal SSH:
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.
Prima privește un ascultător SOCKS dinamic. A doua privește un dispozitiv de rețea de tunel. Sunt cereri de redirecționare diferite.
OpenSSH folosește -D pentru redirecționarea dinamică la nivel de aplicație și -w pentru dispozitivele de tunel. O setare Tunnel poate solicita și aceasta din urmă prin configurație. Neobținerea privilegiilor sau a permisiunii serverului pentru un dispozitiv TUN nu dovedește prin ea însăși că ascultătorul SOCKS anterior nu a fost niciodată creat.
Citește ce a reușit înainte de eroare: autentificarea SSH, crearea ascultătorului și orice cerere ulterioară de canal de destinație. Un port SOCKS în ascultare are încă nevoie de un client compatibil și de o destinație accesibilă și permisă. Este o dovadă despre o singură etapă.
Dacă sarcina vizată este doar redirecționarea SOCKS, verifică de ce a fost solicitat deloc un dispozitiv de tunel. O configurație restrânsă poate dezactiva acea cerere irelevantă:
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]
Păstrează verificările obișnuite ale cheii de gazdă și ale contului SSH. Nu există niciun motiv să acorzi privilegii de dispozitiv de rețea doar pentru a înăbuși o eroare pentru o funcție de care ruta SOCKS nu are nevoie.