Distcc Help. Setting Up A VPN. - BSD

This is a discussion on Distcc Help. Setting Up A VPN. - BSD ; Hi! I was going to cluster my 4 FBSD boxes using Distcc. Some of my friends and I got together and decided to pull our resources a la cpu cycles and combine them all. Instead of my 4 boxes we ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Distcc Help. Setting Up A VPN.

  1. Distcc Help. Setting Up A VPN.

    Hi!

    I was going to cluster my 4 FBSD boxes using Distcc. Some of my friends and I got together and decided to
    pull our resources a la cpu cycles and combine them all. Instead of my 4 boxes we now have 21 computers.

    Inet is toooo freaking slow! Anyone knows how to create routing tables for each VPN?

    Yeah, I know what you're thinking, why not use one box/switch/routers for all 21 computers. That COULD pose
    a security problem and nobody wants to do it that way.

    I have a feeling that I'm over analyzing everything and this is basic stuff that should be simple to setup. I have
    a tendency to over-complicate everything.

    How do you and your friends cluster your boxes?

    Thanks in advance.





  2. Re: Distcc Help. Setting Up A VPN.

    Begin <5_ORj.570$Q97.241@newsfe07.lga>
    On Wed, 30 Apr 2008 00:23:29 GMT, Timmy wrote:
    [line lengths fixed]
    > Inet is toooo freaking slow! Anyone knows how to create routing tables
    > for each VPN?


    Several ways, actually. You can start with route(8) to do it manually,
    then move on to routed(8) to use RIPv2[1], or install something like
    quagga from ports to run OSPF. This progressively gets trickier and
    will require quite a bit of reading to understand what it is all about.

    It's an interesting opportunity to learn something about networking,
    but it won't necessairily make your slow internet faster. To see why,
    consider two things:

    First, crypto is computation heavy. Edge boxes with crypto accelleration
    could help here.

    Second, if your links are asymmetrical, consider that any traffic from
    your friends in your fat downstream will have to have passed through the
    other side's tiny upstream. You get at most the lowest speed of all the
    links in the network path. In scenarios like yours the two ``last mile''
    ends (and for ADSL specifically, the upstreams) are likely the slowest
    links in the path.

    If you want faster networking, you could upgrade your links, or if
    your friends are close enough, provide your own. Solutions might
    involve wireless links like the usual wifi (see also: cantenna) or the
    build-it-yourself RONJA, or possibly a bit of cable and a suitable
    networking technology (but beware of ground loops and lightning strikes).


    > Yeah, I know what you're thinking, why not use one box/switch/routers
    > for all 21 computers. That COULD pose a security problem and nobody
    > wants to do it that way.


    I think security is the least of your worries there. While it is one
    way to reduce the complexity, it creates an unnecessairy single point
    of failure. There is a better way to reduce the number of VPN links
    required.

    What is usually done is trust the local network and have a device ``on
    the edge'' that will provide VPN tunnels to other such networks to
    connect all machines in the network at once, instead of one at a time.
    This is much simpler than trying to have N computers setup VPNs to N-M
    other computers (where M is the number of machines in the local network
    that don't need a VPN link). To see why, count the number of networks,
    and count the number of machines in each network. Then count the number
    of VPN links needed in each case.


    > I have a feeling that I'm over analyzing everything and this is
    > basic stuff that should be simple to setup. I have a tendency to
    > over-complicate everything.


    I used to think that too. I often was, but I also often was just plain
    wrong in my assumptions, and as I gained understanding of what was
    really going on, I learned to separate this problem from other problems
    in a way that made it solvable, and then solve them one at a time.


    And something about line lengths.


    [1] RIP(v1) is outdated (excercise: find out why). RIPv2 got updated
    and might be just the thing to get started with learning how
    dynamic routing protocols work in practice.

    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: Distcc Help. Setting Up A VPN.

    On 30 Apr 2008 08:36:26 GMT
    jpd wrote:

    > Begin <5_ORj.570$Q97.241@newsfe07.lga>
    > On Wed, 30 Apr 2008 00:23:29 GMT, Timmy wrote:
    > [line lengths fixed]
    > > Inet is toooo freaking slow! Anyone knows how to create routing
    > > tables for each VPN?

    >
    > Several ways, actually. You can start with route(8) to do it manually,
    > then move on to routed(8) to use RIPv2[1], or install something like
    > quagga from ports to run OSPF. This progressively gets trickier and
    > will require quite a bit of reading to understand what it is all
    > about.
    >
    > It's an interesting opportunity to learn something about networking,
    > but it won't necessairily make your slow internet faster. To see why,
    > consider two things:
    >
    > First, crypto is computation heavy. Edge boxes with crypto
    > accelleration could help here.
    >
    > Second, if your links are asymmetrical, consider that any traffic from
    > your friends in your fat downstream will have to have passed through
    > the other side's tiny upstream. You get at most the lowest speed of
    > all the links in the network path. In scenarios like yours the two
    > ``last mile'' ends (and for ADSL specifically, the upstreams) are
    > likely the slowest links in the path.
    >
    > If you want faster networking, you could upgrade your links, or if
    > your friends are close enough, provide your own. Solutions might
    > involve wireless links like the usual wifi (see also: cantenna) or the
    > build-it-yourself RONJA, or possibly a bit of cable and a suitable
    > networking technology (but beware of ground loops and lightning
    > strikes).
    >
    >
    > > Yeah, I know what you're thinking, why not use one
    > > box/switch/routers for all 21 computers. That COULD pose a security
    > > problem and nobody wants to do it that way.

    >
    > I think security is the least of your worries there. While it is one
    > way to reduce the complexity, it creates an unnecessairy single point
    > of failure. There is a better way to reduce the number of VPN links
    > required.
    >
    > What is usually done is trust the local network and have a device ``on
    > the edge'' that will provide VPN tunnels to other such networks to
    > connect all machines in the network at once, instead of one at a time.
    > This is much simpler than trying to have N computers setup VPNs to N-M
    > other computers (where M is the number of machines in the local
    > network that don't need a VPN link). To see why, count the number of
    > networks, and count the number of machines in each network. Then
    > count the number of VPN links needed in each case.
    >
    >
    > > I have a feeling that I'm over analyzing everything and this is
    > > basic stuff that should be simple to setup. I have a tendency to
    > > over-complicate everything.

    >
    > I used to think that too. I often was, but I also often was just plain
    > wrong in my assumptions, and as I gained understanding of what was
    > really going on, I learned to separate this problem from other
    > problems in a way that made it solvable, and then solve them one at a
    > time.
    >
    >
    > And something about line lengths.
    >
    >
    > [1] RIP(v1) is outdated (excercise: find out why). RIPv2 got updated
    > and might be just the thing to get started with learning how
    > dynamic routing protocols work in practice.
    >

    Thanks for the advice JPD.
    Clustering is much more difficult than I thought - Nonetheless, I'm
    going to figure it out. I'm starting on it now using VPN. No doubt I
    will soon be back with questions. Hope you're around.

+ Reply to Thread