exactly what's needed. remote tunnelling port X to client (us)
port X. when a client connects from Out There Somewhere, the
server won't have access to the ports on the connecting client;
often it's behind a firewall, for example. so the way to work it
is to have the server talk to "localhost" (its own self) port
9999 which the ssh daemon forwards to the client machine, to
"localhost:9999". the reverse of the usual tunnelling.
I think you're tunneling thw wrong way, you should be doing this:
summer@Dolphin:~$ ssh -L8080:127.0.0.1:80 192.168.1.252
Linux mail 2.4.18-1-686 #1 Wed Apr 14 18:20:10 UTC 2004 i686 unknown
no, it's
ssh -R9999:127.0.0.1:9999 server.address.here
that seizes a port on the remote side and forwards traffic to
the local side. but the second instance of the tunnel won't be
able to seize that port of that interface address. so we need
more interfaces, even if only virtual ones...
then your client talks to port 8080 on localhost and actually connects
to port 80 on the remote host.
server needs to talk to a port on the client. it's reversed
(remote-to-local, instead of the usual local-to-remote).
Note that on 192.168.1.252 the connexions come from localhost.
This has implications for security (eg postgresql trusting
anyone from localhost) but also can solve routing hosts: the
printers, routers etc on 1.x in this example can't route to
me.
so anybody know of caveats or methods in setting up virtual
loopback interfaces? and working with them?
auto lo
iface lo inet loopback
auto lo:1
iface lo:1 inet loopback
auto lo:2
iface lo:2 inet loopback
auto lo:3
iface lo:3 inet loopback