Chris Davies <chris-use...@roaima.co.uk> writes:

> lee <l...@yun.yagibdah.de> wrote:
>> That seems to suggest using a bridge[1], and I find that very
>> confusing. I understand that apparently I am supposed to replace my
>> currently used eth1 by a bride device which uses eth1 and to which I
>> could add other physical devices like eth0. I don't understand what the
>> purpose of adding more physical devices would be and what I actually
>> get when I have such a bridge device and what all that has to do with
>> a guest.
>
> Ah. Consider a bridge to be a software implementation of a network switch.
>
> Currently your networking subsystem refers to eth1, which represents the
> NIC itself. With a bridge, your networking subsystem would refer to a
> bridge called br1 (say), and the bridge would connect to your eth1. (The
> bridge name is completely arbitrary; you could call it eth3 if you really
> wanted to.)
>
> The reason you would use a bridge is because then each of your VMs could
> also connect to the bridge and therefore to eth1, and your host system
> and each of the VMs would have separate IP addresses, etc.

Still I can't imagine this :(  When I look at the drawing on [1], I see
that it doesn't apply because I do not have a configuration like that.
I have only eth1 connected to the internet (the router actually, but
that doesn't make a difference for this).

I do not want to bridge the internet transparently with the local
network, which seems to be what a bridge would do.  It would be like
replacing this:


                                      |--- host A
   Internet --- eth0 firewall eth1 ---|--- host B
                                      |--- host N


with this:


                               |--- con1 --- host A
   Internet --- con0 switch ---|--- con2 --- host B
                               |--- conN --- host N


"con*" stands for the connector on the switch where I plug in the
network cable.

The difference to a switch would be that the switch doesn't show up
because it works transparently.

What I actually have is that:


   Internet A (not in use)

   Internet B --- router w/ FW |--- eth1 host A w/ shorewall
                               |--- ethX or wireless host B
                               |--- ethX or wireless host N

What I want is this:


   Internet B --- router w/ FW --- eth1 host w/ shorewall xxx --- guest


"xxx" is a placeholder for some way to connect the guest which runs on
the host.

Ideally, I would bundle "Internet A" and "Internet B" to increase the
available bandwidth.  It seemed to be so complicated that it didn't
appear worthwhile, given that "Internet A" is very slow.  It is possible
to plug "Internet B" into eth0 (and run pppd on the host) while it's not
possible to plug "Internet A" into the host (because it's ADSL coming
over an ISDN phone line, so it has to come over the router).  I have an
Intel e100 card laying around with two ports, so physical network
interfaces can be plenty :)  The router can get internet either through
the phone line or through an ethernet port.  It only really needs that
when wireless is in use, which it usually isn't.

So I could have something like that:


   Inet A --- router ---|
                        | --- eth0 & eth1 host A w/ shorewall eth2
   Inet B --------------|                                        |
                                                                 |
                                                                 |
                           |-----------------|-----------|-------|
                           |                 |           |
                        host B            host C       guest on A


... if that isn't too complicated :)


[1]: http://www.shorewall.net/SimpleBridge.html


>> It seems to me that having the bridge device in theory would somehow
>> magically enable me to give the guest an IP address in the same network
>> as the host is.
>
> The guest would become visible to your network as a distinct entity
> to the host, and could get an address using DHCP (if your network uses
> this), etc.

Then how do I get it behind the firewall?  It doesn't have a network
interface and even the host won't have one anymore.

I suspect what gives me trouble might be that I would take away a
network interface and replace it with some sort of unknown mess (the
bridge, which is some sort of melting pot) that somehow can have any IP
address it wants.  That totally removes the order of things and leaves
me without a handle (a network interface).

>> That isn't what I want because I want the guest behind the firewall
>> which is on the host (using shorewall).
>
> This is actually two unrelated things that you've squashed together. It
> is completely possible for the host's firewall to restrict access to
> a guest, regardless of whether the guest is hidden by the host or it
> appears as an independent system on your network.

How can that be when they are like plugged into a switch, side by side?
The switch they are plugged in is directly connected to the internet
(the router) since the network cable is plugged into it as well.

> If you are going to use bridging, though, you do need to tell shorewall
> about it. See http://www.shorewall.net/SimpleBridge.html

This example seems to be something very different.  It bridges eth1 and
eth2 transparently and uses eth0 to connect them to the internet through
a firewall.  In my case, there is only one physical interface involved
which would be replaced by the bridge itself, which itself is connected
to the internet without anything in between.  That seems to make it
impossible to separate hosts from the internet and from each other
because the bridge transparently melts everything together into one
network.

What am I missing?

Wouldn't it be much easier if I replaced eth0 with a bridge device so
that shorewall has two interfaces to work with?  I would keep eth1 as is
now and simply add rules for the bridge device which uses eth0?  And
since both eth0 and eth1 are physically installed on the same host, I
don't need to plug a network cable into eth0?  IIRC, I did something
like that last time, but I also had some sort of tapping or tunnel thing
and I don't remember what that was for ...


-- 
Debian testing amd64


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vccwkgf....@yun.yagibdah.de

Reply via email to