Add ENABLE_OUTBOUND_ORIG_SRC config for outbound source IP preservation

[bekerr1]

For our multi-NIC pods, we use policy based routing (PBR) to influence the outbound interface. The routing looks something like the following

$ ip rule show
0:      from all lookup local
32763:  from <ETH0_IP_ADDR> lookup 200
32766:  from all lookup main
32767:  from all lookup default

# Table 200
$ ip route show table 200
default via 169.254.1.1 dev eth0 

# Main table
$ ip route show
default via 169.254.2.1 dev eth1 proto static 
<NETWORK_ADDRESS_RANGE> via 169.254.1.1 dev eth0 proto static 
<POD_SUBNET_ADDRESS_RANGE> via 169.254.1.1 dev eth0 proto static 
<SERVICE_CIDR_RANGE> via 169.254.1.1 dev eth0 proto static 

The intention of this change is to enable Ambient to honor the outbound source address it uses (obtained from the peer addr) in cases where it could receive redirected packets from multiple interfaces.

More on our specific use-case here for those interested:
istio/istio#58681

I wasn't sure if creating a separate env variable and making the distinction between ENABLE_ORIG_SRC, which is currently only used for inbound, was preferred over just re purposing the existing env. Open to suggestions here.

[istio-policy-bot]

😊 Welcome @bekerr1! This is either your first contribution to the Istio ztunnel repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[linux-foundation-easycla]

• ❌ - login: @bekerr1 / name: Brendan Kerr . The commit (7fa69c9) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[istio-testing]

Hi @bekerr1. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Stevenjin8]

lgtm implementation wise, but want to give other folks a chance to take a look.

[bekerr1]

Thanks for the quick look Steven. Working on getting my CLA sorted also.

[Stevenjin8]

/ok-to-test

[bekerr1]

/retest