Fill in `init.remote_addr` from front machines

[t-bast]

When running in cluster mode, we shouldn't return the remote_addr of one of our front machines, this should be written by the front machines themselves and match the real sender's IP address.

See lightning/bolts#917 (comment)

This needs some investigation, maybe there is something else that messes things up (e.g. a load balancer's IP address being reported).

[m-schmoock]

F.y.i those are the addresses ACINQs main node (from03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f) reports as remote_addr

• 13.248.123.158
• 13.248.123.156
• 13.248.123.155
• 13.248.122.61
• 13.248.122.58
• 13.248.122.62

[pm47]

We do preserve the client ip in cluster mode, this is actually due to us using a combination of AWS global accelerator and NLB, which is unfortunately not compatible with client ip preservation. Those ips are not internal ACINQ ips but internal AWS ips.

@m-schmoock if you use this uri: 03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f@34.239.230.56:9735 you will bypass AWS GA and should see your correct ip.

We can't fix that from within eclair, this is purely a deployment issue.

[m-schmoock]

@pm47
Hi, good to know. That brings up two takeaways:

• sending remote_addr should be 'turn off able' on your side if you already know that it will produce false results depending on infrastructure.
• I need to improve CLN to ignore if some peers return 'arbitrary' remote_addr (from clients point of view). Meaning IP addresses the other peers don't report.