Add vrf compatibility

[MrSuicideParrot]

Netavark version v1.8.0 added support for bridges inside VRFs.

Currently, aardvark-dns doesn't work on bridges with a configured VRF. Aardvark-dns attempts to bind to the bidge's IP. However, as the IP is assigned to a VRF, it fails to bind. For a program to be able to bind to a VRF, it must first bind the socket to the VRF where the IP exists. This is done using the SO_BINDTODEVICE socket option.

This pull request adds this capability: before binding to an IP address, it checks if the bridge interface is assigned to a VRF, and if so, it binds the socket to the VRF before attempting to bind the socket to the IP address.

Unfortunately, this feature significantly complicates the logic of binding the DNS server and forces us to use lower-level APIs to set this option. Moreover, to check if a bridge is set to a VRF, I used methods from netavark, thus increasing the number of dependencies of this project.

For these reasons, I don't know if there is interest in merging this pull request, but I did it for at least if anyone encounters this problem and wants it solved, there is already a solution.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MrSuicideParrot
Once this PR has been reviewed and has the lgtm label, please assign luap99 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[Luap99]

This seems backwards, netavark has already all the info we need so there should be no need at all to lookup any addresses via netlink to figure out if there is a vrf.

I have not looked at how vrf works here and if we really must bind the device instead but if extra info is needed then they must be part of the aardvark-dns config file we read instead.

[Luap99]

We cannot do this here. This dependency would make it very hard for us to cut new releases.

[Luap99]

in general using unwrap() is almost never acceptable, error must be handled properly

[MrSuicideParrot]

I have tried to bind to the vrf without this option but I haven't had success. There is a tunable kernel option that enables programs to bind to any vrf, but this is only applicable when a program bind to all interfaces (0.0.0.0) and not a single IP as aardvark-dns does.

I understand the problem of adding the netavark as a depency. I'll investigate
how can I add the vrf information to the config file and remove this dependency.

[Luap99]

you need to extend the config file format https://github.com/containers/aardvark-dns/blob/main/config.md#first-line

I guess we could just add the device name on the first line. Then have netavark set this to the vrf name and call bind to device.

[coolwanglu]

A very hacky workaround:

• move /path/to/aardvark-dns to /path/to/aardvark-dns.original
• create a script /path/to/aardvark-dns that calls exec ip vrf exec MY-VRF /path/to/aardvark-dns.original "$@"

Side note: netavark allows specifying the location of the aardvark-dns binary, but podman does not allow specifying parameter for netavark.

[Luap99]

Side note: netavark allows specifying the location of the aardvark-dns binary, but podman does not allow specifying parameter for netavark.

It does via containers.conf helper_binaries_dir key where you can specify the location where podman looks for these binaries such as netavark/aardvark-dns.

---

Note, in the near futurewe would like to merge the aardvark-dns repo into netavark. And then this should make such changes like this much easier to coordinate between the applications.