masq hairpinning vs Docker networking support for local VIPs within containers

[SpComb]

Using IpvsMethod: "masq" on a Docker host for local container backends is the simplest method in terms of configuration, but it fails at hairpinning: a container connecting to a service with a backend on the same docker bridge (the return path does not pass through the host's IPVS stack).

Ideal situation would be to configure the service VIP as a local route within the docker container, optionally with an IP-IP tunnel endpoint, and using Direct Server Return, avoiding the requirement for a symmetric return path with stateful translation.

[SpComb]

This should probably be optional, whilst retaining support for Docker containers using {"IPVSMethod": "masq"}. The IPVS masq method is required for mapping frontend TCP/UDP ports to different backend TCP/UDP ports. The IPVS droute method ignores the IPVS Dest's port, and forwards the unmodified packet using the original Service port.

[SpComb]

Alternatives to retain the use of IPVS masq would include the use of ebtables BROUTING magic to force bridged packets into the Linux routing code where the IPVS netfilter FORWARD masq return path code would have a chance to mangle them.

Or classical NAT hairpinning involving the additional use of SNAT for connections being forwarded within the docker bridge network...