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

Stanislav Kinsburskiy skinsbursky at virtuozzo.com
Tue Jan 17 23:01:29 PST 2017



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?

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


>     > 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?

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?


>
>
>
>     >
>     > 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/35f5e9b9/attachment.html>


More information about the CRIU mailing list