Force server to use -listenaddress for the api connections

[mfoxworthy]

When the client connects to the server api it is using the gateway IP address as the destination. When the connection comes out of the tunnel it goes to that IP. If that IP is not on the server the api connection fails. We should be using the IP address that the server uses in the -listenaddress command line option. Basically, a NAT is a way.

A workaround for now is to use a iptables command to do this for us.

sudo iptables -t nat -A OUTPUT -p tcp -d --dport 444 -j DNAT --to-destination <ip of server Ethernet interface:444

[parvit]

@mfoxworthy @bizzbyster The PR for this change is ready for testing

[mfoxworthy]

@mfoxworthy @bizzbyster The PR for this change is ready for testing

I tested the server and it appears that the connection is going to the correct IP but I am seeing this from the client:

[parvit]

@mfoxworthy For the first image, the new messages (not actually new they were just delayed to the server closure) you see are actually the result of a fix from the status-gui branch that allows the quic streams coming from the client to be closed when the connection is terminated (applies only to the quic->tcp direction of the connection, the other half was correctly closed on time).

For the second image:

• local: xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx is a debug message which i'll remove shortly
• ERROR: <nil> i'll add some tag in the various print locations to understand where it's coming from but i don't think it's critical to the feature behavior

EDIT: Pushed the change, please test with the updated tray icon

[parvit]

Feature tested positively and merged.