Network Access
Options for Configuring Network Access to the Comet Application¶
Public IP Address¶
A Public IP address is a unique network address assigned to a device connected to the public internet. When installing Comet on a Single Server, you have the option to assign that server a Public IP Address. This option allows Comet to be accessible from anywhere in the world, though you can still limit access in certain ways using a Firewall.
When installing Comet on a single server (with or without external dependencies) which has been assigned a public IP address, the Comet web interface, and API, will be immediately available on any other computer, using the public IP Address.
The Comet Base URL should be set to this public IP address or an equivalent DNS name.
Firewall¶
A Firewall is a network security system that monitors and controls incoming and outgoing network traffic based on predefined security rules. It acts as a barrier between a trusted, secure internal network and untrusted external network, such as the internet. A firewall can also be setup on a single machine to act as a barrier between it and any other public or private network location.
When using a public IP address this can be useful to limit access to Comet to only certain individual computers or networks.
Some examples of Firewall tools you can use to restrict access to Comet over a public IP address include:
- Network Edge Firewall (configured on network routing equipment)
- IPTables (configured on Linux Servers)
- Instance Security Groups (in AWS)
Private IP Address within Intranet¶
When running Comet within the same Intranet/Network as all of its users, it is possible to simply use a Private IP Address. This works much the same as using a public IP address, with the major difference that it cannot be accessed directly over the public internet in any way.
This option is only viable if the private IP address is reachable by any of the computers that need to interact with Comet (either the web interface or the API).
The Comet Base URL should be set to this private IP address or an equivalent DNS name.
Private IP with VPN¶
A VPN (Virtual Private Network) allows users from other networks to securely connect to machines within another network as if on the same network (using a private IP address).
When using this method, Comet is set up the same way as previously described when using a private IP address. However there must be a VPN service available which will allow any computers that need to interact with Comet to connect to this network.
Application Gateway¶
An Application Gateway is an OSI Layer 7 Load Balancer that provides security and access control for applications. This option is used when Comet is meant to be accessible using a public IP address, but the application server(s) is(are) not publicly accessible (they can also be used to allow access using a private IP address when Comet runs in a segregated portion of the intranet). The Application Gateway acts as a reverse proxy, forwarding incoming traffic to the application server while also providing optional security features such as SSL Offloading/Termination, Rate Limiting, and Firewalling.
They have their own IP address, which computers will use to access Comet. The Comet Base URL should be set to this IP address or an equivalent DNS name.
Web Application Firewall¶
OSI Layer 4 firewalling can be applied to an Application Gateway in the same ways as described in the Public IP section. However an Application Gateway will normally provide OSI Layer 7 firewalling through a WAF (Web Application Firewall). Which will allow more fine-grained restrictions to certain kinds of HTTP requests from defined sources.
Kubernetes NodePort-Service/Ingress¶
Kubernetes provides two standard means for exposing applications outside of the Cluster. An OSI Layer 4 solution: NodePort Services, and an OSI Layer 7 solution: Ingresses.
Either of these can be assigned Public IP Addresses if the Kubernetes Cluster has a pool of these to assign. However, most clusters will probably rely on an external Gateway/Load-Balancer to expose these on the Public Internet or to use the features provided by an Application Gateway. We recommend this approach as well as choosing an Ingress over a NodePort Service.
When running in AWS, we recommend using the AWS Load Balancer Controller to automatically provision an Application Gateway for Comet.
SSH Tunneling¶
Tunneling can allow you to send HTTP traffic over a non-HTTP connection/port. This is the basic principle used by a VPN. It is possible to set up a tunnel over an SSH connection which can be useful to test Comet from your machine when you do not yet have the ability to connect to the machine over HTTP from your computer (but can connect via SSH).
Important: This is not a supported means of providing user access to Comet, and should not be relied upon beyond basic validation of a Comet installation.
It can be done with the following command:
ssh -L <UNUSED PORT ON YOUR MACHINE LIKE 8080>:localhost:80 <SSH USERNAME>@<COMET SERVER IP/HOST>
# Use Ctrl-c when you are ready to close the tunnel.
When connecting to Comet over a Tunnel, the Comet Base URL should be set to localhost:<8080 OR PORT USED IN TUNNEL>.
You can then connect to Comet in your browser using the URL (assuming you chose port 8080): http://localhost:8080.
DNS Configuration¶
A DNS Record/Name provides an alias to an IP address, and is a requirement for connecting to Comet with SSL/HTTPS. You will need to request a DNS record from your DNS provider/administrator which corresponds to the IP address through which Comet is available.
When using an Application Gateway, it's likely you already have a DNS name automatically created when creating the gateway, but it will not likely be a very friendly or easy to use name. In this case you can create a better DNS name yourself by creating a CNAME record that points to the automatically created DNS name.
The Comet Base URL should be set to this DNS name.
When creating a certificate for SSL/HTTPS you will need to have it issued for this DNS name, as well.