MeshCentral now with reverse-proxy support
MeshCentral is an open source web based remote management server. This last week, MeshCentral was improved again with support for reverse-proxies that allow for improved scalability and flexibility when deploying MeshCentral as a web service. Any serious network administrator will know about reverse-proxies, notably NGINX but many others exists. There are many benefits including more flexibility in how a web server is configured, allows many web applications can run together on the same server, TLS offloading and load balancing. As more people deploy MeshCentral2, it’s became a more frequent request to add proper support for reverse proxies, notably NGINX.
This week, a new version of MeshCentral was released on NPM along with a new MeshCentral User’s Guide 0.1.8 and a YouTube video with a tutorial on how to support NGINX. MeshCentral has an interesting design where the Mesh Agents connect to the server using web sockets on the same port that users connect on with browsers. This makes it easy to setup as only one port (HTTPS/443) is required to make most of MeshCentral2 work. For agents to authenticate to the server, we need to perform a secondary signature check with a fixed “agent certificate”, this is done so that we can update the web certificate frequently and still have the mesh agents connect correctly to the server. The new reverse proxy setup instructions take care of everything, including offloading TLS for Intel® AMT CIRA connections.
This last week, we added a new feature in MeshCentral allowing it to load the web certificate from the reverse-proxy. We also added code to handle added HTTP headers placed by the reverse proxy so that we can get the real IP address & hostname of the connecting clients & agents that a reverse-proxy would otherwise hide. In the end, we have the most flexible and scalable MeshCentral and this for all incoming connections (Browsers, Agents and Intel® AMT).
In other news:
Ylian
Twitter: https://twitter.com/meshcentral
This week, a new version of MeshCentral was released on NPM along with a new MeshCentral User’s Guide 0.1.8 and a YouTube video with a tutorial on how to support NGINX. MeshCentral has an interesting design where the Mesh Agents connect to the server using web sockets on the same port that users connect on with browsers. This makes it easy to setup as only one port (HTTPS/443) is required to make most of MeshCentral2 work. For agents to authenticate to the server, we need to perform a secondary signature check with a fixed “agent certificate”, this is done so that we can update the web certificate frequently and still have the mesh agents connect correctly to the server. The new reverse proxy setup instructions take care of everything, including offloading TLS for Intel® AMT CIRA connections.
This last week, we added a new feature in MeshCentral allowing it to load the web certificate from the reverse-proxy. We also added code to handle added HTTP headers placed by the reverse proxy so that we can get the real IP address & hostname of the connecting clients & agents that a reverse-proxy would otherwise hide. In the end, we have the most flexible and scalable MeshCentral and this for all incoming connections (Browsers, Agents and Intel® AMT).
In other news:
- The MeshCentral and MeshCommander blog and web site both got a complete redesign.
- MeshCentral now supports “view-only” remote desktop user permission.
- Many more bug fixes have been done to MeshCentral2.
Ylian
Twitter: https://twitter.com/meshcentral
This is how MeshCentral2 is setup normally. Mesh agents connects to port 443 with web socket, see the outer TLS web certificate and validate the server using an inner agent certificate. Intel® AMT CIRA connections are binary over TLS.
With NGINX handling all TLS connections, MeshCentral2 reads the NGINX certificate and handles the added NGINX HTTP headers. Intel® AMT CIRA connections are handled the normal way, with NGINX doing TLS.
YouTube Demonstration Video: https://www.youtube.com/watch?v=ebDVAsistbk
