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

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

  • Next message: James W. Thompson, II: "Re: Six GMail Invites, First come, First Served!"
    Date: Fri, 25 Jun 2004 21:56:33 +0800
    To: debian-user@lists.debian.org
    
    

    Will Trillich wrote:

    >On Fri, Jun 25 at 01:24PM +0800, John Summerfield wrote:
    >
    >
    >>Will Trillich wrote:
    >>
    >>
    >>>On Fri, Jun 25 at 11:46AM +0800, John Summerfield wrote:
    >>>
    >>>
    >>>>Will Trillich wrote:
    >>>>
    >>>>
    >>>>>can linux have multiple 127.0.0.1 interfaces? if so, how?
    >>>>>
    >>>>>
    >>I'm not talking to myself, I'm talking to someone else. Therefore I
    >>shouldn't use a local interface.
    >>
    >>
    >
    >i think one of us doesn't understand the problem solved by
    >port-forwarding...?
    >
    >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.

    > client
    > 192.168.9.9
    > |
    > 192.168.0.1
    > client firewall
    > 11.22.33.44
    > |
    > | internet
    > |
    > 22.44.66.88
    > server's firewall
    > 10.1.1.1
    > |
    > 10.1.2.3
    > server
    >
    >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.

    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.

    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.

    >
    >
    >>There's no objection to using eth0:${n}, and you can also use dummy:
    >>
    >>How many do you want?
    >>for n in 1 2 3 4 5 6 7 8 9; do ifconfig dummy0:$n 192.168.19.${n};done
    >>
    >>
    >
    >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.

    _I_ would use the IP address of an existing interface. Servers can
    generally accept many requests to the one port and IP address.

    On this box, I can address my webserver with either of these IP addresses:
    summer@Dolphin:~$ ifconfig | grep inet
              inet addr:192.168.9.114 Bcast:192.168.9.255 Mask:255.255.255.0
              inet addr:127.0.0.1 Mask:255.0.0.0
    summer@Dolphin:~$

    Whether I actually get the same content depends on the configuration of
    the web server, but that's a topic for another time.

    -- 
    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: James W. Thompson, II: "Re: Six GMail Invites, First come, First Served!"

    Relevant Pages

    • Re: What doesnt lend itself to OO?
      ... >>server is a pure data transfer interface. ... essentially exposing the client or service implementation. ... >>paradigms can be abstracted just like any other problem space in an OO ...
      (comp.object)
    • Re: What doesnt lend itself to OO?
      ... The whole idea that a subsystem is just ... > The first line exists in the server. ... objects between client and server i.e. as far as the client code is ... > external interface is the traditional input interface whose ...
      (comp.object)
    • Re: What doesnt lend itself to OO?
      ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
      (comp.object)
    • Re: What doesnt lend itself to OO?
      ... >> The problem with stateless programming is that it turns object ... > server is a pure data transfer interface. ... So the client should be ...
      (comp.object)
    • Re: What doesnt lend itself to OO?
      ... > A pure data transfer interface consists of messages that have a message ... > essentially exposing the client or service implementation. ... stateless ones like web services etc look like ... I was using the IT view of client/server where the server ...
      (comp.object)