Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
Will Trillich wrote:
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.
That's standard terminology.
Also, some server software (sendmail is an example) makes a client
request to a connecting host to discover the identity of its client. The
server is identd (service auth).
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.
It is. As I alreadt explained, it's talking to a proxy server (ssh) on
your machine. How the server satisfied the request is irrelevant.
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.
No, it's getting it from a client on _its_ local host. Whether the
client is sshd (as in this case) or the client program in your hands is
irrelevant.
So far as you're concerned, the server is on your peecee.
OTOH quickmate sees its client as being on the same hardware it's
running on.
same thing, different direction.
THAT's what i'm talking about.
Best you become accustomed to standard terminology. The "Using C on the
UNIX System" book has sample code to illustrate my point.
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!
Did you check the book? There are other documents you could check: I
once had documents on client/server programming in REXX (and did some),
and Perl has heaps of support for it.
See this illustration:
summer@Dolphin:~$ ssh -L2022:127.0.0.1:22 192.168.1.121
Linux Echidna 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown
No mail.
Last login: Tue Jun 29 21:50:05 2004 from 192.168.9.114
summer@Echidna:~$
and then
summer@Dolphin:~$ ssh -p 2022 127.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
<snip>
Linux Echidna 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown
No mail.
Last login: Wed Jun 30 08:00:52 2004 from 192.168.9.114
summer@Echidna:~$ w
08:01:25 up 6 days, 20:28, 3 users, load average: 0.04, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/18 localhost 23Jun04 42:35m 0.14s 0.14s -bash
summer pts/20 192.168.9.114 08:00 33.00s 0.05s 0.05s -bash
summer pts/24 localhost 08:01 0.00s 0.08s 0.05s w
summer@Echidna:~$
The connexion from 192.168.9.114 is the first above. summer's connexion
from localhost is the second. the "From" column is the client end, and
quickmate sees it in exactly the same way.
--
Cheers
John
-- spambait
1aaaaaaa@computerdatasafe.com.au Z1aaaaaaa@computerdatasafe.com.au
Reply to: