Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)

From: John Summerfield (debian_at_ComputerDatasafe.com.au)
Date: 06/26/04

  • Next message: John Summerfield: "Re: Two-part question" 
    Date: Sat, 26 Jun 2004 20:33:02 +0800
To: debian-user@lists.debian.org

    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
-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: John Summerfield: "Re: Two-part question"