SSH SOCKS-oerstjoering stiet apart fan TUN-apparaatflaters
Werken in oprjochte SOCKS-luisterder sels as deselde SSH-sesje letter gjin apart TUN-apparaat meitsje kin.
Dizze beide waarnimmings kinne njonkeninoar bestean yn ien SSH-log:
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.De earste giet oer in dynamyske SOCKS-luisterder. De twadde giet oer in tunnelnetwurkapparaat. It binne aparte oerstjoerfersiken.
OpenSSH brûkt -D foar dynamyske oerstjoering op applikaasjenivo en -w foar tunnelapparaten. In Tunnel-ynstelling kin it lêste ek fia konfiguraasje opfreegje. It net krijen fan de rjochten of servertastimming foar in TUN-apparaat bewiist op himsels net dat de eardere SOCKS-luisterder nea oanmakke is.
Lês wat slagge foar de flater: SSH-autentikaasje, it oanmeitsjen fan de luisterder en elk letter fersyk foar in bestimmingskanaal. In harkjende SOCKS-poarte hat noch altyd in kompatibele klant en in berikber, tastien bestimming nedich. It is bewiis oer ien stadium.
As it bedoelde wurk allinnich SOCKS-oerstjoering is, ûndersykje dan wêrom't der oait in tunnelapparaat opfrege is. In beheinde konfiguraasje kin dat net-relatearre fersyk útskeakelje:
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]Hâld de gewoane SSH-hostkaai- en akkountkontrôles. Der is gjin reden om netwurkapparaatrjochten te jaan allinnich om in flater stil te meitsjen foar in funksje dy't de SOCKS-route net nedich hat.