In this post:
-
Learn how to set up the vpn RHEL System Role to quickly and easily implement host-to-host VPN connections across your RHEL environment in an automated manner.
In today's world where organizations frequently use multiple cloud providers, datacenters, and systems in edge environments, secure communication between these distributed systems is essential. Host-to-host VPN tunnels allow for encrypted communication between systems, and are frequently used when traffic needs to traverse untrusted networks such as the public internet.
While host-to-host VPN tunnels can be implemented on Red Hat Enterprise Linux (RHEL) manually, this can be time consuming and error-prone. Red Hat introduced the VPN RHEL System Role in RHEL 8.5 to provide an automated solution to implement host-to-host VPN connections, as well as opportunistic mesh VPNs.
RHEL System Roles are a collection of Ansible roles and modules that are included in RHEL to help provide consistent workflows and streamline the execution of manual tasks. For more information on VPNs in RHEL, refer to the configuring a VPN with IPsec documentation.
Environment overview
In my example environment, I have a control node system named controlnode running RHEL 8 and four managed nodes: rhel8-server1, rhel8-server2, rhel7-server1, and rhel7-server2 (the first two running RHEL 8, and the other two running RHEL 7).
![Figure 1. Figure 1.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image2_80_0.png.webp?itok=g9OUbOv7)
I would like to configure a host to host VPN tunnel between each of these four systems, as shown:
![Figure 2. Figure 2.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image3_60_0.png.webp?itok=0yKHK5Xk)
Each host-to-host VPN tunnel connects two hosts together and must be configured on both hosts. This means that each of the four managed nodes will have three host-to-host tunnel configurations implemented.
I’ve already set up an Ansible service account on the five servers, named ansible, and have SSH key authentication set up so that the ansible account on controlnode can log in to each of the systems. In addition, the ansible service account has been configured with access to the root account via sudo on each host.
I’ve also installed the rhel-system-roles and ansible packages on controlnode. For more information on these tasks, refer to the Introduction to RHEL System Roles post.
In this environment, I’m using a RHEL 8 control node, but you can also use Ansible automation controller or Red Hat Satellite as your RHEL system roles control node. Ansible automation controller provides many advanced automation features and capabilities that are not available when using a RHEL control node.
For more information on Ansible automation controller and its functionality, refer to this overview page. For more information on using Satellite as your RHEL system roles control node, refer to Automating host configuration with Red Hat Satellite and RHEL System Roles.
Defining the inventory file and role variables
From the controlnode system, the first step is to create a new directory structure:
[ansible@controlnode ~]$ mkdir -p vpn/group_vars
These directories will be used as follows:
-
The vpn directory will contain the playbook and the inventory file.
-
The vpn/group_vars file will contain variable files for inventory groups that will apply to hosts in the respective Ansible inventory groups.
I need to define an Ansible inventory file to list and group the hosts that I want the vpn System Role to configure. I’ll create the main inventory file at vpn/inventory.yml with the following content:
all: children: host_to_host_vpn: hosts: rhel8-server1: rhel8-server2: rhel7-server1: rhel7-server2:
|
This inventory defines an inventory group named host_to_host_vpn, and assigns the four managed nodes to this inventory group.
Next, I’ll define the role variables that will control the behavior of the vpn System Role when it runs. The README.md file for the vpn role, available at /usr/share/doc/rhel-system-roles/vpn/README.md, contains important information about the role including a list of available role variables and how to use them.
I’ll create a file that will define variables for my managed nodes listed in the host_to_host_vpn inventory group by creating a file at vpn/group_vars/host_to_host_vpn.yml with the following content:
vpn_connections: - hosts: rhel8-server1: rhel8-server2: rhel7-server1: rhel7-server2: auto: start
In this example, I’m using the vpn_connections variable to specify information on my desired VPN configuration, including the list of hosts that should be configured with host-to-host VPN tunnels and setting the auto variable to start.
Creating the playbook
The next step is creating the playbook file at vpn/vpn.yml with the following content:
- name: Open Firewall for ipsec hosts: host_to_host_vpn tasks: - firewalld: service: ipsec permanent: yes immediate: yes state: enabled - hosts: host_to_host_vpn roles: - rhel-system-roles.vpn
The first task, Open Firewall for ipsec, runs on the four managed nodes in the host_to_host_vpn inventory group, and opens the firewall for the ipsec service.
The second task, also running on the four managed nodes in the host_to_host_vpn group, runs the vpn RHEL System Role.
|
Running the playbook
At this point, everything is in place, and I’m ready to run the playbook. For this demonstration, I’m using a RHEL control node and will run the playbook from the command line. I’ll use the cd command to move into the vpn directory, and then use the ansible-playbook command to run the playbook.
[ansible@controlnode ~]$ cd vpn [ansible@controlnode vpn]$ ansible-playbook vpn.yml -b -i inventory.yml
I specify that the vpn.yml playbook should be run, that it should escalate to root (the -b flag), and that the inventory.yml file should be used as my Ansible inventory (the -i flag).
After the playbook completes, I verified that there were no failed tasks:
![Figure 3. Figure 3.](/rhdc/managed-files/styles/wysiwyg_full_width/private/image4_42_0.png.webp?itok=Qiz1lI_y)
|
Validating the configuration
I can login to each of the managed nodes to validate that the VPN configuration is set up correctly. I’ll start by logging in to rhel8-server1:
[ansible@rhel85beta vpn]$ ssh rhel8-server1
Once logged on, I can run sudo ipsec trafficstatus to see the three host to host VPN tunnels:
[ansible@rhel8-server1 ~]$ sudo ipsec trafficstatus 006 #5: "rhel8-server1-to-rhel7-server1", type=ESP, add_time=1636554445, inBytes=0, outBytes=0, id='@rhel7-server1' 006 #6: "rhel8-server1-to-rhel7-server2", type=ESP, add_time=1636554445, inBytes=0, outBytes=0, id='@rhel7-server2' 006 #4: "rhel8-server1-to-rhel8-server2", type=ESP, add_time=1636554445, inBytes=0, outBytes=0, id='@rhel8-server2'
Each line shows the inBytes and outBytes as 0. To generate show traffic, I can ping each of the other hosts:
[ansible@rhel8-server1 ~]$ for host in rhel7-server1 rhel7-server2 rhel8-server2; do ping -c 4 $host; done PING rhel7-server1 (192.168.0.57) 56(84) bytes of data. 64 bytes from rhel7-server1 (192.168.0.57): icmp_seq=1 ttl=64 time=0.907 ms 64 bytes from rhel7-server1 (192.168.0.57): icmp_seq=2 ttl=64 time=0.860 ms 64 bytes from rhel7-server1 (192.168.0.57): icmp_seq=3 ttl=64 time=0.832 ms 64 bytes from rhel7-server1 (192.168.0.57): icmp_seq=4 ttl=64 time=0.771 ms --- rhel7-server1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 0.771/0.842/0.907/0.057 ms PING rhel7-server2 (192.168.0.58) 56(84) bytes of data. 64 bytes from rhel7-server2 (192.168.0.58): icmp_seq=1 ttl=64 time=0.802 ms 64 bytes from rhel7-server2 (192.168.0.58): icmp_seq=2 ttl=64 time=0.965 ms 64 bytes from rhel7-server2 (192.168.0.58): icmp_seq=3 ttl=64 time=0.733 ms 64 bytes from rhel7-server2 (192.168.0.58): icmp_seq=4 ttl=64 time=0.829 ms --- rhel7-server2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 0.733/0.832/0.965/0.086 ms PING rhel8-server2 (192.168.0.56) 56(84) bytes of data. 64 bytes from rhel8-server2 (192.168.0.56): icmp_seq=1 ttl=64 time=0.918 ms 64 bytes from rhel8-server2 (192.168.0.56): icmp_seq=2 ttl=64 time=0.735 ms 64 bytes from rhel8-server2 (192.168.0.56): icmp_seq=3 ttl=64 time=0.749 ms 64 bytes from rhel8-server2 (192.168.0.56): icmp_seq=4 ttl=64 time=0.789 ms --- rhel8-server2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3006ms rtt min/avg/max/mdev = 0.735/0.797/0.918/0.080 ms
If I run sudo ipsec trafficstatus again, I can now see each of the VPN tunnels shows 336 inBytes and outBytes:
[ansible@rhel8-server1 ~]$ sudo ipsec trafficstatus 006 #5: "rhel8-server1-to-rhel7-server1", type=ESP, add_time=1636554445, inBytes=336, outBytes=336, id='@rhel7-server1' 006 #6: "rhel8-server1-to-rhel7-server2", type=ESP, add_time=1636554445, inBytes=336, outBytes=336, id='@rhel7-server2' 006 #4: "rhel8-server1-to-rhel8-server2", type=ESP, add_time=1636554445, inBytes=336, outBytes=336, id='@rhel8-server2'
Conclusion
The vpn RHEL System Role can help you quickly and easily implement VPN connections across your RHEL environment in an automated manner. While this blog post focused on host-to-host VPN tunnels, the vpn RHEL System Role also supports opportunistic mesh VPNs.
We offer many RHEL System Roles that can help automate other important aspects of your RHEL environment. To explore additional roles, review the list of available RHEL System Roles and start managing your RHEL servers in a more efficient, consistent and automated manner today.
Want to learn more about Red Hat Ansible Automation Platform? Check out our e-book, "The automated enterprise: Unify people and processes."
À propos de l'auteur
Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management. He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit