How to Automate Your VPN Setup With Ansible

In a , we set up a WireGuard VPN server and client and learned about various configuration options for WireGuard, how to improve VPN server uptime, how to relay traffic, and more. Setting up a server and client like that is a lot of work! If the server dies or you want to set up a new server (maybe for a friend or family member this time), you have to go back to the walk-through and follow all the steps, remembering if you deviated from those instructions at any point. previous blogpost There's a better way — automation! If you're only going to do a thing once (e.g. set up a VPN), investing in automation probably doesn't make sense. But if you anticipate doing a thing repeatedly, automating it frees up your time to learn and accomplish more in the future. You can also share your automation, empowering others to build and achieve more, faster. Automation is the heart of computing, and many different automation tools and approaches have sprung up over time. For our project of automating VPN server setup, we can consider a variety of tools: The simplest approach from a tooling perspective, writing shell scripts would involve running the commands from the , using ssh for the commands that run on the server and to copy configurations files to the server. Shell scripts previous WireGuard tutorial blogpost rsync If shell scripting isn't ideal, there are libraries that expose similar scripting functionality in a more ergonomic interface for developers familiar with higher-level languages like Ruby and Python. SSH scripting libraries like Capistrano or Fabric Tools in this category are even more specialized for automating server infrastructure and configuration, often including an ecosystem of packages and plugins to automatically set up or configure nearly anything you can think of. Infrastructure/configuration automation tools like Puppet , Chef , or Ansible Infrastructure-as-code (IaC) tools have a lot of overlap with the above category, but support provisioning cloud resources in a more first-class/native way. Infrastructure-as-code tools like Terraform You could also run WireGuard in containers, deploying a server-configured container image to a cloud provider and running a client-configured container image locally to connect to the server. There are of this approach. Containers like Docker a few existing examples For this tutorial, I'm going to focus on the middle category above — infrastructure / configuration automation tools — and specifically, I'll focus on Ansible. There is a by Gruntwork and, even though that article favors Terraform, Ansible is still a useful general-purpose tool, especially if you're working with servers that aren't "in the cloud", such as a Raspberry Pi at home. great comparison of different tools in this area Let's get started with automating VPN setup with Ansible! By the end of this article, we'll be able to set up a VPN server and client with a single command. Similar to the previous blogpost, I'll use Ubuntu 20.04 and DigitalOcean droplets. Setting Up Ansible Ansible can be like , but I prefer to use so I can get the latest updates and avoid cluttering system package management with third-party PPAs (Personal Package Archives). We'll also use (as suggested by ) to make sure we're not breaking or cluttering the system Python installation. Install with the following: installed via an OS package manager apt pip pyenv Hypermodern Python pyenv # From https: sudo apt-get update sudo apt-get install --no-install-recommends make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev curl https: //github.com/pyenv/pyenv/wiki#suggested-build-environment //pyenv.run | bash It's a good habit when a tutorial gives you to open up that URL and see what it's going to do. In this case, you'll see that it'll download and execute a shell script on GitHub that will clone 6 repos from GitHub to your folder and prompt you to add a few lines to your shell's initialization script. curl | bash ~/.pyenv Follow the output prompt from above, which asks you to put lines like the below in your shell initialization script (e.g. if you use the bash shell). Make sure to fill in your own username! ~/.bashrc PATH= export "/home/YOUR_USERNAME/.pyenv/bin:$PATH" eval "$(pyenv init -)" eval "$(pyenv virtualenv-init -)" Install a recent python version: # List available python versions pyenv install --list # Install a specific version pyenv install # (Suggested) If you want to always use that version when running # your terminal pyenv global 3.9 .2 `python` in 3.9 .2 If you want, you can also create a to further isolate the Ansible installation, and make that virtualenv automatically activate when you're in a particular folder/repo. That would look like: virtualenv pyenv virtualenv ansible-tutorial pyenv local ansible-tutorial # (Optional) # Feel free to pick a different virtualenv name than "ansible-tutorial" 3.9 .2 # Create a .python-version file that pyenv will find when your shell is in the # same directory (or a sub-directory) and automatically activate the named # virtualenv Install the pip package, which will install various command-line tools, including , which we'll use to run a "playbook" of commands that will set up a VPN server and client for us. ansible ansible-playbook pip install ansible ansible --version # Confirm installation worked Get a Server To use Ansible for a VPN server, we need… a server! Ansible could provision a server from a cloud provider for us (and I'll touch on this briefly later), but we'll keep our playbook hardware-provider-agnostic for now, so you can run it as easily against a cloud server as a Raspberry Pi on your home network. I'm going to to test against, but you could also (to test against a local VM) or any server you can SSH to. create a $5/month DigitalOcean droplet use Vagrant Testing Ansible playbooks against VMs, rather than a bare-metal machine, comes with an advantage — after you've written the playbook, you can start a new, empty VM and test the whole playbook start to finish to ensure that it works consistently. Connecting to the Server with Ansible Once you have your server or VM, take note of its IP address use it to create an file like the below: inventory.ini [vpn] vpn_server ansible_host= ansible_user=root 203.0 .113 .1 An tells Ansible what servers it can act upon and how to access them. Let's use the above inventory file as an example. When we run Ansible and target the of servers or the , it will try to connect to the server using a command like: inventory file vpn group vpn_server host ssh root@ 203.0 .113 .1 So, if you can't SSH to the server, then Ansible won't be able to connect either! Connecting to the server with an SSH key is strongly recommended! to connect without needing a password. If you must connect with a password, you can and then provide your SSH password when using Ansible by adding the flag to all ansible commands. Add your SSH key to your server sudo apt install sshpass --ask-pass Let's test to make sure that Ansible can connect to the server: ansible -i inventory.ini -m ping vpn This runs the , targeting the group of servers. You should see "pong" in the output, meaning that Ansible could connect to the server and the server has a Python installation that Ansible can use. ping Ansible module vpn Ansible's Built-in Variables and Facts There are other useful Ansible modules that we can use with the command: ansible The fetches , about the server. You can use these facts as variables in Ansible commands and playbooks. setup module system information, also known as "facts" The can evaluate variables, which is useful for… well, debugging! debug module Try running both of these modules with your server so you can see what facts and information Ansible makes available: ansible -i inventory.ini -m setup vpn ansible -i inventory.ini -m debug -a vpn "var=hostvars" This was one of the most confusing parts for me when learning Ansible — figuring out what all these built-in variables and facts (like , , and ) were and how to find them. groups inventory_dir ansible_distribution Writing an Ansible Playbook The command lets you run across groups of servers. This is powerful, but we probably shouldn't try to automate server setup and configuration in a single command… probably. 🤔 Instead, we can organize multiple tasks in one or multiple YAML files, which we will run with the command. ansible ad-hoc commands ansible ansible-playbook Let's write a file In the same folder as . Here are its contents: playbook.yml inventory.ini --- - name: setup vpn server hosts: vpn_server tasks: - name: ping ping: - name: show variables facts debug: var=hostvars and If you're not familiar with , the above is equivalent to this JSON structure: YAML [{ : , : , : [{ : , : }, { : , : }]}] 'name' 'setup vpn server' 'hosts' 'vpn_server' 'tasks' 'name' 'ping' 'ping' None 'name' 'show variables and facts' 'debug' 'var=hostvars' Breaking down the above: The top-level structure is a "play" in Ansible lexicon. Our play above has a , a which describes which servers the play will run against, and a list of . name hosts pattern tasks We have 2 tasks, each has a and the name of an Ansible module that will do something. name Run the playbook... ansible-playbook -i inventory.ini playbook.yml … and you'll see that it gathers facts from the server (just like the setup command above did), and then runs the "ping" task and the "debug" task to show all the gathered facts and variables defined for . ansible -m vpn_server There are tons of , even more , and even more published to (an open repository for Ansible collections and roles). built-in Ansible modules curated Ansible community modules Ansible Galaxy WireGuard Server Setup There's much more to learn about Ansible! But let's stop here and apply what we've learned in order to set up a WireGuard server. Referring to the steps we took in , we want to: the previous tutorial Install the system package wireguard Create public and private keys with correct permissions Create the server's WireGuard configuration file (Optionally) Enable IP forwarding for relaying traffic Start the VPN Managing the Keys As , if we want to repeatably deploy the VPN server without needing to reconfigure all VPN clients, we need to use the same private key every time. hinted at in the previous tutorial Put another way: if we generated a private key while deploying the server and used the corresponding public key on various clients, and the server ends up dying, we deploy it again by generating a new private key. However, all of our VPN clients would then need to update to the public key to be able to connect to the VPN server. This would be inconvenient! could new new Instead, we'll generate the server keys once by hand and use them in the playbook so they're consistent between every deploy. This means we won't include step #2 from above in the Ansible playbook. Generate the keys with and commands. You can output both with the following command: wg genkey wg pubkey privkey=$(wg genkey) sh -c 'echo " server_privkey: $privkey server_pubkey: $(echo $privkey | wg pubkey)"' Copy the output lines and add them to a new mapping under the play in . Here's what mine looks like now (your keys will be different): vars playbook.yml --- - name: setup vpn server hosts: vpn_server vars: server_privkey: aBYk1JZyP8ck+FeaTjb3xi94U4Nv8V+gWoTW1hRLQlo= server_pubkey: / f7bUT+ hWMEP5BxeK51PGuMuTnQ9pRpkxg5jUSTo= tasks: # ... 7 6 2 Encrypting the Private Key It's a good practice to AVOID having secrets in plaintext (like the VPN private key above). This is especially true if those secrets will be shared with anyone else, like via a git repo. Let's prevent this by using . Vault is a tool for encrypting secret values and using them in playbooks. Encrypt the private key with: Ansible Vault ansible-vault encrypt_string --ask-vault-password --stdin-name server_privkey You'll be prompted twice for a Vault encryption password, after which you'll paste your value and hit twice. If the command completed after a single , try again and make sure you're not copy-pasting an invisible newline character at the end of the value. Copy the output into your playbook, which will now look like: privkey Ctrl+d Ctrl+d privkey --- - name: setup vpn server hosts: vpn_server vars: server_privkey: !vault | $ANSIBLE_VAULT; ;AES256 a31326664 a3936353033663263 server_pubkey: / f7bUT+ hWMEP5BxeK51PGuMuTnQ9pRpkxg5jUSTo= tasks: ... 1.1 646438636565343063343631326136386239623935393637336539653636386135363 663386639393232346534643163656363316234306439306566306534610 363763663139383034636632343230376365333130333230373866353033326563303 5636138373830633534373033303536303566663166616539360 336662663034376661616631343661333164363134373061343739633637623739306 465653532383838393662396333623966343165366635353132396332313762343534 65313761623964653532623839356633343838 7 6 2 Make sure to remember your encryption password (and save it in a password manager); you'll need to enter it every time you run the playbook. Installing and Configuring WireGuard Next, we'll remove our testing and tasks and write tasks for steps 1, 3, 4, and 5 from the above list. These steps translate neatly into Ansible tasks in our updated : ping debug playbook.yml --- - name: setup vpn server hosts: vpn_server vars: server_privkey: !vault | $ANSIBLE_VAULT; ;AES256 a31326664 a3936353033663263 server_pubkey: / f7bUT+ hWMEP5BxeK51PGuMuTnQ9pRpkxg5jUSTo= tasks: - name: install wireguard package apt: name: wireguard state: present update_cache: yes - name: create server wireguard config template: dest: /etc/wireguard/wg0.conf src: server_wg0.conf.j2 owner: root group: root mode: - name: enable persist ip forwarding sysctl: name: net.ipv4.ip_forward value: state: present sysctl_set: yes reload: yes - name: start wireguard enable on boot systemd: name: wg-quick@wg0 enabled: yes state: started 1.1 646438636565343063343631326136386239623935393637336539653636386135363 663386639393232346534643163656363316234306439306566306534610 363763663139383034636632343230376365333130333230373866353033326563303 5636138373830633534373033303536303566663166616539360 336662663034376661616631343661333164363134373061343739633637623739306 465653532383838393662396333623966343165366635353132396332313762343534 65313761623964653532623839356633343838 7 6 2 # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/copy_module.html '0600' # https://docs.ansible.com/ansible/latest/collections/ansible/posix/sysctl_module.html and "1" # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/systemd_module.html and Ok ok, yes, this is a bit like drawing an owl. Source …but usually an ansible playbook like the above can be written quickly. I follow a cycle: Type "ansible module install package" into a search engine Open the result that looks most helpful docs.ansible.com Read through available parameters and the (often helpful) examples at the bottom Copy an example into my playbook and modify parameters as needed Go back to step 1, searching for the next task (e.g. "ansible module template file") I've included a comment line linking to the Ansible docs page for each module used in the above, in case you want to read about the parameters. playbook.yml Testing our First Attempt Let's test our playbook. $ ansible-playbook -i inventory.ini --ask-vault-password playbook.yml Vault password: PLAY [setup vpn server] ******************************************************** TASK [Gathering Facts] ********************************************************* ok: [vpn_server] TASK [install wireguard package] *********************************************** changed: [vpn_server] TASK [create server wireguard config] ****************************************** fatal: [vpn_server]: FAILED! => { : false, : } PLAY RECAP ********************************************************************* vpn_server : ok= changed= unreachable= failed= skipped= rescued= ignored= "changed" "msg" "Could not find or access 'server_wg0.conf.j2'\nSearched in: ..." 2 1 0 1 0 0 0 Oh no! Installing WireGuard was successful, but creating the config failed. Ansible's error messages are usually helpful, and this one indicates that the template file ( ) we're trying to use to create the server's configuration couldn't be found. server_wg0.conf.j2 Let's create it at : templates/server_wg0.conf.j2 # {{ ansible_managed }} [Interface] Address = / ListenPort = PrivateKey = {{ server_privkey }} 10.0 .1 .1 24 51820 A few notes about the above: Ansible automatically searches in relative paths like and when running Ansible modules that have a parameter. Our task has a parameter , so Ansible will search for it in the folder. templates/ files/ src template src: server_wg0.conf.j2 templates/ It's convention to suffix template files with , to indicate that the file will be . .j2 templated with Jinja2 In Jinja2, values inside double curly braces ( ) will be replaced with the value of the variable. In this template, the variable will be decrypted and its value inserted into the resulting file in place of . {{ variable }} server_privkey {{ server_privkey }} The text is replaced with the string "Ansible managed". It's a good convention to put this in a comment at the top of templated files, because it signals to anyone reading the file on the server that the file is managed by Ansible — any edits they make could be overwritten when Ansible next runs, so they should find and make edits in the corresponding Ansible playbook and template files instead. {{ ansible_managed }} Let's run the test again: $ ansible-playbook -i inventory.ini --ask-vault-password playbook.yml Vault password: PLAY [setup vpn server] ******************************************************** TASK [Gathering Facts] ********************************************************* ok: [vpn_server] TASK [install wireguard package] *********************************************** ok: [vpn_server] TASK [create server wireguard config] ****************************************** changed: [vpn_server] TASK [enable and persist ip forwarding] **************************************** changed: [vpn_server] TASK [start wireguard and enable on boot] ************************************** changed: [vpn_server] PLAY RECAP ********************************************************************* vpn_server : ok= changed= unreachable= failed= skipped= rescued= ignored= 5 3 0 0 0 0 0 It succeeded! The WireGuard interface is now running on the server. Notice that the "install wireguard package" step shows instead of this time. The module (and most modules) detect that the server is already in the desired state (the package was installed last time we ran the playbook, so it satisfies ) and perform no actions. The task is , meaning you can run it repeatedly and the outcome is the same. Idempotent tasks make it easy to see what changed and what didn't each time a playbook is run. ok changed apt wireguard state=present idempotent WireGuard Client Setup Ansible can also operate on the local machine. To set up our local machine as a client, we want to: Install the system package wireguard Create public and private keys with correct permissions Create the client's WireGuard configuration file, which must include the server's public key Start the VPN We also need to update the server's configuration file with a section including the client's public key, so the client can connect to the server. The client's public key isn't known until after we create it — we could create client keys manually like we did for the server's keys, but then the playbook wouldn't be able to set up multiple clients without having to manually edit the keys for each client. [Peer] Acting on Localhost Because we're targeting a new host ( ), we need to write a new play in . We can put it above the existing play (which targets ), so the client's keys are generated before the server config is templated. localhost playbook.yml vpn_server --- - name: setup vpn client hosts: localhost connection: local become: yes vars: ansible_python_interpreter: tasks: - name: setup vpn server hosts: vpn # Use system python so apt package is available "/usr/bin/env python" # Coming soon # Rest of server vars/tasks here... Lots of new things here! We target the local machine with using for the hosts pattern. [localhost](http://localhost) We "connect" locally by using the . local connection plugin The line indicates that the play will run as root, which we need to be able to install the package. Ansible will effectively run , rather than just (which would fail). Because of this setting, we'll need to run the playbook with the flag. We didn't need this line for the server setup play, because we're already connecting as root via the connection variable. become: yes wireguard sudo apt-get install wireguard apt-get install wireguard --ask-become-pass ansible_user=root With the var, we tell Ansible to use the system python (which includes the python package). Alternatively, we could for our current python 3.9.2 installation. If you get a error, you may need to change the line from to . ansible_python_interpreter apt install that package No such file or directory python python3 Client Setup Tasks and Config Writing the Ansible tasks for the client-side VPN setup is similar to the server side. --- - name: setup vpn clients hosts: localhost connection: local become: yes vars: ansible_python_interpreter: tasks: - name: install wireguard package apt: name: wireguard state: present update_cache: yes - name: generate private key shell: cmd: umask && wg genkey | tee privatekey | wg pubkey > publickey chdir: /etc/wireguard creates: /etc/wireguard/publickey - name: get public key command: cat /etc/wireguard/publickey register: publickey_contents changed_when: - name: set public key fact set_fact: pubkey: - name: create client wireguard config template: dest: /etc/wireguard/wg0.conf src: client_wg0.conf.j2 owner: root group: root mode: - name: setup vpn server hosts: vpn_server # Use system python so apt package is available "/usr/bin/env python" 077 False # Save pubkey as a fact, so we can use it to template wg0.conf for the server "{{ publickey_contents.stdout }}" '0600' # Rest of server vars/tasks here... Breaking this down: Installing the package should look very familiar! wireguard We generate keys with the module so we can use pipes and file redirection. The keys are only generated if the file doesn't already exist, thanks to the parameter. shell publickey creates Next, we need to save the public key so we can add it as a section in the server config. Normally, we'd use to look up a value from a file, but the file lookup modules seems not to respect ; it tries to read the file without escalating to root privileges and fails as a result. So, we instead the file and save the resulting output as a fact. [Peer] {{ lookup('file', '/etc/wireguard/publickey') }} become: yes cat Finally, template the client config file. Its contents closely match the , but we use the IP address of the VPN server from to set the server's endpoint. previous tutorial's ansible_host inventory.ini [Interface] Address = / PostUp = wg set %i private-key /etc/wireguard/privatekey PostUp = ping -c1 [Peer] PublicKey = {{ server_pubkey }} Endpoint = {{ hostvars[ ].ansible_host }}: AllowedIPs = / # The address your computer will use on the VPN 10.0 .0 .8 32 # Load your privatekey from file # Also ping the vpn server to ensure the tunnel is initialized 10.0 .0 .1 # VPN server's wireguard public key # Public IP address of your VPN server (USE YOURS!) # Use the floating IP address if you created one for your VPN server 'vpn_server' 51820 # 10.0.0.0/24 is the VPN subnet 10.0 .0 .0 24 # To also accept and send traffic to a VPC subnet at 10.110.0.0/20 # AllowedIPs = 10.0.0.0/24,10.110.0.0/20 # To accept traffic from and send traffic to any IP address through the VPN # AllowedIPs = 0.0.0.0/0 # To keep a connection open from the server to this client # (Use if you're behind a NAT, e.g. on a home network, and # want peers to be able to connect to you.) # PersistentKeepalive = 25 Managing Variables If we run the playbook now, it will fail with a error. That's because is defined for the play that targets the , it's not available for the play targeting the . We need to move the variable somewhere so that it's readable by the entire playbook. where the filename matches server groups in the inventory file. So, we could create a file and declare variables in it, which would be directly usable when running a play against any servers in the group. We don't include as a host in the group (though we could). We'll instead use the special file, which makes variables available to all hosts. 'server_pubkey' is undefined server_pubkey server client Ansible looks for YAML files in a folder group_vars/ group_vars/vpn.yml vpn localhost vpn group_vars/all.yml Move the server keys' variables from to : playbook.yml group_vars.all.yml --- server_privkey: !vault | $ANSIBLE_VAULT; ;AES256 a31326664 a3936353033663263 server_pubkey: / f7bUT+ hWMEP5BxeK51PGuMuTnQ9pRpkxg5jUSTo= 1.1 646438636565343063343631326136386239623935393637336539653636386135363 663386639393232346534643163656363316234306439306566306534610 363763663139383034636632343230376365333130333230373866353033326563303 5636138373830633534373033303536303566663166616539360 336662663034376661616631343661333164363134373061343739633637623739306 465653532383838393662396333623966343165366635353132396332313762343534 65313761623964653532623839356633343838 7 6 2 Your directory should now look like this: . ├── group_vars │ ├── all.yml ├── inventory.ini ├── playbook.yml └── templates ├── client_wg0.conf.j2 └── server_wg0.conf.j2 Run the playbook and the client should run all its tasks successfully: ansible-playbook -i inventory.ini --ask-vault-password --ask-become-pass playbook.yml The VPN client is now set up. The only remaining step for the client is to start the VPN after the server is running and configured to accept connections from the client (so the client's ping will succeed). PostUp Adding a Peer to the Server Config Add a section to the server template at : [Peer] templates/server_wg0.conf.j2 # {{ ansible_managed }} [Interface] Address = / ListenPort = PrivateKey = {{ server_privkey }} [Peer] PublicKey = {{ hostvars[ ].pubkey }} AllowedIPs = 10.0 .0 .1 24 51820 'localhost' 10.0 .0 .8 We read the from and we read from the module that runs during the client-targeted play in the playbook. {{ server_privkey }} group_vars/all.yml {{ hostvars['localhost'].pubkey }} set_fact Reloading the Server Config If we run the playbook, the config file on the server will be updated with the new section, but the WireGuard interface is already running and configured based on the old file contents. We need to reload the configuration when it changes. are the Ansible-provided mechanism for this, and they trigger when a task referencing them . Handlers run at the end of the play in which they're notified, so many tasks could notify a "reload config" handler, but the handler would only run once at the end. Let's create a couple handlers in a list after the lists in and notify them from the and tasks: [Peer] Handlers changes handlers tasks playbook.yml create client wireguard config create server wireguard config - name: create client wireguard config template: dest: /etc/wireguard/wg0.conf src: client_wg0.conf.j2 owner: root group: root mode: notify: restart wireguard handlers: - name: restart wireguard shell: wg-quick down wg0; wg-quick up wg0 args: executable: /bin/bash - name: setup vpn server hosts: vpn_server tasks: - name: create server wireguard config template: dest: /etc/wireguard/wg0.conf src: wg0.conf.j2 owner: root group: root mode: notify: reload wireguard config handlers: - name: reload wireguard config shell: wg syncconf wg0 <(wg-quick strip wg0) args: executable: /bin/bash # ... '0600' # Restarts WireGuard interface, loading any new config and running PostUp # commands in the process. Notify this handler on client config changes. # ... '0600' # ... # Reloads config without disrupting current peer sessions, but does not # re-run PostUp commands. Notify this handler on server config changes. # ... The Ansible module only performs an action and marks the task as if the config file changes — it is idempotent. Idempotence is valuable when used with handlers, because the handler will only run when the task changes. Notifying a handler on a task that isn't idempotent may result in the handler always running (e.g. a service is unnecessarily restarted everytime the playbook is run). template changed Start the VPN Client Add one final play to the end of the playbook to start the client VPN now that the server is configured to accept its connection: # ... - name: start vpn on clients hosts: localhost connection: local become: yes tasks: - name: start vpn command: wg-quick up wg0 Automation Complete! Now we can run the whole playbook and — whether the server and client are brand-new or in some intermediate state — this single command will set up a WireGuard VPN server and client! ansible-playbook -i inventory.ini --ask-vault-password --ask-become-pass playbook.yml The complete Ansible code can be found at: https://gitlab.com/tangram-vision-oss/tangram-visions-blog/-/tree/main/AnsibleVpnSetup There are many improvements that could be made: Provision a cloud server automatically, using an Ansible module such as . community.digitalocean.digital_ocean_droplet Automatically when provisioning a new cloud VPN server. update a floating IP address Configure multiple clients automatically. One approach is to add a group to the inventory, define VPN IPs in the inventory (e.g. ), and use those host variables in the config templates. When templating the server config, over hostnames in the clients group, adding a new block for each. vpn_clients vpn_ip=10.0.0.8 loop [Peer] Organize the playbook as , one for the server and one for the client. Roles are more reusable and shareable than playbooks. roles Test and lint with and . molecule ansible-lint Thanks for joining me on this Ansible-learning journey! If you have any suggestions or corrections, please let me know or , and if you’re curious to learn more about how we improve perception sensors, visit us at . send us a tweet Tangram Vision Previously published here .