[CRIU] [PATCH] net: drop network traffic for loopback device only

[Stanislav Kinsburskiy]

18 янв. 2017 г. 9:49 AM пользователь Andrey Vagin <avagin at virtuozzo.com> написал:
On Tue, Jan 17, 2017 at 11:01:29PM -0800, Stanislav Kinsburskiy wrote:
>
>
> 18 янв. 2017 г. 4:31 AM пользователь Andrey Vagin <avagin at virtuozzo.com>
> написал:
>
>     On Tue, Jan 17, 2017 at 12:08:18PM -0800, Stanislav Kinsburskiy wrote:
>     >
>     >
>     > 17 янв. 2017 г. 9:05 PM пользователь Andrey Vagin <avagin at virtuozzo.com>
>     > написал:
>     >
>     >     On Mon, Jan 16, 2017 at 07:04:50PM +0300, Stanislav Kinsburskiy
>     wrote:
>     >     > The intention of commit 61b8fc264f55e15dea90350834a50d551d33bffa
>     was to
>     >     drop
>     >     > local traffic only.
>     >     > But there was a side effect: iptables rules were blocking all the
>     traffic
>     >     > including external communication.
>
>     The intention of my commit wat to block all traffic to not think how to
>     block it externally...
>
>
> Well, I see.
> Sad, that commit message explains it differently.
>
>
>
>
>     >     > While it's not a big problem by itself, it significantly
>     complicates
>     >     external
>     >     > communication when needed (say, in case of NFS files), because
>     forces one
>     >     to
>     >     > unmask NFS routes within container.
>
>     How are you going to block all external traffic except nfs?
>

I don't. P.haul does.
Curently via iface down.
Will be replaced by drop via ebtables on host.

>
> Simply block all the external traffic. Then unmask routes for NFS ports by
> server IP. One by one.

A container can use veth which is connected to a bridge. In this case
veth can be disconned of connected to the bridge. How are you going to
filter NFS traffic in this case?

Disconnected or connected when?
During dump?


>
>
>
>     >     > Let's get rid of this side effect by limiting rules to loopback
>     >     interface.
>     >     > External traffic blocking is controlled outside containers anyway.
>     >
>     >     * Does it controlled for venet?
>     >
>     >
>     > Sorry, I don't understand the question.
>
>     How do we block traffic which go via venet?
>

On host via iptables.

>
> This one is considered as external, and has to be blocked elsewhere.
>
>
>     >
>     >
>     >     * Both ends of a local tcp connection can be bond to an ip address
>     >       (which is set to any interface). I am not sure that this hack will
>     >       work for this case.
>     >
>     >
>     > Well, I was assured, that even it this case traffic is considered as
>     local, and
>     > transfered via loopback.
>
>     Yes, you are right, I've checked. But this patch will break Docker,
>     because it doesn't block traffic externally.
>
>
> But it should, isn't it?

According to my plan it should not ;). But the plan may be wrong. Anyway
it breaks backward compatibility and we need to add an option to block
network by this way.

Current solution doesn't block packets delivery to tcpdump (Packet sockets, to be precise) within container. Otherwise it would be perfect.


Actually I am not sure that it will help you to solve a problem with
nfs...

Problem with NFS can be solved without this patch.
The intention of the patch is to bring logic, mentioned in the comment, to the code.
And also simplify NFS unmasking.
Nevetheless, this patch is not an essential one.
If it breaks Docker, then, probably, it doesn'tmake much sense to take it.


>
>
>
>     >
>     >
>     >
>     >     >
>     >     > Signed-off-by: Stanislav Kinsburskiy <skinsbursky at virtuozzo.com>
>     >     > ---
>     >     >  criu/net.c |    8 ++++----
>     >     >  1 file changed, 4 insertions(+), 4 deletions(-)
>     >     >
>     >     > diff --git a/criu/net.c b/criu/net.c
>     >     > index 080c617..d75c9fa 100644
>     >     > --- a/criu/net.c
>     >     > +++ b/criu/net.c
>     >     > @@ -1547,8 +1547,8 @@ static int network_lock_internal()
>     >     >  {
>     >     >        char conf[] =   "*filter\n"
>     >     >                                ":CRIU - [0:0]\n"
>     >     > -                             "-I INPUT -j CRIU\n"
>     >     > -                             "-I OUTPUT -j CRIU\n"
>     >     > +                             "-I INPUT -i lo -j CRIU\n"
>     >     > +                             "-I OUTPUT -o lo -j CRIU\n"
>     >     >                                "-A CRIU -j DROP\n"
>     >     >                                "COMMIT\n";
>     >     >        int ret = 0, nsret;
>     >     > @@ -1571,8 +1571,8 @@ static int network_unlock_internal()
>     >     >  {
>     >     >        char conf[] =   "*filter\n"
>     >     >                        ":CRIU - [0:0]\n"
>     >     > -                     "-D INPUT -j CRIU\n"
>     >     > -                     "-D OUTPUT -j CRIU\n"
>     >     > +                     "-D INPUT -i lo -j CRIU\n"
>     >     > +                     "-D OUTPUT -o lo -j CRIU\n"
>     >     >                        "-X CRIU\n"
>     >     >                        "COMMIT\n";
>     >     >        int ret = 0, nsret;
>     >     >
>     >
>     >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20170118/5399824e/attachment.html>