Re: routing to ping automatically via the correct network

[Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxxx>]

On 8/7/20 6:00 PM, Marc Roos wrote:
> In this case yes
...
> In this case yes, but mostly not. I am actually having issues with
> using a macvtap of a gretap tunnel within the namespace.

Okay.  So, this is somewhat a synthetic test and MACVTAP isn't a 
complete match for the real case.  But the synthetic test otherwise 
mostly matches what you need.  Check.

> No I do not want to change the host to much.

Fair enough.

> Furthermore I think it is more secure not having task ip ranges on 
> the host.

You do have host (/32) routes.  So it's not the entire prefix.  But it's 
not nothing either.

> Just ip ranges that do not have routing to the internet.

Having an IP on the external interface doesn't mean that the internal 
IP's have access to the internet.  Particularly with RFC 1918 IPs.  ;-)

> Yes

Okay.  And you /want/ that lack of commonality.

> Yes sorry, copy typos, tables are of course for different eth. I like 
> to be able to use any network in these containers.

Fair enough.  It happens.  I wanted to make sure that's what it was and 
not some other misunderstanding on my part.

> How would this look like?

Hypothetically:  Host and netns have IPs in the same prefixes.

 host:eth0:169.254.254.0/31
netns:eth0:169.254.254.1/31

 host:eth0:169.254.254.2/31
netns:eth1:169.254.254.3/31

host has a route for 10.0.0.8/32 via 169.254.254.1
host has a route for 172.16.1.5/32 via 169.254.254.3

netns has a route for 192.168.10.20 via 169.254.254.0 and 169.254.254.2. 
 --  There is some room for nuance in how this route exists, be it one 
ECMP route -or- two routes possibly with slightly different metrics.

> I think the task will fail with an asymmetric routes.

Maybe.  Maybe not.

Linux's default doesn't care what interface the traffic comes in if it's 
destined to a local IP, even if it's on another interface.

I say /default/ because there are ways to change this behavior.

Though, I think the synthetic nature of your test will differ from the 
real world where (test)eth0 and (test)eth1 don't share an upstream 
parent and might not even land on the same system.  Thus the two routes 
aren't really functional asymmetrically.

> The host is more important than these tasks. I am having sort of hyper 
> converged situation on storage servers. Keeping the host secure as in 
> 'least exposed to tasks' is important to me.  Also I would like to 
> limit the changes needed on the host, to keep things simple there.

Fair enough.

What interface will connections from clients be coming into the host on? 
 What IPs will the clients have?  What IPs will the clients connect to?

Do you need to have (test)eth0 and (test)eth1 in the same network namespace?

Is the function of the network namespace to function like a NAS gateway? 
 Possibly between protocols?

Have you done any looking at l3mdev?  It might be a way to streamline 
the different routing tables in the netns.



--
Grant. . . .
unix || die

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature