Re: Getting delegated IPv6 prefix from systemd-networkd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23.10.2022 13.57, Arseny Maslennikov wrote:
On Sun, Oct 23, 2022 at 09:30:16AM +0300, Topi Miettinen wrote:
On 22.10.2022 15.55, Ian Pilcher wrote:
On 10/19/22 17:05, Ian Pilcher wrote:
(I know that systemd-networkd can allocate subnets from the delegated
prefix to local interfaces, but that's not what I need to do in this
case.)

Is there an API of some sort that my scripts can use?  A file that I can
monitor/parse?  A command that I can run?


Anyone?


For firewall integration, perhaps PR #24570 (once merged) could be useful
for you. Then the assigned prefix can be used in NFTables rules with NFT
sets.

Topi, thank you for the effort, this looks great at first glance! What's
especially cool about this solution is it seems to relieve networkd from
the burden of maintaining a special custom API, reusing a Linux feature
instead.


myif.network:
[DHCPPrefixDelegation]
NFTSet=inet:myfilter:myif_ipv6_address

nftables.conf:
table inet myfilter {
         set myif_ipv6_address {
                 type ipv6_addr
                 flags interval
         }

         chain myservice_input {
                 ip saddr @myif_ipv6_address accept
                 drop
         }
}

This is better than using networkd-dispatcher or NetworkManager scripts,
since the sets will be updated immediately by networkd when the addresses
are available, but of course it can't cover all possible cases where scripts
could be used.

On the other hand, scripts (or daemons running indefinitely) can query
the data stored in the nft sets and monitor modifications to those sets.
That way, the set objects can be used as a generic communication medium,
not necessarily being part of firewall state. (This might even work for
people who prefer some alternatives to nftables: they won't have to use
the rule engine. Those ppl can argue the same way about ipset, though)

The following example shows how to monitor nft objects with a shell and
nft(1) CLI:

   [root@host ~]# nft -j monitor elements | grep --color -F 'baobab' &
   [1] 1547610
   [root@host ~]# nft --json list set inet default baobab | jq '.nftables[1:]'
   [
     {
       "set": {
         "family": "inet",
         "name": "baobab",
         "table": "default",
         "type": "ipv6_addr",
         "handle": 11,
         "flags": [
           "interval"
         ],
         "elem": [
           {
             "prefix": {
               "addr": "2001:db8:8::",
               "len": 48
             }
           },
           {
             "prefix": {
               "addr": "2001:db8:9::",
               "len": 48
             }
           }
         ]
       }
     }
   ]
   [root@host ~]#
   [root@host ~]# nft add element inet default baobab '{' 2001:db8:a::/48 '}' >/dev/null 2>&1
   {"add": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:a::", "len": 48}}]}}}}
   [root@host ~]# nft flush set inet default baobab >/dev/null 2>&1
   {"delete": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:a::", "len": 48}}]}}}}
   {"delete": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:9::", "len": 48}}]}}}}
   {"delete": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:8::", "len": 48}}]}}}}
   [root@host ~]# nft add element inet default baobab '{' 2001:db8:9::/48 '}' >/dev/null 2>&1
   {"add": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:9::", "len": 48}}]}}}}
   [root@host ~]# nft add element inet default baobab '{' 2001:db8:8::/48 '}' >/dev/null 2>&1
   {"add": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:8::", "len": 48}}]}}}}
   [root@host ~]# nft add element inet default baobab '{' 2001:db8:a::/48 '}' >/dev/null 2>&1
   {"add": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:a::", "len": 48}}]}}}}
   [root@host ~]# nft flush set inet default baobab >/dev/null 2>&1
   {"delete": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:a::", "len": 48}}]}}}}
   {"delete": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:9::", "len": 48}}]}}}}
   {"delete": {"element": {"family": "inet", "table": "default", "name": "baobab", "elem": {"set": [{"prefix": {"addr": "2001:db8:8::", "len": 48}}]}}}}

We can see that the json-encoded events printed after each modification
command are actually printed by the backgrounded `nft monitor` job.

This watches for changes to set elements; the sets being
deleted/recreated themselves can be monitored in a similar way (`nft
monitor sets`).

Great idea! Then I think there should be a rough feature parity with networkd-dispatcher and NetworkManager scripts. The listener can even be sandboxed easily to the max, which is not the case with the scripts.

-Topi




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux