client: allow clients behind a 1:1 NAT to connect in ibrl mode

[nikw9944]

Summary of Changes

• client: allow clients behind a 1:1 NAT to connect in ibrl mode
• This is a trivial change to the client, which already supported NAT for ibrl -a
• Requires applications using this feature to bind to 0.0.0.0 rather than a specific IP address

Testing Verification

• e2e: new e2e/client_behind_nat_test.go test with 2 clients (1 ibrl and 1 ibrl -a) behind a 1:1 NAT gateway
• Tested by hand with python3 -m http.server, which continues to accept inbound traffic over doublezero0 after a doublezerod restart
• Verified that a running Solana client (Agave/Jito) resumes using doublezero0 after upgrade to updated snapshot client

[packethog]

I'm concerned about solving this by just applying the detected public IP to the tunnel interface. If their app is only listening to the RFC1918/whatever address is behind the NAT, they're going to bring up their tunnel and we'll potentially break them because traffic is now coming in destined to an address they're not listening on.

[nikw9944]

Yes, it requires applications to bind to 0.0.0.0, but isn't that the nature of the beast? Also I think "break them" is too strong, because wouldn't they have to make some other change external to this client update to send traffic to the public IP?

I can't think of a way to solve for that other than documentation and support. Any ideas?

[packethog]

Yes, it requires applications to bind to 0.0.0.0, but isn't that the nature of the beast?

What do you mean nature of the beast? In the current IBRL mode, we don't require users to do that.

Also I think "break them" is too strong, because wouldn't they have to make some other change external to this client update to send traffic to the public IP?

The situation I'm worried about is:

1. An app behind a 1:1 NAT is listening on their RFC1918 address, not all interfaces
2. There are 10 other hosts connected to DZ communicating with this app via it's public IP behind 1:1 NAT
3. The app gets connected to DZ, and it's public IP is advertised into DZ
4. The 10 other hosts now attempt to reach the app via DZ
5. Traffic ends up getting dropped in the kernel where this app is running because the app's listening socket is not bound to this address

[nikw9944]

What do you mean nature of the beast?

I should have said: "Yes, it requires applications to bind to 0.0.0.0, but is there any other way to do multihoming properly?"

I get the concern, but it doesn't seem like an unreasonable caveat to me. Am I missing something?

[packethog]

"Yes, it requires applications to bind to 0.0.0.0, but is there any other way to do multihoming properly?"

We could handle the 1:1 NAT for the user on the doublezero0 interface via something like tc. This way it doesn't matter what address the app is bound to and there's no risk we break their application when they connect to DZ.