Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
On Sat, Jun 26 at 08:33PM +0800, John Summerfield wrote:
> >>I don't understand why the server would be making the
> >>connexion request. By definition, the client does that.
> >
> >it's not "by definition" -- it's "in the VAST majority of cases".
> >as in "very seldom, and it's surely suspicious behavior that
> >should be investigated by at least three government agencies at
> >the highest level, there will be a case for forwarding server
> >ports to the client, not that there's anything wrong with that."
>
> I'll stick with "by definition." ftp in active does things a little
> oddly: when the client requests a transfer, it sends the port command: I
> don't know the full details,but some of the information it provides is
> the IP address and port for ftpd to connect to to send the data. So far
> as the protocol is concerned, the server makes a client connexion
> request to the client program which in consequence becomes a server.
aha. i see your perspective -- you're calling quickmate a
server, even tho it's on the user's client-side machine. by that
arrangement, yes, it's the server.
but the tunnel is initiated locally, so we forward a remote port
to the local machine in order to accomplish our task. :)
> >aha! but, as you said:
> >
> > > You don't want loopback devices. The loopback device is
> > > for me to send messages to myself: the client and server
> > > are on the same box.
> >
> >"i'm talking to myself"! 127.0.0.1 is the loopback interface,
> >so you "don't want that"... :) unless you've got the port
> >forwarded elsewhere. right? yes? hmm?
>
> My web browser is talking to a server on my loopback device,
> yes. What the server does is respond validly to HTTP requests.
> Whether it gets the date from local store (Apache with static
> html) or generates it (Apache with CGI or PHP and a database
> backend) or entirely from across a network (as Squid does) is
> irrelevant.
>
> I'm not routing traffic from the loopback device, and that's
> what you were talking about.
ssh -L80:192.168.0.1:80 distant.server.there
lynx localhost:80
lynx thinks it's talking to its own selfsame machine, tho the
request gets beamed to 192.168.0.1 instead.
ssh -R10001:127.0.0.1:10001 distant.server.there
quickmate localhost:10001 &
quickmate thinks it's listening to locally-originating
connections, but it's gonna be getting them from the remote
end of the tunnel instead.
same thing, different direction.
THAT's what i'm talking about.
> >>You don't want loopback devices. The loopback device is for
> >>me to send messages to myself: the client and server are on
> >>the same box.
they APPEAR to be on the same box, thanks to the magic of
port-forwarding tunnels. whether it's -R (coming) or -L (going)
it's magic, either way.
> Clients do not listen and clients do not accept questions.
> That has caused most of our confusion.
>
> A TCP client uses socket() and connect(). A TCP server uses
> socket(), bind(), listen() and accept().
>
> See using C on the Unix system, O'Reilly & Assoc.
conceptually quickmate fills the definition of a client -- it
gives the user a menu to work with to converse with the remote
database server; operationally, it's serving requests to port
10001 like a server would.
and to get it to work we use a remote-to-local tunnel. works
like a dream!
--
I use Debian/GNU Linux version 3.0;
Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown
DEBIAN NEWBIE TIP #83 from Kieren Diment <kieren@mailandnews.com>
and USM Bish <bish@nde.vsnl.net.in>
:
GOT GIBBERISH? And wondering what to do next, to clear the
mess? Clear your command-line buffer with control-C (in case
you'd entered something that might be harmful), and then enter
reset
which is a symlink to /usr/bin/tset which is a portion of
"ncurses-bin" package. ("apt-get install ncurses-bin")
Also see "man tset" for more info.
Also see http://newbieDoc.sourceForge.net/ ...
Reply to: