...
The IPsec-based VPN network instances should be even more isolated from each other and other networks. Application inside a VPN network should only be able to talk to apps in the same network or with endpoints on the other side of the tunnel.
One way to The following drawing visually depict the current EVE implementation of network instances is in the drawingwith an example of 4 apps, 2 local NIs, one switch NI and some (non-overlapping) IP addressing:
While the current implementation is successful in prohibiting a direct communication between network instances and facilitating hairpinning inside or outside the device based on the aforementioned criteria, it fails to isolate networks when it comes to IP address allocation.
For example, it is not possible to deploy multiple network instances with the same or overlapping IP subnets. A significant risk of IP address collisions exists also between external (uplink) and internal (downlink) networks. A local network instance should be completely isolated and independent from the outside networks with a NAT happening placed in-between. Similarly, traffic selectors of multiple VPN networks could overlap, thus preventing from opening the tunnels at the same time, which is also against the our semantics of network instance isolation.
We can get better isolation, including IP address isolation if we split network instances using either VRFs or with network namespaces. Furthemore, if we use a containerd task to run network instance networking (and not just a bare network namespaceespecially the external processes like dnsmasq, radvd, etc.), we can also even isolate resource usage and apply limiting. We will now describe VRF VRFs and network instances separately, with a bit more focus on VRFs, which, after some internal discussion, is now the preferred choice.
...