From: Ola Lundqvist (opal_at_debian.org)
Date: Mon 01 Dec 2003 - 07:44:34 GMT
Hi
Another problem that occurs (I can not see that it fit this
really) is the following:
Assume that we have access to several networks (using 1+ network interfaces)
from the vserver handler. The vserver handler should have access to
(at least) one, that no other have access to and should have a specific
default gateway.
Each other vserver (or similar) should then have the ability to use
an alternative default gateway. That can be useful sometimes.
We have:
An example:
handler:
address 192.168.0.1
gw 192.168.0.254
v1:
address 10.0.0.1
gw 10.0.0.254
v2:
address 10.0.0.1
gw 10.0.0.254
etc...
It would be nice if I could set the default gateway in the
vserver configuration and that the iproute2 things it properly
set up then.
In this case I think a) below would be a good case. But b can also
be acceptable.
Observe that ping often work in similar cases. The real problem is
to use TCP or UDP. That is more tricky.
Regards,
// Ola
On Sat, Nov 29, 2003 at 04:26:45PM +0100, Herbert Poetzl wrote:
>
> Hi Folks!
>
> did some iproute2 testing with vserver, and
> discovered that some setups will not do
> what you might expect (I guess this will
> explain some questions on the mailing list
> regarding routing with more than one gateway)
>
>
> for the following examples I assume that no
> network configuration has been done, so you
> might need to adjust for your setup:
>
> scenario: two networks 192.168.0.0/24 and
> 10.0.0.0/16 with default gateways 192.168.0.1
> and 10.0.0.1 (our host can use .2 and .3)
>
> # ifconfig eth0 192.168.0.2
>
> # ip route add 192.168.0.0/24 dev eth0 table 100
> # ip route add default via 192.168.0.1 dev eth0 table 100
> # ip rule add from 192.168.0.0/24 table 100
>
> basically this configures routing for the first
> network, which is only used, if the packet
> originated from 192.168.0.0/24 ...
>
>
> reaching the gateway:
>
> # ping -c 1 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) from 192.168.0.2 : 56(84) bytes of data.
> 64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=4.610 msec
> 1 packets transmitted, 1 packets received, 0% packet loss
>
> our own address:
>
> # ping -c 1 192.168.0.2
> connect: Invalid argument
>
> this might be unexpected, but can easily be
> explained and solved ... to ping the host,
> we need a local loopback device, hence ..
>
> # ifconfig lo 127.0.0.1
>
> will solve this issue.
>
> something on the net:
>
> # ping -c 1 128.130.2.3
> connect: Network is unreachable
>
> why 'Network is unreachable' you might ask?
> simple because the source address is 0.0.0.0
> and we did not specify a default
>
> and now with vserver:
>
> # chbind --ip 192.168.0.2 ping -c 2 128.130.2.3
> PING 128.130.2.3 (128.130.2.3) from 192.168.0.2 : 56(84) bytes of data.
> 64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=12.320 msec
> ...
>
> to our surprise, this is able to reach the
> destination, and more surprisingly ...
>
> # chbind --ip 192.168.0.2 --ip 192.168.0.3 ping -c 2 128.130.2.3
> connect: Network is unreachable
>
> will fail, as the 'original' attempt did.
>
> what happened, is it a bug? can we use that?
>
> basically, it isn't a bug, but it definitely
> is unexpected behaviour ... the explanation
> lies in the source, and the way ping works ...
>
> ping first creates two socket()s one for ICMP
> (a raw socket) and one for IP (UDP), to send
> and receive the the packets ... the latter is
> connect()ed with src=0.0.0.0 and the dest.
> address used in the ping, which explains the
> 'Network is unreachable' cases, but not the
> success of chbind/ping with one ip ...
>
> the current implementation of connect, tries
> to be 'smart' and replaces the 0.0.0.0 with
> the source address configured for the vserver,
> if and only if it has only one ip assigned ...
>
> why this long explanation:
>
> I think, we should change/adapt this behaviour
> as it will inevitably lead to some problems
> if you want to use more than one gateway, and
> connect() from inside the vserver to somewhere
> outside the local net ...
>
> # ifconfig eth0:1 10.0.0.2
>
> # ip route add 10.0.0.0/16 dev eth0 table 101
> # ip route add default via 10.0.0.1 dev eth0 table 101
> # ip rule add from 10.0.0.0/16 table 101
>
> will allow you to serve requests from outside
> the server, reaching either 10.0.0.2 or
> 192.168.0.2 via the configured gateways but
> you won't be able to ssh/telnet/ftp from a
> vserver started with two or more IPs ...
>
> what I would suggest:
>
> Basically I see two options, to solve this
> without too much confusion and/or magic
>
> a) we 'define' that the first IP assigned
> to a vserver, is the one to be used for
> 'outgoing' connects, regardless of the
> routing setup (or at least as fallback,
> if using 0.0.0.0 fails)
>
> b) we add a 'source' address to the vserver
> config, which by default, is 0.0.0.0 and
> can be assigned some other ip (probably
> restricted to IPs from the config array)
>
> please let me know what you think, and which
> direction you would prefer ...
>
> TIA,
> Herbert
>
>
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
-- --------------------- Ola Lundqvist --------------------------- / opal_at_debian.org Annebergsslingan 37 \ | opal_at_lysator.liu.se 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver