Support Failover over multiple remote servers
qluo1 opened this issue · comments
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.
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.
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
- 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)
- wstunnel::tunnel::transport::io: Closing local <= remote tunnel
- wstunnel::tunnel::transport::io: Closing local => remote tunnel
- wstunnel::udp: New UDP connection from 127.0.0.1:43285
- wstunnel::tcp: Opening TCP connection to
... - .. daemon.notice netifd: Network device 'wgclient' link is down
... - ..user.notice wgclient-up....
- 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
- 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
- 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
- INFO wstunnel::tunnel::server: Accepting connection
... - 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
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
thanks for the help issue closed.