support for new primitive (reverse-gateway) type that creates a link to remote standalone gateway

[muhamadazmy]

Problem

While ZOS has a built-in support for gateways that becomes available with nodes that has public-config (can be used as access points) it's not always possible to run zos in some envirotments. Hence a some sort of detecated stand-alone gateway solution is needed.

The solution then goes as this

• First, standalone gateways need to be installed, they run our gateway software (more on that later)
• If a user need to expose a (private) workload over the gateway, he needs to also deploy a gateway-agent workload on the same node that hosts his WL.
  • The params accepted by the agent are (vm-name, dns-name, and remote-gw, signature)
  • The vm name must be a vm workload in the same deployment
  • the dns-name, must be a valid reserved name on the chain
  • A signature of the "user" that combine all arguments, this is to prove to the gateway it's the owner of this name that is trying to set it up
  • the remote-gw, is the dns name of the remote gw to hook into. Some basic validation can be done on this to make sure it indeed runs a gateway of the correct version.
• Once the gateway-agent is started, it will establish a TCP (not http) connection to the remote GW. On connect the following will happen:
  • The agent will start by sending the configuration required to establish the gateway rule, this include the domain name, tls offloading, etc. Note that at this stage also the user signature is passed as is, this allows the gateway to validate the ownership of the name.
  • After validation, including that the user does not have the same name configured on this gateway, the gateway respond back with "ok" or "error" based on the result.
  • If it's okay, the gateway (side) does the following:
  • The gateway start a random listening port, and then does a 2 way copy from that port to the agent already established connection port (used in previous steps)
  • Configure the local running traefik instance to gateway that name, to that random (local) listening port
  • if agent connection is lost, configuration file is deleted

If gateway controller is restarted, it need to delete all configuration for traffek custom names, and wait for agents to reconnect.

it's obvious that this gatewasy agent/server need to have it's own separate repository

[AhmedHanafy725]

The vm name must be a vm workload in the same deployment

why the vm workload must be on the same deployment with the gateway agent? We always deploy the vm and think if we need to expose it on a gateway afterward. can't be just on the same node and using the network name and vm's IP as we do on the other gateway workloads?

[muhamadazmy]

per here https://github.com/threefoldtech/zos/issues/2167

Where a new gw agent will run on the zos next to the workload that need to be exposed, then that agent will connect to a public and standalone gateway server that then can serve traffic over a reverse proxy