Redirecting the Collector TCP channel
Overview
Because Nexthink Appliances installed on premise are usually not accessible through the Internet, only the Collectors running on devices inside the corporate network or with VPN access can reach their assigned Appliance. Thus, the Collectors of roaming devices without VPN access cannot directly communicate with their Appliance.
To forward Collector traffic from roaming devices to their assigned Appliances, run a redirection Appliance on a DMZ that faces both the Internet and your corporate network, so that the Appliance is reachable by the roaming devices while able to deliver traffic to your internal Appliances at the same time:
If all Collectors are configured to send end-user data through the TCP channel, run a reverse proxy that redirects all the TCP traffic.
If some Collectors send end-user data through the UDP channel, run the redirection service to forward the UDP traffic and a reverse proxy to redirect the TCP traffic.
Note that, although the redirection service is able to forward TCP traffic since V6.21, the service only handles the end-user data portion of the TCP channel (not Engage, Act, assignment, or updates data) for redundancy or anonymization purposes. Thus, avoid the redirection service to forward TCP traffic from the Collectors of roaming devices. Instead, run a separate reverse proxy on the Appliance for the TCP channel. The Engine Appliance already includes a version of the popular web server Nginx. Find in this article how to configure Nginx as reverse proxy for the TCP channel of the Collector.
As a prerequisite, remember that roaming devices will only be able to reach their assigned Engine both inside and outside the corporate network if the name of the Engine configured in the Collector is valid as well for the redirection Appliance when the device is on the Internet. Please contact Customer Success Services to get guidance on how to configure the DNS service for that purpose.
Running Nginx on the Engine Appliance
To redirect the TCP channel of the Collector, we assume that you already have an Engine Appliance up and running where the Engine service has been stopped to exclusively use the Appliance for redirecting Collector traffic. Remember that you only need to run the redirection service in addition to Nginx on the redirection Appliance if any of the roaming Collectors sends end-user data through UDP.
Ensure that nginx is running on your redirection Appliance by logging in to the CLI of the Appliance and running the following command:
sudo systemctl status nginx
If the service is not running, first enable it with the following command to make nginx start on every boot of the Appliance:
sudo systemctl enable nginx
Start the service after properly configuring it, as shown in the instructions below.
Transfer TLS certificates and private key to the redirection Appliance
To secure the connection between the Collectors and ngninx, copy the certificates and private key that protect the TCP channel of the internal Appliances to the redirection Appliance (we name the certificate and key files in the same way as in the article on replacing certificates).
To transfer the TLS certificates and private key of an Engine:
Copy the certificate and key files to the redirection Appliance:
If you are using a custom certificate to protect the TCP connection between Collectors and the Engine:
Copy the server certificate (slave.crt), the intermediate certificate or chain of certificates (intermediate.crt), if any, and the private key (slave.key), all in PEM format, to the nexthink account of the redirection Appliance using your favorite SCP tool.
Log in to the CLI of the redirection Appliance.
Concatenate the server and intermediate certificates. If you do not have an intermediate certificate, the command will give you a warning that you can safely ignore:
cat slave.crt intermediate.crt > slave_bundle.crt
If you are using the default certificates generated by the Appliance:
Log in to the CLI of the Engine.
Get the keystore in the Engine that holds the certificates and key to protect the TCP channel.
keytool -importkeystore \
-srckeystore /var/nexthink/nxproxy/keystore/keystore.jks \
-destkeystore certs_key.p12 -deststoretype PKCS12
When prompted for the destination keystore password and for the source keystore password, always type in nexthink.Get the bundle of certificate files and the private key from the keystore. Provide nexthink as password to each command:
openssl pkcs12 -in certs_key.p12 -nokeys -out slave_bundle.crt
openssl pkcs12 -in certs_key.p12 -nocerts -nodes -out slave.key
Clean the certificate and key files off additional attributes:
sed -ni -e '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' slave_bundle.crtsed -ni -e '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' slave.key
Copy the certificate and key files to the redirection Appliance using your favorite SCP tool.
Log in to the CLI of the redirection Appliance.
Change the permissions of the certificate and key files:
sudo chmod 444 slave_bundle.crtsudo chmod 400 slave.key
Move the certificate and key files to a standard location:
sudo mv slave_bundle.crt /etc/pki/tls/certssudo mv slave.key /etc/pki/tls/private
If you are using automatic Collector assignment, repeat the same steps described above to transfer the TLS certificates of the Portal to the redirection Appliance. To that end, log in to the CLI of the Portal instead of the CLI of the Engine when indicated and replace:
slave.crt
bymaster.crt
slave_bundle.crt
bymaster_bundle.crt
slave.key
bymaster.key
Read the considerations on the automatic assignment of roaming Collectors.
Depending on how you configured your DNS for Collectors to reach both their assigned Engine (or the Portal in the case of automatic Collector assignment) and the redirection Appliance, your certificates may require to be issued to multiple subjects (i.e. multiple domain names). For default certificates, multiple subjects can be specified when setting the external names of the Engine or when setting the external names of the Portal. In the case of custom certificates that specify multiple subjects, a single server certificate may be used to protect all of the Engines and the Portal at the same time: master.crt
and slave.crt
would be the same certificate in this case. Please contact Customer Success Services if you need guidance on DNS configuration.
Configuring Nginx as WebSocket reverse proxy
The Collector TCP channel uses WebSocket as its application-level protocol. To configure nginx as a reverse proxy for the WebSocket protocol and thus redirect TCP Collector traffic, the Appliance includes an additional folder to store Nexthink-related configuration:
Log in to the CLI of the Appliance.
Create an additional configuration file for nginx in the folder reserved by the Appliance. The name is not important as long as the extension is .conf:
sudo vi /var/nexthink/nxnginx/conf.d/nxcollector-ws.conf
Press i and insert the content detailed below.
Press Esc to stop inserting text.
Type in the sequence :wq and press Enter to save the changes and exit the editor.
Stop and disable the proxy service in the Engine to avoid interference with the redirection of the TCP channel:
sudo systemctl stop nxproxysudo systemctl disable nxproxy
Restart nginx:
sudo systemctl restart nginx
Add a server directive to the configuration file for each Appliance that needs redirection. In the example below, the first server entry configures the redirection for the Portal (for Collector assignment), while the second entry configures an Engine:
Substitute the following keywords for actual values:
{Redirection_Appliance_IP}
The IP address of the redirection Appliance as seen from the Internet, if the Appliance is directly facing the Internet. Alternatively, if the redirection Appliance is inside a DMZ subnetwork managed by a router that does the address translation (NAT), this is the IP address of the redirection Appliance inside the DMZ. For example: listen 203.0.113.10:443 ssl;
{Portal_DNS_FQDN}
The Fully Qualified Domain Name of the Portal that returns the IP of the redirection Appliance when resolved by the Internet.For example server_name portal.example.com;
{Engine_DNS_FQDN}
The Fully Qualified Domain Name of the Engine that returns the IP of the redirection Appliance when resolved by the Internet.For example server_name engine1.example.com;
{Portal_Private_IP}
The IP address of the Portal as seen from inside the corporate network.
For example proxy_pass https://192.168.0.100:443;
{Engine_Private_IP}
The IP address of the Engine as seen from inside the corporate network.For example proxy_pass https://192.168.0.99:443;
The Internet names of the Portal and the Engine (respectively, Portal_DNS_FQDN and Engine_DNS_FQDN) must both resolve to the same IP address when resolved by a roaming device: the address of the redirection Appliance. The names themselves must be different for the reverse proxy to forward the traffic to the proper destination.
The example illustrates the use of the default TCP port 443 for the communication of the Collector with the Engine and the Portal. If you configured the Collectors and the Appliances to communicate through a different TCP port, substitute as well the default port number 443 for your own (the default custom port number is TCP 8443).
For each additional Engine that needs redirection, transfer the TLS certificates and add a new server entry to the configuration file, as described above.
RELATED TASKS
RELATED REFERENCES
Last updated