Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
Will Trillich wrote:
On Fri, Jun 25 at 09:56PM +0800, John Summerfield wrote:
Will Trillich wrote:
turns out the vast majority of these connections will be coming
from beyond a remote firewall (remote from where the server is
located on the 'net):
Cool. That's the problem tunneling (port forwarding) solves. So does
openvpn, but more generally: it can make two lans separeted by the
hostile Internet seem to be one.
vpn is a very clever use of resources, and an amazing boost in
convenience 1) once it's set up [much heavy lifting there
requiring much expertise when things aren't Just Quite Right]
and 2) even tho it provides lots more functionality [i.e.
security issues] than most folks usually need, and is certainly
the case here when we only need one tcp port to do the dirty
work and 3) are typically better suited for long-term lan-to-lan
connections than transient solitary-pc-to-lan connections.
Openvpn is very easy to set up, and I'd be surprised if you couldn't do
it in an hour or so. Unless you want the beta (and that actually is
likely), it's basically "apt-get install" then read the docs, create a
secrets file which you copy to the other side, then edit the config files.
Here is a working configuration:
dev tun
remote office.example.com
resolv-retry infinite
ifconfig 192.168.7.254 192.168.4.253
route 192.168.0.0 255.255.255.0 192.168.4.253
route 192.168.1.0 255.255.255.0 192.168.4.253
route 192.168.4.0 255.255.255.0 192.168.4.253
secret coco.key
port 5000
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb 3
the server can't open a port on the client machine, cuz it
can't get past the client firewall. the client CAN ssh past
the server virewall (that's how the latter is set up) to the
server itself and establish a remote-to-local forwarding
rule. if the server can be made to chat with a localhost
interface using a port to match the forwarding setup, it will
work -- for one user per loopback interface.
I don't understand why the server would be making the
connexion request. By definition, the client does that.
aha -- suddenly i become the teacher.
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.
This has lead to some security problems: I send you a port command to
connext to Monique...
MOST traffic, by far, is initiated by a client that connects to a
server. but sometimes there's an instance (quickmate from
janzabar in this case) where after the main connection is
established, the user activates a function on the server, and the
server initiates another connection to the client -- in this
instance to activate the quickmate menu. quickmate opens the
local/client port, listening for instructions from the server;
when the server says (at the user's request) "do this menu" it
pops up and away we go.
in fact, until yesterday, i myself wondered when you would
possibly ever need a remote-to-local connection. voila! here's
one (perhaps the very single only one ever, in the entire history
of the universe, since the dawn of time, ever).
I could concoct a few other uses.
Here's what openvpn does:
traceroute to 192.168.1.252 (192.168.1.252), 30 hops max, 38 byte packets
1 ns (192.168.9.4) 0.359 ms 0.226 ms 0.209 ms
2 gw (192.168.9.1) 0.413 ms 192.168.7.254 (192.168.7.254) 0.929 ms
0.552 ms
3 192.168.1.252 (192.168.1.252) 1058.580 ms 1103.616 ms 1066.529 ms
summer@Dolphin:~$
The internet is between 2 & 3. I can see all hosts on 1.x and
other networks it can route to, and they can see me. Of
course, I can add rules to the firewalls, and I could use
NAT.
vpn is way cool, no doubt. if we had one in this case, you're
right -- this would all be moot. and maybe someday in the
future, politics permitting, that will happen. i hope so.
for now, we ssh with tcp ports tunnelled all over creation. :)
I think we're going to have half-a-dozen or so vpns. It has also crossed
my mind this is a technique that can secure wireless: my AP only listens
to UDP traffic, on port 5000. It's encrypted and if you don't share a
secret with me, your traffic gets dropped.
<plonk>
I'm running openvpn on gw at my end (my firewall, a Powermac running
Woody) and the host at the other end is inside the firewall, a
commercial ADSL router.
Using ssh the way _I_ described. I can connect from my system at home to
hosts at work. In the specific example I gave, I could connect to the
webserver on 127.0.0.1.
With this command:
ssh -L 8088:192.168.4.254:80 192.168.1.252
if I open my browser on http://127.0.0.1:8088/ then ssh forwards the
connexion request to 1.252 and from there makes a connextion request to
port 80 on 192.168.4.254 which could be an ADSL router. The router would
see the request as coming from 1.252.
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.
:)
similarly to your setup, i've got my firewall at home set to
forward ssh requests to my debian server; then i have my roving
ssh laptop configured to connect to the mother ship (server in
my basement) port-forwarding :8888 back to the firewall for
seeming-to-be-from-inside-the-lan administrative configuration.
ssh -L:8888:192.168.0.1:80 home.server.net.addr
then i http://localhost:8888/ and administer my firewall "from
inside" even tho i'm miles from home. tres kewl!
about those dummy interfaces... can they be made into loopback
devices? and if so, how?
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.
unless the server port is forwarded elsewhere, in which case the
server THINKs it's talking to itself (just as the client
normally does) but the traffic actually wormholes through to the
client end of the connection.
just like "ssh -L port:host:port" but in reverse -- instead,
it's "ssh -R port:host:port". instead of the client forwarding
its local ports to the server, we get the server to forward its
local ports to the client. grok?
_I_ would use the IP address of an existing interface. Servers can
generally accept many requests to the one port and IP address.
just as the client can accept many incoming request to any
particular port. but only one process can open the port for
listening purposes. the port is open for listening on the
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.
--
Cheers
John
-- spambait
1aaaaaaa@computerdatasafe.com.au Z1aaaaaaa@computerdatasafe.com.au
Reply to: