Thanks, so what you described by your method is a load balancer/failover.
As briefly as possible:
You have two exit IP addresses assuming that 2 ISPs are used, active statefull connections break when switching between the 2 gateways as the other end (server) is not notified for handover to the second IP address, at least by standard unlike MPTCP/MPQUIC for example (still uncommon), and thus it's not a seamless failover,
it is a disruptive failover.
In nutshell: your video call, remote desktop, gaming, radio, streaming, non-resumable downloads etc will end if it happens to be on the faulty WAN. It will also end if the router/firewall decides to switch it off due to packet loss or other reasons. It can't handover the connection to the better WAN. You'd have to restart the call after a failover or wait for the video call app to reconnect. This is still useful if failures are rare or scheduled which is not the case for many in this country.
In load balancing configuration (not your case), active connections cannot be migrated on low saturation, they're weighed before creation, example:
You have two ISPs: 4G: 20 Mbit down 10 Mbit up, ADSL: 20 Mbit down 1Mbit up, and you're uploading a file, most uploading services are single socket, the upload may go through 4G or ADSL which is undesirable when load balancing asymmetric connections. Your video game/video call may also use the worst/slowest WAN. Setting unbalanced weight assumes that you have stable and
predictable internet connections, at least in terms of speed.
Bonding aggregates single sockets, the weighing is done dynamically by packet but it requires a server to terminate one end.
SD-WANs can also rehash the flows to the other path if tunnels/IGPs are used without bonding. (Zerotier's balance-aware, Citrix etc)
Having an orchestrator with tunneling allows you to:
- Have one exit IP address
- Correct a lossy WAN by forward error correction (with slight latency increase)
- Maintain active sessions
- Bond single-socket connections as described above
- Duplicate packets in case all WANs are lossy/bad
- Correct packet ordering which is very important for TCP with bad ISPs (even in a UDP tunnel)
- Use realtime WAN quality monitoring as opposed to pinging one-way, as well as quality index (memory/history) and other logic
- Use QoS for flows by path as opposed to prioritization-only (similar to SD-WAN)
- Que and shape speed for dynamic links to reduce bufferbloat (quicker with 2 ends)
The focus is mainly on the Pi (and old laptops) due to availability and cost, hence the reliance on USB ethernet adapters, if you wish to combine few hundred megabit connections then this hardware setup isn't suitable but that's not the case in Lebanon ;)
The solution is very popular with Starlink users despite the decent speeds due to dropouts.
There is a drop down menu in the link that describes the setup process, the example uses a smartphone for simplicity.
If you wish to give it a try, try Speedify on a PC/Mac with wired connections first to see if it works well.
Note that the speed ramps up slowly for weighing dynamic connections, use a speed testing service that has decent intervals or the built-in test which waits for the speed to stabilize.
Tip for Lebanon: Use French servers, Paris #1 server is close to Marseille (IMEWE).