Support Failover over multiple remote servers

[qluo1]

Describe the feature

it would be good if we can support multiple remote servers for failover.

an example with list of remote server in client side cli options: wss://sv1.abc:443 wss://sv2.abc:443

Describe the reason for such feature

in a highly restricted environment, we saw tunnel failed from time to time.
.... wstunnel::tunnel::client: failed to do websocket handshake with the server ....

Describe alternatives you've considered

we have tried "--connection-min-idle=5", and observed, all sessions frequently hit network error.

2024-10-06T04:49:49.023532Z WARN wstunnel::tcp: Cannot connect to tcp endpoint x.x.x.x:443 reason Network unreachable (os error 101)

overall, the wstunnel + wireguard has preformed well.

[erebe]

Hello,

I don't think this is going to help you to have a fallback server. The issue is more lying in how "--connection-min-idle" is working.
idle connections establish a connection up to the TLS layer and after stay idle until there is a tunnel to establish, at which point the http/websocket request is sent.

In general, middle boxes does not like at all idle connections and aggressivly terminate them. So it is possible that the connection has been terminated due to being idle for too long, and when wstunnel tries to use it to connect to the server, by sending data it realize it has been terminated.
It is a bit hard to tell without a pcap/network capture, but this is my guess.

In such scenario not using --connection-min-idle should provides you more success rate, even if it slows down tunnels connection time.

[qluo1]

I think you are right, i have disabled "--connection-min-idle", now i can see better logging.

the disconnect and reconnect like following.

I suspect item 1), the connection reset by peer (os error 104) likely due to censorship. It happens from time to time.

on the item 8), is it likely be similar issue #365 ?, which you have just fixed for v10.1.3

note: i am still using wstunnel 9.4.2

1. ERROR tunnel{id="01926d06-38b5-7cb8-ab8b-68c8a30ceeab" remote="localhost:51820"}: wstunnel::tunnel::transport::io: error while reading from tunnel rx Connection reset by peer (os error 104)
2. wstunnel::tunnel::transport::io: Closing local <= remote tunnel
3. wstunnel::tunnel::transport::io: Closing local => remote tunnel
4. wstunnel::udp: New UDP connection from 127.0.0.1:43285
5. wstunnel::tcp: Opening TCP connection to
   ...
6. .. daemon.notice netifd: Network device 'wgclient' link is down
   ...
7. ..user.notice wgclient-up....
8. ERROR tunnel{peer="[::1]:34532" forwarded_for="x.x.x.x" id="01926d07-9d94-7c2d-b745-862b6c8bf8ae" remote="localhost:61820"}: wstunnel::tunnel::transport::io: error while reading from tunnel rx Unexpected EOF
9. INFO tunnel{peer="[::1]:34532" forwarded_for="x.x.x.x" id="01926d07-9d94-7c2d-b745-862b6c8bf8ae" remote="localhost:61820"}: wstunnel::tunnel::transport::io: Closing local <= remote tunnel
10. INFO tunnel{peer="[::1]:34532" forwarded_for="x.x.x.x" id="01926d07-9d94-7c2d-b745-862b6c8bf8ae" remote="localhost:61820"}: wstunnel::tunnel::transport::io: Closing local => remote tunnel
11. INFO wstunnel::tunnel::server: Accepting connection
    ...
12. INFO tunnel{peer="[::1]:34584" forwarded_for="x.x.x.x" id="01926ea5-8729-768f-b412-35fd590083f3" remote="localhost:61820"}: wstunnel::tunnel::server: connected to Udp { timeout: None } localhost: 61820

[erebe]

Hello,

No the bug you mentionned has been introduced in version v10.1.1 so it is unlikely the issue for your version v9.4.2

[qluo1]

thanks for the help issue closed.