In one line: How to connect multiple on-premise clients installations having private IP & behind a firewall to a public cloud hosted server and able to call HTTP endpoint & SSH in any of the on-premise clients setup from server.
Details: We've multi-tenant application, in which we've one live public (or cluster of multiple) Tomcat server, which is deployed in public cloud (ex: AWS). We also have client Tomcat server which will be deployed in client place and obviously the on-premise hosted client will have private IP and will be firewalled (allowing communication on specific ports to our live server).
We've to support the on-premise client installations to support some functionalities of the app during client offline. But end user will be syncing from live server to client server periodically.
I need a efficient way to access private hosted client machine (SSH & Tomcat) from public server.
Setup:
- Language: Java 8
- App Server: Tomcat 8
- OS: Ubuntu Linux 14.04 (both public cloud hosted & client servers)
To my knowledge, below are the ways & their pros & cons to achieve this:
- SSH reverse tunnel
- Pros: No need for any additional programming
- Cons: As the client count increases, those many ports need to be opened on the public server, which could raise many security issues.
- Local tunnel services, like ngrock or many other services
- Pros: No need for hand coded program and probably they would have handled many edge cases like re-connection and keeping the connection alive even though it is idle for most of the time.
- Cons: Most of them are commercial solutions and pricing model is per node. We'll be having at least 500-600 client installations.
- Websockets - Server will send push and client will callbacks the server.
- Pros: No need to open multiple ports on server
- Cons: Only HTTP is possible, SSH is not possible
- Hand coded socket programming where each client connects to separate port on server via SSH tunnel
- Pros: We'll have full control
- Cons: I m not sure how many edge cases we may have to handle, among which we might know many as of now.
Please suggest a better way to suit our requirement, keeping resource efficiency and security in mind.