netdev - Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d70cb6ae-1e90-16b2-083c-8da8112e1f28@ucloud.cn>
Date:   Tue, 9 Jul 2019 21:38:47 +0800
From:   wenxu <wenxu@...oud.cn>
To:     Florian Westphal <fw@...len.de>
Cc:     pablo@...filter.org, netfilter-devel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add
 nf_nat_bridge_ops support

在 2019/7/9 18:42, Florian Westphal 写道:
> wenxu <wenxu@...oud.cn> wrote:
>>> For NAT on bridge, it should be possible already to push such packets
>>> up the stack by
>>>
>>> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
>>>        meta pkttype set unicast ether daddr set 00:11:22:33:44:55
>> yes, packet can be push up to IP stack to handle the nat through bridge device. 
>>
>> In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
>> is the same known by outer.
> I think that in general they will have different MAC addresses, so plain
> replacement of ip addresses won't work.
>
>> But in This case modify the packet dmac to bridge device, the packet push up through bridge device
>> Then do nat and route send back to bridge device.
> Are you saying that you can use the send-to-ip-layer approach?
>
> We might need/want a more convenient way to do this.
> There are two ways that I can see:
>
> 1. a redirect support for nftables bridge family.
>    The redirect expression would be same as "ether daddr set
>    <bridge_mac>", but there is no need to know the bridge mac address.
>
> 2. Support ebtables -t broute in nftables.
>    The route rework for ebtables has been completed already, so
>    this needs a new expression.  Packet that is brouted behaves
>    as if the bridge port was not part of the bridge.

This is my senario:

For a virtual machine example with address  10.0.0.7 and internet address 2.2.1.7  default router

10.0.0.1. There are both the east-west and south-north traffic. So the outer vnet0 connect to bridge

br0 which with address 10.0.0.1.   The bridge also add an flow-based/metadata_dst vxlan device vxlan0.

So there are three kinds traffic to handle:

1. 10.0.0.7 <-----> 10.0.0.8: both ingress and egress packet gothrough the bridge with vlanid to vni feature.

2. 10.0.0.7 <-----> 10.0.1.8: The egress packet push up to stack through br0 to do route. And the route send packet through

vxlan0 to peer with static mac(Maybe the route can send through br0); The ingress packet always gothrough the bridge to VM.

3. 10.0.0.7  <----> 1.1.1.7: The egress The egress packet push up to stack through br0 to do route and nat. And the route send

packet through vxlan0 to router. With this patche, The router assume is the same mac address for 10.0.0.7 and 2.2.1.7. so it can do

nat under bridge and send to VM.

I think the most big problem is that the only vxlan0 device is alyways attach on br0. For L3( do route) traffic the egress packet will push

up to stack do route through br0.  The ingress I hope only gothrough the bridge to VM for all the three kinds traffic above.