feat: add source support

[DakEnviy]

Summary

Adds optional source filtering (IP, subnet or "any") to UFW rules created by ufw-docker, updates help/usage, and introduces comprehensive test coverage for the new behaviour.

Motivation

Users need to restrict allowed traffic to a container by specific source addresses or subnets, not only by destination port/protocol.

It is useful for cases when an application lives behind a proxy (e.g. CloudFlare). I use it with this script:

#!/usr/bin/env bash
set -euo pipefail

container_name="${1:-}"

if [[ -z "$container_name" ]]; then
    >&2 echo "Container name is empty"
    exit 1
fi

for cidr in `curl -sw '\n' https://www.cloudflare.com/ips-v4`; do
    ufw-docker allow "$container_name" "$cidr"
done

ufw reload

What’s changed

• Add an optional source argument to the CLI:
  • ufw-docker <list|allow> [docker-instance-id-or-name [source] [port[/tcp|/udp]] [network]]
  • Default source is any if omitted.
• Accept and validate:
  • IPv4/IPv6 address (e.g. 192.168.1.10, fd00:cf::42)
  • IPv4/IPv6 CIDR (e.g. 192.168.1.0/24, fd00:cf::/8)
  • Literal any
• Apply source in generated UFW route rules:
  • ufw route allow proto <tcp|udp> from <SOURCE> to <INSTANCE_IP> [port <PORT>] comment "allow <instance> <SOURCE> <PORT>/<PROTO> [<NETWORK>]"
• Reflect source in comments and in list/delete matching.
• Update help/usage text to include the source parameter.
• any is used as the default when the source is omitted to allow.

Implementation note:

source parameter was added before port to set from and use auto-detection for ports together.

Documentation note:

I wrote the Chinese part using a translator, so please do not judge it strictly and check it thoroughly.

[DakEnviy]

@chaifeng, hello! Please have a look once you have time

[chaifeng]

Hi @DakEnviy

Thanks for your contribution!

I've looked this PR and have some concerns regarding backward compatibility. The changes introduce a new source parameter which shift the position of port and protocol arguments. It may lead to unexpected behavior or breakage for current users.

Could we explore options to maintain backward compatibility? For example, perhaps we could follow ufw's syntax more closely, which would be more easy for current users.