Ansible integration in MeshCentral WAN mode !

[siliconhippy]

Been reading for a couple hours as I have looked into Cloud /WAN mode for managing multiple devices behind NAT in LANs: been trying Cloudflare tunnels (Wireguard VPN) with Cockpit (for Linux.) Of course Windows RDP could also work here.

But MeshCentral takes the cake with so many features and AIO setup- no LAN port forwarding or separate tunnel /VPN setup required for WAN remote management !

So, can WAN mode MeshCentral also integrate with Ansible (agentless configuration management tool)? Or, could MeshCentral Device Groups perform similar scripts automation to manage/update devices ?

[Ylianst]

I have never used Ansible so, not sure I can be of much help. One thing to note is that MeshCentral Router can forward any TCP connect to any device (video here) so, you may be able to plug Ansible to that.

[veitw]

@siliconhippy : If you want to use the SSH transport, MeshCentral's integrated SSH client itself will not work for this.

But as @Ylianst mentioned, you could locally forward the remote machines' SSH ports through the reverse connection to MC, and through MeshCentral Router to your local machine. This means that MeshCentral Router will open a port on localhost, let's say 127.0.0.1:3000/tcp, that you can connect to locally. Once you connect via e.g. ssh -p 3000 user@127.0.0.1, MeshCentral Router will forward it to MeshCentral, then from MeshCentral to the MeshAgent on your remote machine, and there from MeshAgent to 127.0.0.1:22/tcp. The same applies to Ansible, when you use the SSH transport to connect to 127.0.0.1:3000.

Unfortunately, so far MeshCentral Router is only available for Microsoft Windows and with limited functionality for Apple macOS. For other OS there is currently no MeshCentral Router. But there are two possible ways to work around this:

1. The MeshCmd command line tool can forward network connections, too (TCP only). If you execute it using a meshactions.txt file defining the target machines, local and remote ports, as well as a MeshCentral login with appropriate permissions to set this up (which can be a login token bound to your MC user), it would also be possible to script this. All information you need to create the meshactions.txt such as the remote machines' node IDs can be obtained using MeshCentral's other command line tool, MeshCtrl.

2. The RoutePlus plugin by @ryanblenis allows you to use a MeshAgent installed locally to act as a replacement for MeshRouter. You configure within MeshCentral, remote machines and ports you want to forward, and then select which MeshAgent belongs to your local machine. The plugin will then let your local MeshAgent to bind the ports and forward connections to the remote target MeshAgent.

[mobycloud]

Viet and Ylianst,

Thanks so much for quick responses 😜 I read somewhere that "the developer is passionate about the project...great community." True...also given updated videos.

The other question: Ansible, agentless configuration tool ( Puppet, Salt* need agents, which Ansible also will with reverse connection called Ansible-pull), like all tools requires an IP address to connect to clients.

So I am wondering - Ansible might connect Linux as above suggestion.

But how could Ansible gain access to MeshCentral tunnels for individual devices managed? Any MeshCentral configuration file here?

I would like to use MeshCentral as remote management tool on Cloud for Servers/ devices in multiple LANs behind NAT. But I also need authentication and authorization plus Ansible automated management as a nice full FOSS package.

The alternative is using Cloudflare tunnels ( previously Argo tunnels.) And write custom code (aka buggy hell) for Cloud DB authentication and authorization. Then Linux Cockpit for remote management, comparable to MeshCentral.

But MeshCentral seems ideal as it sets up auto tunnels, and does remote management; and seems to have plugs for SAML2.0 for remote authentication and authorization.

Azure AD with OAuth2 can only do authentication, and of course costs big money like Cloudflare ( $7/user/month after first 20 free users !)

https://blog.cloudflare.com/ridiculously-easy-to-use-tunnels/

Any further insights are appreciated 👍 Also LDAP might not help here if devices are scattered. The whole idea is Cloud ( independent of local routers/ permissions.)

Just note please that we here are talking about home based devices or IoT hobby/ experimental stuff not some enterprise project with loads of $$ budget ! 🐱

[veitw]

@mobycloud AFAIK forwarding ports in reverse from the agents/managed devices to the user machine has not yet been implemented beside the possibilities RoutePlus offers for this, although it is not intended to be used this way round and thus would be limited. But maybe you could use RoutePlus as a base to implement this feature in your own plug-in?

I am nor sure whether @Ylianst would like to implement and/or see this in MC directly, as I think this might exceed the purposes he intends MC to have, but I think you should create a feature request issue for this.

If you are fine with reverse connections from the managed device to the user machine to only be available while the managed device is being managed by a user, and TCP connections do suffice, you could simply use reverse port forwarding in SSH while you SSH to the remote machine through MC routing.

But maybe setting up a VPN server using Wireguard, OpenVPN or IPsec/L2TP via FreeS/WAN or Openswan as a true network-transparent solution could be a better fit to your intended use. Those are free and open source projects, too, so there is no need to pay horrendous per-user fees to VPN providers like Cloudflare.

[veitw]

One should add the following extra information:

• OpenVPN can work in TCP mode, so such a VPN would work in all situation where MC would work, too, without changes to firewalls.

• Even SSH is able to act as a VPN server via a regular TCP SSH connection, although configuration is usually more complex than using e.g. OpenVPN.

• If a VPN server and the corresponding firewalling to prevent the managed devices to speak to each other is too complex for the intended purpose, you could consider using reverse SSH, instead: Reverse SSH means that the managed device, which could reside behind firewalls preventing incoming connections, opens a pubkey authenticated SSH connection to a management server, opening one or more remote TCP forwardings on the management server. To connect to a managed device, the user connects to one of these remote forwarded ports on the management machine, and the connection is tunneled through the reverse SSH connection to the managed device. Other agent connections such as puppet can be forwarded through the reverse SSH connections using local port forwardings instead of remote port forwardings, too. Using reverse SSH is as simple as running the SSH client as a service on the managed devices, that automatically restarts in an infinite loop when SSH exits. The challenge on the client-side is to configure SSH to detect dead connections reliably and timely by setting keep-alives and timeouts, and on the server-side to configure permissions for the pubkeys to not execute any commands and only allow certain remote forwarding ports to be bound.

[siliconhippy]

Viet,

Really appreciate your details 🤠 Yes we have been looking at both reverse SSH setup, and also Zero Tier, plus Cloudflare tunnels ( Wireguard VPN) as I said above.

So let me think more about it and revert. MeshCentral is a fantastic project...

[prononext]

Nice, I was also thinking about connecting ansible via meshctrl hopefully this can proceed. 🤠

[si458]

closing as stale, but also look into using the meshctrl as it has features like adding devices, moving groups, device info, etc...