I have a situation where I am trying to host my own web server because I need some custom software, including telephony, WebRTC, node.js, etc. However, my net connection in the town and country where it will be hosted, over a fiber optic line is not very reliable (physically speaking - prone to cuts - rare but has happened a couple of times already).
To get around this, I thought I would have the inhouse server be reachable via two ISPs through two different physical media and of course two different public IPs. The domain registrar will ordinarily have only one IP in the DNS setting (A record) so as a fault tolerance mechanism, this will serve no purpose. Even if I were to manually change the A record for the domain, when one of the physical connection is down, it will take time to propagate, not to mention DNS caching, etc. All this is basic stuff, I presume.
To get around the problem described, can I use a reverse-proxy on the hosted server whose sole purpose is to redirect incoming requests for a given session to a particular IP address, kind of in a round-robin manner, as used in load balancing, though technically it is the same server with two different IPs. The DNS A record will point to the hosted server. If one of the ISP's connection is down, the hosted server will automatically forward to the other IP only.
I looked at common reverse proxy servers (APache, Nginx, Squid) but could not get a clear understanding of how it manages redirection from a session perspective. That is, multiple requests in the same session, are redirected to the same IP? Reverse proxy server called Pound seems to provide such service but I am unclear there too.
Does the reverse proxy handle session management? If not, how does it know that a particular request must be forwarded to the same IP within a session? Or does this have more to do with TCP connection, rather than an application-level session? Please note that in this reverse proxy usage, the forwarded IPs are not on the same local net as the proxy itself but rather public IP addresses of remote servers of totally different ISPs. Perhaps it does not matter as the remote server is the same in my case, albeit with different IP interfaces with different IP address. Will the session management take care of itself, even though the requests are coming from two different IPs on the same server, within the same session (resulting from a physical disruption of one cable mid-way through a session)?
I just need some clarification before I move forward with the implementation. Or is there a better approach to address this problem?I guess that many in third-world countries will face this problem, particularly if they want to host node.js and associated new generation services, in-house, and not have to be too concerned about the problems raised here.
On a related subject, can Iptables destination NAT be used as a reverse proxy server. This is only a theoretical question because I will not be able to set IPtables rules on the hosted shared server.
