|
Questions
tsocks doesn't seem to be working for SSH, why?
tsocks can be used a number of ways, the most common being the LD_PRELOAD
environment variable. When set (often through a script) this requests that
the system dynamic loader load tsocks into each process before execution
of the process begins. This allows tsocks to redirect calls to standard
networking functions to force them to be socksified.
Unfortunately LD_PRELOAD simply doesn't work for setuid programs when the
user running the program is not the same as the owner of the executable. This
is because being able to load code into a privileged executable would be a
major security flaw. To fix this problem you may wish to removed the setuid
bit from SSH (this will force it not to use privileged TCP ports, disable
some forms of RSA authentication to older servers and may have other effects).
Alternatively you might wish to force tsocks to be loaded into all processes
using the /etc/ld.so.preload file, for more information please see the tsocks
man page.
tsocks doesn't seem to be working for ftp, why?
tsocks can only socksify outgoing connection requests from applications,
in ftp there are normally two channels, one is made from the client to the
server (called the control channel) and another from the server back to the
client (called the data channel). If a SOCKS server is between the client
and the server the server will incorrectly try to connect back to the SOCKS
server rather than the client. Thus the data channel connection will be fail
(not that it would likely succeed even if it did try to connect back to the
correct client, given the SOCKS server is probably firewalling the network off).
The simplest solution to this problem is to use passive mode ftp, in this form
of ftp all connections are made from the client to server, even the data
channel. Most ftp clients and servers support passive mode, check your
documentation (as a tip the Linux command line ftp client uses passive mode
when invoced with the -p option)
I keep getting an error like "SOCKS server is not on a local subnet!", what's going on?
By definition SOCKS servers in the tsocks configuration file must be on
networks specified by a "local" subnet statement. Remember that a 'local'
subnet doesn't describe a subnet that the machine is directly attached to
but rather networks that the machine can reach without the aid of any SOCKS
server (thus such networks are "local" networks).
When you think about it, if a SOCKS server were on a network that wasn't local
then you would need a SOCKS server in order to be able to reach the SOCKS
server (which can actually occur in some strange networks but tsocks doesn't
yet support that sort of network).
To fix your problem just define the network your SOCKS server is on in a local
subnet statement.
make install doesn't seem to honor the --prefix when
installing libtsocks.so
This is a very common question even though it is repeatedly discussed in
the README and INSTALL files. The installation step does not honor
prefix when installing the tsocks library deliberately. The reason
for this is that the default path (i.e /lib) is certain to be on the root
partition. This is important when tsocks is added to the
/etc/ld.so.preload file, if the library weren't in the root filesystem
when the machine next rebooted processes that are part of the boot
sequence before all of the filesystems are mounted would try to find the
library, fail then crash, effecively killing the machine. So, for
safeties sake the installation path for the library can only be modified
using the --libpath option to configure.
Does tsocks support receiving connections via SOCKS? (i.e the SOCKS
BIND operation)
The first version of SOCKS, version 4, only provided support for making
connections out through a socks proxy, i.e the SOCKS CONNECT operation.
Later an extension was made that allowed for connections to be received
through a SOCKS proxy called the SOCKS BIND operation. tsocks only
supports the CONNECT operation (when working with both version 4 and 5
servers). Extending it to provide BIND support wouldn't be
extraordinarily difficult, but it wouldn't be trivial either. Given that
I have no use for this functionality and that there appears to be no real
demand for it, I don't intend to implement it. I would of course welcome
a contributed patch which adds the support.
|
