[CRIU] [PATCH] net: drop network traffic for loopback device only
Andrey Vagin
avagin at virtuozzo.com
Wed Jan 18 00:48:53 PST 2017
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?
>
>
> 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?
>
>
>
> > > 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?
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.
Actually I am not sure that it will help you to solve a problem with
nfs...
>
>
>
> >
> >
> >
> > >
> > > 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;
> > >
> >
> >
>
>
More information about the CRIU
mailing list