feat: handle creation and configuration of multiple WireGuard tunnels

[MircoBarone]

Description

Part of the multi-tunnel WireGuard implementation. This is the first PR related to issue #3225.

Add --listen-ports and --endpoint-ports flags to the WireGuard container.

These flags allow specifying multiple ports for the Gateway server and client, respectively.
The original idea was to also include the --num-interfaces flag to indicate the number of WireGuard interfaces to create, but it is unnecessary and redundant: the same information can be inferred from the number of ports, maintaining a single source of truth.

The existing --listen-port and --endpoint-port flags are preserved for backward compatibility and default values. They can be ignored if values are provided in the new multi-port flags, ensuring that the existing infrastructure continues to work without changes.

[adamjensenbot]

Hi @MircoBarone. Thanks for your PR!

I am @adamjensenbot.
You can interact with me issuing a slash command in the first line of a comment.
Currently, I understand the following commands:

• /rebase: Rebase this PR onto the master branch (You can add the option test=true to launch the tests
  when the rebase operation is completed)
• /merge: Merge this PR into the master branch
• /build Build Liqo components
• /test Launch the E2E and Unit tests
• /hold, /unhold Add/remove the hold label to prevent merging with /merge

Make sure this PR appears in the liqo changelog, adding one of the following labels:

• feat: 🚀 New Feature
• fix: 🐛 Bug Fix
• refactor: 🧹 Code Refactoring
• docs: 📝 Documentation
• style: 💄 Code Style
• perf: 🐎 Performance Improvement
• test: ✅ Tests
• chore: 🚚 Dependencies Management
• build: 📦 Builds Management
• ci: 👷 CI/CD
• revert: ⏪ Reverts Previous Changes

[MircoBarone]

/rebase test=true

[MircoBarone]

I have updated the logic to support the creation of multiple interfaces.
This commit is an incremental step, as the interfaces are created but not yet fully configured.

I have added the GetWireguardPorts function to extract the list of ports from the flags (--endpoint-port(s), --listen-port(s)) , which is also used to determine the number of interfaces. I tried to correctly handle priority between the new plural flags and the legacy single-port flags.

I have also extended GetInterfaceIP to assign a unique IP to each interface within the 169.254.0.0/16 range. Each interface now gets its own /30 subnetwork.
I considered assigning the same IP to all interfaces, but in my opinion, it is problematic because it would generate overlapping routes where the kernel consistently picks only the first available route.
For example:

169.254.18.0/30 dev liqo-tunnel proto kernel scope link src 169.254.18.2
169.254.18.0/30 dev liqo-tunnel1 proto kernel scope link src 169.254.18.2
169.254.18.0/30 dev liqo-tunnel2 proto kernel scope link src 169.254.18.2
169.254.18.0/30 dev liqo-tunnel3 proto kernel scope link src 169.254.18.2

This would cause, in particular, issues with keepalives.

The wireguard container entrypoint has been extended to initialize N interfaces using a fail-fast approach: if the creation of even a single interface fails, the entire container is considered failed and will exit.

Additionally, all underlying interface creation functions have been refactored to support this index-based multi-tunnel logic.

[MircoBarone]

In the commit ad92c6b I have removed the single-port flags of the wireguard container (--endpoint-port and --listen-port) and replaced them with --endpoint-ports and --listen-ports.

This change is meant to be integrated with PR #3233 and PR #3236. The idea is to update the template later on, introducing something like this:

--endpoint-ports={{ if .Spec.Endpoint.Ports }}{{ range $i, $p := .Spec.Endpoint.Ports }}{{ if $i }},{{ end }}{{ $p }}{{ end }}{{ else }}{{ .Spec.Endpoint.Port }}{{ end }}

I will submit the template modifications once the two PRs are merged.

Let me know if you agree with this approach.

[fra98]

/build

[fra98]

/test