One place for hosting & domains

      How to Set Up an IKEv2 VPN Server with StrongSwan on Ubuntu 20.04


      Not using Ubuntu 20.04?


      Choose a different version or distribution.

      A previous version of this tutorial was written by Justin Ellingwood and Namo

      Introduction

      A virtual private network, or VPN, allows you to securely encrypt traffic as it travels through untrusted networks, such as those at the coffee shop, a conference, or an airport.

      Internet Key Exchange v2, or IKEv2, is a protocol that allows for direct IPSec tunneling between the server and client. In IKEv2 VPN implementations, IPSec provides encryption for the network traffic. IKEv2 is natively supported on some platforms (OS X 10.11+, iOS 9.1+, and Windows 10) with no additional applications necessary, and it handles client hiccups quite smoothly.

      In this tutorial, you’ll set up an IKEv2 VPN server using StrongSwan on an Ubuntu 20.04 server. You’ll then learn how to connect to it with Windows, macOS, Ubuntu, iOS, and Android clients.

      Prerequisites

      To complete this tutorial, you will need:

      Step 1 — Installing StrongSwan

      First, we’ll install StrongSwan, an open-source IPSec daemon which we’ll configure as our VPN server. We’ll also install the public key infrastructure (PKI) component so that we can create a Certificate Authority (CA) to provide credentials for our infrastructure.

      Start by updating the local package cache:

      Then install the software by typing:

      • sudo apt install strongswan strongswan-pki libcharon-extra-plugins

      The additional libcharon-extra-plugins package is used to ensure that various clients can authenticate to your server using a shared username and passphrase.

      Now that everything’s installed, let’s move on to creating our certificates.

      Step 2 — Creating a Certificate Authority

      An IKEv2 server requires a certificate to identify itself to clients. To help create the required certificate, the strongswan-pki package comes with a utility called pki to generate a Certificate Authority and server certificates.

      To begin, let’s create a few directories to store all the assets we’ll be working on. The directory structure matches some of the directories in /etc/ipsec.d, where we will eventually move all of the items we create:

      • mkdir -p ~/pki/{cacerts,certs,private}

      Then lock down the permissions so that our private files can’t be seen by other users:

      Now that we have a directory structure to store everything, we can generate a root key. This will be a 4096-bit RSA key that will be used to sign our root certificate authority.

      Execute these commands to generate the key:

      • pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/ca-key.pem

      Following that we can move on to creating our root certificate authority, using the key that we just generated to sign the root certificate:

      • pki --self --ca --lifetime 3650 --in ~/pki/private/ca-key.pem
      • --type rsa --dn "CN=VPN root CA" --outform pem > ~/pki/cacerts/ca-cert.pem

      The --lifetime 3650 flag is used to ensure that the certificate authority’s root certificate will be valid for 10 years. The root certificate for an authority does not change typically, since it would have to be redistributed to every server and client that rely on it, so 10 years is a safe default expiry value.

      You can change the distinguished name (DN) value to something else if you would like. The common name (CN field) here is just the indicator, so it doesn’t have to match anything in your infrastructure.

      Now that we’ve got our root certificate authority up and running, we can create a certificate that the VPN server will use.

      Step 3 — Generating a Certificate for the VPN Server

      We’ll now create a certificate and key for the VPN server. This certificate will allow the client to verify the server’s authenticity using the CA certificate we just generated.

      First, create a private key for the VPN server with the following command:

      • pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/server-key.pem

      Now, create and sign the VPN server certificate with the certificate authority’s key you created in the previous step. Execute the following command, but change the Common Name (CN) and the Subject Alternate Name (SAN) field to your VPN server’s DNS name or IP address:

      • pki --pub --in ~/pki/private/server-key.pem --type rsa
      • | pki --issue --lifetime 1825
      • --cacert ~/pki/cacerts/ca-cert.pem
      • --cakey ~/pki/private/ca-key.pem
      • --dn "CN=server_domain_or_IP" --san server_domain_or_IP
      • --flag serverAuth --flag ikeIntermediate --outform pem
      • > ~/pki/certs/server-cert.pem

      Note: If you are using an IP address instead of a DNS name, you will need to specify multiple --san entries. The line in the previous command block where you specify the distinguished name (--dn ...) will need to be modified with the extra entry like the following excerpted line:

      --dn "CN=IP address --san @IP_address --san IP_address 
      

      The reason for this extra --san @IP_address entry is that some clients will check whether the TLS certificate has both an DNS entry and an IP Address entry for a server when they verify its identity.

      The --flag serverAuth option is used to indicate that the certificate will be used explicitly for server authentication, before the encrypted tunnel is established. The --flag ikeIntermediate option is used to support older macOS clients.

      Now that we’ve generated all of the TLS/SSL files StrongSwan needs, we can move the files into place in the /etc/ipsec.d directory by typing:

      • sudo cp -r ~/pki/* /etc/ipsec.d/

      In this step, we’ve created a certificate pair that will be used to secure communications between the client and the server. We’ve also signed the certificates with the CA key, so the client will be able to verify the authenticity of the VPN server using the CA certificate. With all of these certificates ready, we’ll move on to configuring the software.

      Step 4 — Configuring StrongSwan

      StrongSwan has a default configuration file with some examples, but we will have to do most of the configuration ourselves. Let’s back up the file for reference before starting from scratch:

      • sudo mv /etc/ipsec.conf{,.original}

      Create and open a new blank configuration file using your preferred text editor. Here, we’ll use nano:

      • sudo nano /etc/ipsec.conf

      Note: As you work through this section to configure the server portion of your VPN, you will encounter settings that refer to left and right sides of a connection. When working with IPSec VPNs, the left side by convention refers to the local system that you are configuring, in this case the server. The right side directives in these settings will refer to remote clients, like phones and other computers.

      When you move on to configuring clients later in this tutorial, the client configuration files will refer to themselves using various left directives, and the server will be referred to using right side terminology.

      First, we’ll tell StrongSwan to log daemon statuses for debugging and allow duplicate connections. Add these lines to the file:

      /etc/ipsec.conf

      config setup
          charondebug="ike 1, knl 1, cfg 0"
          uniqueids=no
      

      Then, we’ll create a configuration section for our VPN. We’ll also tell StrongSwan to create IKEv2 VPN Tunnels and to automatically load this configuration section when it starts up. Append the following lines to the file:

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          auto=add
          compress=no
          type=tunnel
          keyexchange=ikev2
          fragmentation=yes
          forceencaps=yes
      

      We’ll also configure dead-peer detection to clear any “dangling” connections in case the client unexpectedly disconnects. Add these lines:

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          dpdaction=clear
          dpddelay=300s
          rekey=no
      

      Next, we’ll configure the server’s “left” side IPSec parameters. Each of the following parameters ensures that the server is configured to accept connections from clients and to identify itself correctly. You’ll add each of these settings to the /etc/ipsec.conf file once you are familiar with what they are and why they are used:

      • left=%any The %any value ensures that the server will use the network interface where it receives incoming connections for subsequent communication with clients. For example, if you are connecting a client over a private network, the server will use the private IP address where it receives traffic for the rest of the connection.
      • leftid=@server_domain_or_IP This option controls the name that the server presents to clients. When combined with the next option leftcert, the leftid option ensures that the server’s configured name and the Distinguished Name (DN) that is contained in the public certificate match.
      • leftcert=server-cert.pem This option is the path to the public certificate for the server that you configured in Step 3. Without it, the server will not be able to authenticate itself with clients, or finish negotiating the IKEv2 set up.
      • leftsendcert=always The always value ensures that any client that connects to the server will always receive a copy of the server’s public certificate as part of the initial connection set up.
      • leftsubnet=0.0.0.0/0 The last “left” side option that you will add tells clients about the subnets that are reachable behind the server. In this case, 0.0.0.0/0 is used to represent the entire set of IPv4 addresses, meaning that the server will tell clients to send all their traffic over the VPN by default.

      Now that you are familiar with each of the relevant “left” side options, add them all to the file like this:

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          left=%any
          leftid=@server_domain_or_IP
          leftcert=server-cert.pem
          leftsendcert=always
          leftsubnet=0.0.0.0/0
      

      Note: When configuring the server ID (leftid), only include the @ character if your VPN server will be identified by a domain name:

      /etc/ipsec.conf

          . . .    leftid=@vpn.example.com
          . . .
      

      If the server will be identified by its IP address, just put the IP address in:

      /etc/ipsec.conf

          . . .
          leftid=your_server_ip
          . . .
      

      Next, we can configure the client’s “right” side IPSec parameters. Each of the following parameters tells the server how to accept connections from clients, how clients should authenticate to the server, and the private IP address ranges and DNS servers that clients will use. Add each of these settings to the /etc/ipsec.conf file once you are familiar with what they are and why they are used:

      • right=%any The %any option for the right side of the connection instructs the server to accept incoming connections from any remote client.
      • rightid=%any This option ensures that the server will not reject connections from clients that provide an identity before the encrypted tunnel is established.
      • rightauth=eap-mschapv2 This option configures the authentication method that clients will use to authenticate to the server. eap-mschapv2 is used here for broad compatibility to support clients like Windows, macOS, and Android devices.
      • rightsourceip=10.10.10.0/24 This option instructs the server to assign private IP addresses to clients from the specified 10.10.10.0/24 pool of IPs.
      • rightdns=8.8.8.8,8.8.4.4 These IP addresses are Google’s public DNS resolvers. They can be changed to use other public resolvers, the VPN server’s resolvers, or any other resolver that clients can reach.
      • rightsendcert=never This option instructs the server that clients do not need to send a certificate to authenticate themselves.

      Now that you are familiar with the required “right” side options for the VPN, add the following lines to /etc/ipsec.conf:

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          right=%any
          rightid=%any
          rightauth=eap-mschapv2
          rightsourceip=10.10.10.0/24
          rightdns=8.8.8.8,8.8.4.4
          rightsendcert=never
      

      Now we’ll tell StrongSwan to ask the client for user credentials when they connect:

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          eap_identity=%identity
      

      Finally, add the following lines to support Linux, Windows, macOS, iOS, and Android clients. These lines specify the various key exchange, hashing, authentication, and encryption algorithms (commonly referred to as Cipher Suites) that StrongSwan will allow different clients to use:

      /etc/ipsec.conf

      . . .
      conn ikev2-vpn
          . . .
          ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
          esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
      

      Each supported cipher suite is delineated from the others by a comma. For example chacha20poly1305-sha512-curve25519-prfsha512 is one suite, and aes256gcm16-sha384-prfsha384-ecp384 is another. The cipher suites that are listed here are selected to ensure the widest range of compatibility across Windows, macOS, iOS, Android, and Linux clients.

      The complete configuration file should look like this:

      /etc/ipsec.conf

      config setup
          charondebug="ike 1, knl 1, cfg 0"
          uniqueids=no
      
      conn ikev2-vpn
          auto=add
          compress=no
          type=tunnel
          keyexchange=ikev2
          fragmentation=yes
          forceencaps=yes
          dpdaction=clear
          dpddelay=300s
          rekey=no
          left=%any
          leftid=@server_domain_or_IP
          leftcert=server-cert.pem
          leftsendcert=always
          leftsubnet=0.0.0.0/0
          right=%any
          rightid=%any
          rightauth=eap-mschapv2
          rightsourceip=10.10.10.0/24
          rightdns=8.8.8.8,8.8.4.4
          rightsendcert=never
          eap_identity=%identity
          ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
          esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
      

      Save and close the file once you’ve verified that you’ve added each line correctly. If you used nano, do so by pressing CTRL + X, Y, then ENTER.

      Now that we’ve configured the VPN parameters, let’s move on to creating an account so our users can connect to the server.

      Step 5 — Configuring VPN Authentication

      Our VPN server is now configured to accept client connections, but we don’t have any credentials configured yet. We’ll need to configure a couple things in a special configuration file called ipsec.secrets:

      • We need to tell StrongSwan where to find the private key for our server certificate, so the server will be able to authenticate to clients.
      • We also need to set up a list of users that will be allowed to connect to the VPN.

      Let’s open the secrets file for editing:

      • sudo nano /etc/ipsec.secrets

      First, we’ll tell StrongSwan where to find our private key:

      /etc/ipsec.secrets

      : RSA "server-key.pem"
      

      Then, we’ll define the user credentials. You can make up any username or password combination that you like:

      /etc/ipsec.secrets

      your_username : EAP "your_password"
      

      Save and close the file. Now that we’ve finished working with the VPN parameters, we’ll restart the VPN service so that our configuration is applied:

      • sudo systemctl restart strongswan-starter

      Now that the VPN server has been fully configured with both server options and user credentials, it’s time to move on to configuring the most important part: the firewall.

      Step 6 — Configuring the Firewall & Kernel IP Forwarding

      With the StrongSwan configuration complete, we need to configure the firewall to allow VPN traffic through and forward it.

      If you followed the prerequisite initial server setup tutorial, you should have a UFW firewall enabled. If you don’t yet have UFW configured, you should start by adding a rule to allow SSH connections through the firewall so your current session doesn’t close when you enable UFW:

      Then enable the firewall by typing:

      Then, add a rule to allow UDP traffic to the standard IPSec ports, 500 and 4500:

      • sudo ufw allow 500,4500/udp

      Next, we will open up one of UFW’s configuration files to add a few low-level policies for routing and forwarding IPSec packets. Before we we can do this, though, we need to find which network interface on our server is used for internet access. Find this interface by querying for the device associated with the default route:

      Your public interface should follow the word “dev”. For example, this result shows the interface named eth0, which is highlighted in the following example:

      Output

      default via your_server_ip dev eth0 proto static

      When you have your public network interface, open the /etc/ufw/before.rules file in your text editor. The rules in this file are added to the firewall before the rest of the usual input and output rules. They are used to configure network address translation (NAT) so that the server can correctly route connections to and from clients and the Internet.

      • sudo nano /etc/ufw/before.rules

      Near the top of the file (before the *filter line), add the following configuration block. Change each instance of eth0 in the above configuration to match the interface name you found with ip route. The *nat lines create rules so that the firewall can correctly route and manipulate traffic between the VPN clients and the internet. The *mangle line adjusts the maximum packet segment size to prevent potential issues with certain VPN clients:

      /etc/ufw/before.rules

      *nat
      -A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT
      -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
      COMMIT
      
      *mangle
      -A FORWARD --match policy --pol ipsec --dir in -s 10.10.10.0/24 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
      COMMIT
      
      *filter
      :ufw-before-input - [0:0]
      :ufw-before-output - [0:0]
      :ufw-before-forward - [0:0]
      :ufw-not-local - [0:0]
      . . .
      

      Next, after the *filter and chain definition lines, add one more block of configuration:

      /etc/ufw/before.rules

      . . .
      *filter
      :ufw-before-input - [0:0]
      :ufw-before-output - [0:0]
      :ufw-before-forward - [0:0]
      :ufw-not-local - [0:0]
      
      -A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 10.10.10.0/24 -j ACCEPT
      -A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 10.10.10.0/24 -j ACCEPT
      

      These lines tell the firewall to forward ESP (Encapsulating Security Payload) traffic so the VPN clients will be able to connect. ESP provides additional security for our VPN packets as they’re traversing untrusted networks.

      When you’re finished, ave and close the file once you’ve verified that you’ve added each line correctly. If you used nano, do so by pressing CTRL + X, Y, then ENTER.

      Before restarting the firewall, we’ll change some network kernel parameters to allow routing from one interface to another. The file that controls these settings is called /etc/ufw/sysctl.conf. We’ll need to configure a few things in the file including.

      First IPv4 packet forwarding needs to be turned on so that traffic can move between the VPN and public facing network interfaces on the server. Next we’ll disable Path MTU discovery to prevent packet fragmentation problems. Finally we will not accept ICMP redirects nor send ICMP redirects to prevent man-in-the-middle attacks.

      Open UFW’s kernel parameters configuration file using nano or your preferred text editor:

      • sudo nano /etc/ufw/sysctl.conf

      Now add the following net/ipv4/ip_forward=1 setting at the end of the file to enable forwarding packets between interfaces:

      /etc/ufw/sysctl.conf

      . . .
      net/ipv4/ip_forward=1
      

      Next block sending and receiving ICMP redirect packets by adding the following lines to the end of the file:

      /etc/ufw/sysctl.conf

      . . .
      net/ipv4/conf/all/accept_redirects=0
      net/ipv4/conf/all/send_redirects=0
      

      Finally, turn off Path MTU discovery by adding this line to the end of the file:

      /etc/ufw/sysctl.conf

      . . .
      net/ipv4/ip_no_pmtu_disc=1
      

      Save the file when you are finished. Now we can enable all of our changes by disabling and re-enabling the firewall, since UFW applies these settings any time that it restarts:

      • sudo ufw disable
      • sudo ufw enable

      You’ll be prompted to confirm the process. Type Y to enable UFW again with the new settings.

      Step 7 — Testing the VPN Connection on Windows, macOS, Ubuntu, iOS, and Android

      Now that you have everything set up, it’s time to try it out. First, you’ll need to copy the CA certificate you created and install it on your client device(s) that will connect to the VPN. The easiest way to do this is to log into your server and output the contents of the certificate file:

      • cat /etc/ipsec.d/cacerts/ca-cert.pem

      You’ll see output similar to this:

      Output

      -----BEGIN CERTIFICATE----- MIIFNDCCAxygAwIBAgIIHCsidG5mXzgwDQYJKoZIhvcNAQEMBQAwODELMAkGA1UE . . . H2YUdz8XNHrJHvMQKWFpi0rlEcMs+MSXPFWE3Q7UbaZJ/h8wpSldSUbQRUlphExJ dJ4PX+MUJO/vjG1/ie6Kh25xbBAc3qNq8siiJZDwrg6vjEK7eiZ1rA== -----END CERTIFICATE-----

      Copy this output to your computer, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines, and save it to a file with a recognizable name, such as ca-cert.pem. Ensure the file you create has the .pem extension.

      Alternatively, use SFTP to transfer the file to your computer.

      Once you have the ca-cert.pem file downloaded to your computer, you can set up the connection to the VPN.

      Connecting from Windows

      There are multiple ways to import the root certificate and configure Windows to connect to a VPN. The first method uses graphical tools for each step. The second method uses PowerShell commands, which can be scripted and modified to suit your VPN configuration.

      Note: These instructions have been tested on Windows 10 installations running versions 1903 and 1909.

      Configuring Windows with Graphical Tools

      First, import the root certificate by following these steps:

      1. Press WINDOWS+R to bring up the Run dialog, and enter mmc.exe to launch the Windows Management Console.
      2. From the File menu, navigate to Add or Remove Snap-in, select Certificates from the list of available snap-ins, and click Add.
      3. We want the VPN to work with any user, so select Computer Account and click Next.
      4. We’re configuring things on the local computer, so select Local Computer, then click Finish.
      5. Under the Console Root node, expand the Certificates (Local Computer) entry, expand Trusted Root Certification Authorities, and then select the Certificates entry:
        Certificates view

      6. From the Action menu, select All Tasks and click Import to display the Certificate Import Wizard. Click Next to move past the introduction.

      7. On the File to Import screen, press the Browse button, ensure that you change the file type from “X.509 Certificate (.cer;.crt)” to “All Files (.)”, and select the ca-cert.pem file that you’ve saved. Then click Next.

      8. Ensure that the Certificate Store is set to Trusted Root Certification Authorities, and click Next.

      9. Click Finish to import the certificate.

      Then configure the VPN with these steps:

      1. Launch Control Panel, then navigate to the Network and Sharing Center.
      2. Click on Set up a new connection or network, then select Connect to a workplace.
      3. Select Use my Internet connection (VPN).
      4. Enter the VPN server details. Enter the server’s domain name or IP address in the Internet address field, then fill in Destination name with something that describes your VPN connection. Then click Done.

      Configuring Windows using PowerShell

      To import the root CA certificate using PowerShell, first open a PowerShell prompt with administrator privileges. To do so, right click the Start menu icon and select Windows PowerShell (Admin). You can also open a command prompt as administrator and type powershell.

      Next we’ll import the certificate using the Import-Certificate PowerShell cmdlet. In the following command, the first -CertStoreLocation argument will ensure that the certificate is imported into the computer’s Trusted Root Certification Authorities store so that all programs and users will be able to verify the VPN server’s certificate. The -FilePath argument should point to the location where you copied the certificate. In the following example the path is C:UserssammyDocumentsca-cert.pem. Ensure that you edit the command to match the location that you used.

      • Import-Certificate `
      • -CertStoreLocation cert:LocalMachineRoot `
      • -FilePath C:userssammyDocumentsca-cert.pem

      The command will output something like the following:

      Output

      PSParentPath: Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot Thumbprint Subject ---------- ------- DB00813B4087E9367861E8463A60CEA0ADC5F002 CN=VPN root CA

      Now to configure the VPN using PowerShell, run the following command. Substitute your server’s DNS name or IP address on the -ServerAddress line. The various flags will ensure that Windows is correctly configured with the appropriate security parameters that match the options that you set in /etc/ipsec.conf.

      • Add-VpnConnection -Name "VPN Connection" `
      • -ServerAddress "server_domain_or_IP" `
      • -TunnelType "IKEv2" `
      • -AuthenticationMethod "EAP" `
      • -EncryptionLevel "Maximum" `
      • -RememberCredential `

      If the command is successful there will not be any output. To confirm the VPN is configured correctly, use the Get-VPNConnection cmdlet:

      • Get-VpnConnection -Name "VPN Connection"

      You will receive output like the following:

      Output

      Name : VPN Connection ServerAddress : your_server_ip AllUserConnection : False Guid : {B055A1AB-175C-4028-B4A8-D34309A2B20E} TunnelType : Ikev2 AuthenticationMethod : {Eap} EncryptionLevel : Maximum L2tpIPsecAuth : UseWinlogonCredential : False EapConfigXmlStream : #document ConnectionStatus : Disconnected RememberCredential : True SplitTunneling : False DnsSuffix : IdleDisconnectSeconds : 0

      By default Windows chooses older and slower algorithms. Run the Set-VpnConnectionIPsecConfiguration cmdlet to upgrade the encryption parameters that Windows will use for the IKEv2 key exchange, and to encrypt packets:

      • Set-VpnConnectionIPsecConfiguration -Name "VPN Connection" `
      • -AuthenticationTransformConstants GCMAES256 `
      • -CipherTransformConstants GCMAES256 `
      • -DHGroup ECP384 `
      • -IntegrityCheckMethod SHA384 `
      • -PfsGroup ECP384 `
      • -EncryptionMethod GCMAES256

      Note: If you would like to delete the VPN connection and reconfigure it with different options, you can run the Remove-VpnConnection cmdlet.

      • Remove-VpnConnection -Name "VPN Connection" -Force

      The -Force flag will skip prompting you to confirm the removal. You must be disconnected from the VPN if you attempt to remove it using this command.

      Connecting to the VPN

      Once you have the certificate imported and the VPN configured using either method, your new VPN connection will be visible under the list of networks. Select the VPN and click Connect. You’ll be prompted for your username and password. Type them in, click OK, and you’ll be connected.

      Connecting from macOS

      Follow these steps to import the certificate:

      1. Double-click the certificate file. Keychain Access will pop up with a dialog that says “Keychain Access is trying to modify the system keychain. Enter your password to allow this.”
      2. Enter your password, then click on Modify Keychain
      3. Double-click the newly imported VPN certificate. This brings up a small properties window where you can specify the trust levels. Set IP Security (IPSec) to Always Trust and you’ll be prompted for your password again. This setting saves automatically after entering the password.

      Now that the certificate is imported and trusted, configure the VPN connection with these steps:

      1. Go to System Preferences and choose Network.
      2. Click on the small “plus” button on the lower-left of the list of networks.
      3. In the popup that appears, set Interface to VPN, set the VPN Type to IKEv2, and give the connection a name.
      4. In the Server and Remote ID field, enter the server’s domain name or IP address. Leave the Local ID blank.
      5. Click on Authentication Settings, select Username, and enter your username and password you configured for your VPN user. Then click OK.

      Finally, click on Connect to connect to the VPN. You should now be connected to the VPN.

      Connecting from Ubuntu

      To connect from an Ubuntu machine, you can set up and manage StrongSwan as a service or use a one-off command every time you wish to connect. Instructions are provided for both.

      Managing StrongSwan as a Service

      To manage StrongSwan as a service, you will need to perform the following configuration steps.

      First, update your local package cache using apt

      Next, install StrongSwan and the required plugins for authentication:

      • sudo apt install strongswan libcharon-extra-plugins

      Now you’ll need a copy of the CA certificate in the /etc/ipsec.d/cacerts directory so that your client can verify the server’s identity. Run the following command to copy the ca-cert.pem file into place:

      • sudo cp /tmp/ca-cert.pem /etc/ipsec.d/cacerts

      To ensure the VPN only runs on demand, use systemctl to disable StrongSwan from running automatically:

      • sudo systemctl disable --now strongswan-starter

      Next configure the username and password that you will use to authenticate to the VPN server. Edit /etc/ipsec.secrets using nano or your preferred editor:

      • sudo nano /etc/ipsec.conf

      Add the following line, editing the highlighted username and password values to match the ones that you configured on the server:

      /etc/ipsec.conf

      your_username : EAP "your_password"
      

      Finally, edit the /etc/ipsec.conf file to configure your client to match the server’s configuration:

      /etc/ipsec.conf

      config setup
      
      conn ikev2-rw
          right=server_domain_or_IP
          # This should match the `leftid` value on your server's configuration
          rightid=server_domain_or_IP
          rightsubnet=0.0.0.0/0
          rightauth=pubkey
          leftsourceip=%config
          leftid=username
          leftauth=eap-mschapv2
          eap_identity=%identity
          auto=start
      

      To connect to the VPN, type:

      • sudo systemctl start strongswan-starter

      To disconnect again, type:

      • sudo systemctl stop strongswan-starter

      Using the charon-cmd Client for One-Off Connections

      To manage StrongSwan as a service, you will need to perform the following configuration steps.

      First, update your local package cache using apt

      Next, install StrongSwan and the required plugins for authentication:

      • sudo apt install strongswan libcharon-extra-plugins

      Now you’ll need a copy of the CA certificate in the /etc/ipsec.d/cacerts directory so that your client can verify the server’s identity. Run the following command to copy the ca-cert.pem file into place:

      • sudo cp /tmp/ca-cert.pem /etc/ipsec.d/cacerts

      At this point you can connect to the VPN server with charon-cmd using the server’s CA certificate, the VPN server’s IP address, and the username you configured.

      Run the following command whenever you want to connect to the VPN:

      • sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username

      When prompted, provide the VPN user’s password and you will be connected to the VPN. To disconnect, press CTRL+C in the terminal and wait for the connection to close.

      Connecting from iOS

      To configure the VPN connection on an iOS device, follow these steps:

      1. Send yourself an email with the root certificate attached.
      2. Open the email on your iOS device and tap on the attached certificate file, then tap Install and enter your passcode. Once it installs, tap Done.
      3. Go to Settings, General, VPN and tap Add VPN Configuration. This will bring up the VPN connection configuration screen.
      4. Tap on Type and select IKEv2.
      5. In the Description field, enter a short name for the VPN connection. This could be anything you like.
      6. In the Server and Remote ID field, enter the server’s domain name or IP address. The Local ID field can be left blank.
      7. Enter your username and password in the Authentication section, then tap Done.
      8. Select the VPN connection that you just created, tap the switch on the top of the page, and you’ll be connected.

      Connecting from Android

      Follow these steps to import the certificate:

      1. Send yourself an email with the CA certificate attached. Save the CA certificate to your downloads folder.
      2. Download the StrongSwan VPN client from the Play Store.
      3. Open the app. Tap the “more” icon () in the upper-right corner and select CA certificates.
      4. Tap the “more” icon () in the upper-right corner again. Select Import certificate.
      5. Browse to the CA certificate file in your downloads folder and select it to import it into the app.

      Now that the certificate is imported into the StrongSwan app, you can configure the VPN connection with these steps:

      1. In the app, tap ADD VPN PROFILE at the top.
      2. Fill out the Server with your VPN server’s domain name or public IP address.
      3. Make sure IKEv2 EAP (Username/Password) is selected as the VPN Type.
      4. Fill out the Username and Password with the credentials you defined on the server.
      5. Deselect Select automatically in the CA certificate section and click Select CA certificate.
      6. Tap the IMPORTED tab at the top of the screen and choose the CA you imported (it will be named “VPN root CA” if you didn’t change the “DN” earlier).
      7. If you’d like, fill out Profile name (optional) with a more descriptive name.

      When you wish to connect to the VPN, click on the profile you just created in the StrongSwan application.

      Troubleshooting Connections

      If you are unable to import the certificate, ensure the file has the .pem extension, and not .pem.txt.

      If you’re unable to connect to the VPN, check the server name or IP address you used. The server’s domain name or IP address must match what you’ve configured as the common name (CN) while creating the certificate. If they don’t match, the VPN connection won’t work. For example, if you set up a certificate with the CN of vpn.example.com, you must use vpn.example.com when you enter the VPN server details. Double-check the command you used to generate the certificate, and the values you used when creating your VPN connection.

      Finally, double-check the VPN configuration to ensure the leftid value is configured with the @ symbol if you’re using a domain name:

      /etc/ipsec.conf

          leftid=@vpn.example.com
      

      If you’re using an IP address, ensure that the @ symbol is omitted. Also make sure that when you generated the server-cert.pem file that you included both --san @IP_address and --san IP_address flags.

      Conclusion

      In this tutorial, you’ve built a VPN server that uses the IKEv2 protocol. You learned about the directives that control the left and right sides of a connection on both server and clients. You also configured a Windows, macOS, iOS, Android, or Linux client to connect to the VPN.

      To add or remove users, skip to Step 5 again. Each line in /etc/ipsec.secrets is for one user, so adding or removing users, or changing passwords just requires editing the file.

      Now you can be assured that your online activities will remain secure wherever you go and with any device that you use to access the internet.



      Source link

      So installieren Sie Tinc und richten ein einfaches VPN unter Ubuntu 18.04 ein


      Einführung

      Tinc ist ein Open-Source Virtual Private Network (VPN)-Daemon mit nützlichen Funktionen wie Verschlüsselung, optionaler Komprimierung und automatischem Mesh-Routing, der VPN-Verkehr opportunistisch direkt zwischen Servern routen kann. Diese Funktionen unterscheiden tinc von anderen VPN-Lösungen und machen es zu einer guten Wahl für die Erstellung eines VPN aus vielen kleinen, geografisch verteilten Netzwerken.

      In diesem Tutorial gehen wir darauf ein, wie Sie mit tinc ein sicheres VPN erstellen, in dem Ihre Server kommunizieren können, als ob sie sich in einem lokalen Netzwerk befinden würden. Wir werden auch demonstrieren, wie man mit tinc einen sicheren Tunnel in einem privaten Netzwerk einrichtet. Wir verwenden Ubuntu-18.04-Server, aber die Konfigurationen können für die Verwendung mit jedem anderen Betriebssystem angepasst werden.

      Ziele

      Um mehrere Anwendungsfälle abzudecken, beschreibt dieses Tutorial die Verbindung eines Client-Knotens mit dem VPN über eine private Netzwerkschnittstelle und eines anderen über eine öffentliche. Sie können diese Einrichtung jedoch an Ihre eigenen Bedürfnisse anpassen. Sie müssen nur planen, wie Ihre Server aufeinander zugreifen sollen, und die in diesem Tutorial vorgestellten Beispiele an Ihre eigenen Bedürfnisse anpassen. Achten Sie darauf, die in den Beispielen hervorgehobenen Werte durch Ihre eigenen Werte zu ersetzen, wenn Sie eine Anpassung an Ihre eigene Einrichtung vornehmen. Es könnte jedoch in Ihrem Interesse sein, zunächst dem Tutorial in der vorliegenden Form zu folgen, um sicherzustellen, dass Sie die beteiligten Komponenten und Prozesse verstehen, bevor Sie diese Anleitung modifizieren.

      Um die Übersichtlichkeit zu wahren, wird in diesem Tutorial wie folgt auf die Server verwiesen:

      • server-01: Alle VPN-Knoten stellen eine Verbindung mit diesem Rechner her und die Verbindung muss für die einwandfreie VPN-Funktionalität aufrechterhalten werden. Weitere Server können auf die gleiche Weise wie dieser konfiguriert werden, um, falls gewünscht, Redundanz bereitzustellen.
      • client-01: Verbindet sich mit dem VPN-Knoten von server-01 über dessen private Netzwerkschnittstelle
      • client-02: Verbindet sich mit dem VPN-Knoten von server-01 über dessen öffentliche Netzwerkschnittstelle

      Anmerkung: Tinc selbst unterscheidet nicht zwischen Servern (Rechnern, die VPN-Dienste hosten und bereitstellen) und Clients (Rechnern, die sich mit dem sicheren privaten Netzwerk verbinden und es verwenden). Es kann jedoch hilfreich sein, die Funktionsweise von tinc zu verstehen und zu visualisieren, indem Sie sich Ihre Server so vorstellen.

      Hier ist eine Darstellung des VPN, das wir einrichten möchten:

      Tinc VPN-Einrichtung

      Das blaue Feld steht für unser VPN und das rosa Feld für das zugrunde liegende private Netzwerk. Alle drei Server können über das VPN kommunizieren, obwohl das private Netzwerk ansonsten für client-02 nicht zugänglich ist.

      Voraussetzungen

      Wenn Sie diesem Tutorial genau folgen möchten, stellen Sie zwei Ubuntu-18.04-Server (server-01 und client-01) in demselben Datencenter bereit und aktivieren Sie auf jedem das private Netzwerk. Erstellen Sie dann einen weiteren Ubuntu-18.04-Server (client-02) in einem separaten Datencenter. Jeder Server sollte über einen administrativen Benutzer und eine mit ufw konfigurierte Firewall verfügen. Um dies einzurichten, folgen Sie unserem Leitfaden für die Ersteinrichtung des Servers für Ubuntu 18.04.

      Zusätzlich müssen wir später in diesem Tutorial einige Dateien zwischen den einzelnen Rechnern mit scp übertragen. Aus diesem Grund müssen Sie auf jedem Ihrer Server SSH-Schlüssel generieren, die SSH-Schlüssel von client-01 und client-02 zu der Datei authorized_keys von server-01 und dann den SSH-Schlüssel von server-01 zu den Dateien authorized_keys von client-01 und client-02 hinzufügen. Hilfe für das Einrichten finden Sie in unserem Leitfaden So richten Sie SSH-Schlüssel unter Ubuntu 18.04 ein.

      Schritt 1 – Installieren von Tinc

      Tinc ist aus den Standard-APT-Repositorys von Ubuntu verfügbar, d. h., wir können es mit nur wenigen Befehlen installieren.

      Sofern Sie dies nicht kürzlich getan haben, führen Sie auf jedem Server den folgenden Befehl aus, um die jeweiligen Paketindizes zu aktualisieren:

      All servers

      Installieren Sie dann tinc auf jedem Server, indem Sie den folgenden Befehl ausführen:

      All servers

      Damit haben Sie tinc auf jedem Ihrer Server installiert. Sie müssen jedoch einige Änderungen an der Konfiguration von tinc auf jedem Rechner vornehmen, damit Ihr VPN ausgeführt werden kann. Beginnen wir mit der Aktualisierung von server-01.

      Schritt 2 – Konfigurieren des Tinc-Servers

      Tinc erfordert, dass jeder Rechner, der Teil des VPN sein wird, die folgenden drei Konfigurationskomponenten aufweist:

      • Tinc-Konfigurationsdateien: Es gibt drei verschiedene Dateien, die den tinc-Daemon konfigurieren:
        • tinc.conf, die den Netznamen, das Netzwerkgerät, über das VPN ausgeführt wird, und andere VPN-Optionen definiert;
        • tinc-up, ein Skript, das das in tinc.conf definierte Netzwerkgerät nach dem Start von tinc aktiviert;
        • tinc-down, die das Netzwerkgerät deaktiviert, wenn tinc stoppt.
      • Öffentliche/private Schlüsselpaare: Tinc verwendet öffentliche/private Schlüsselpaare, damit nur Benutzer mit gültigen Schlüsseln auf das VPN zugreifen können.
      • Host-Konfigurationsdateien: Jeder Rechner (oder Host) im VPN hat seine eigene Konfigurationsdatei, die die tatsächliche IP-Adresse des Hosts und das Subnetz, in dem tinc ihn bedient, enthält.

      Tinc verwendet einen Netznamen, um ein tinc-VPN von einem anderen zu unterscheiden. Dies ist hilfreich, wenn Sie mehrere VPNs einrichten möchten. Es wird jedoch empfohlen, einen Netznamen selbst dann zu verwenden, wenn Sie nur ein VPN konfigurieren wollen. Sie können Ihrem VPN einen beliebigen Netznamen geben, aber der Einfachheit halber nennen wir unser VPN netname.

      Erstellen Sie auf server-01 die Konfigurationsverzeichnisstruktur für das VPN:

      server-01

      • sudo mkdir -p /etc/tinc/netname/hosts

      Verwenden Sie Ihren bevorzugten Texteditor, um eine Datei tinc.conf zu erstellen. Wir verwenden hier nano:

      server-01

      • sudo nano /etc/tinc/netname/tinc.conf

      Fügen Sie der leeren Datei die folgenden Zeilen hinzu. Diese konfigurieren einen tinc-Knoten namens server_01​​​ mit einer Netzwerkschnittstelle namens tun0, die IPv4 verwenden wird:

      server-01:/etc/tinc/netname/tinc.conf

      Name = server_01
      AddressFamily = ipv4
      Interface = tun0
      

      Warnung: Beachten Sie, dass der Wert nach der Anweisung Name einen Unterstrich (_) anstatt eines Bindestrichs (-) enthält. Dies ist wichtig, da tinc verlangt, dass der Wert Name nur alphanumerische oder Unterstrich-Zeichen enthält. Wenn Sie hier einen Bindestrich verwenden, werden Sie bei dem Versuch, das VPN später in diesem Leitfaden zu starten, auf einen Fehler stoßen.

      Speichern und schließen Sie die Datei nach dem Hinzufügen dieser Zeilen. Wenn Sie nano verwendet haben, drücken Sie STRG+X, Y, dann die EINGABETASTE.

      Erstellen Sie als Nächstes eine Host-Konfigurationsdatei namens server_01 im Unterverzeichnis hosts. Letztendlich werden die Client-Knoten diese Datei zur Kommunikation mit server-01 verwenden:

      server-01

      • sudo nano /etc/tinc/netname/hosts/server_01

      Auch hier ist zu beachten, dass der Name dieser Datei einen Unterstrich und keinen Bindestrich enthält. Auf diese Weise entspricht er der Anweisung Name in der Datei tinc.conf, was es tinc ermöglicht, den öffentlichen RSA-Schlüssel des Servers automatisch an diese Datei anzuhängen, wenn wir die Datei später generieren.

      Fügen Sie die folgenden Zeilen in die Datei ein und stellen Sie sicher, dass die öffentliche IP-Adresse von server-01 enthalten ist:

      server-01:/etc/tinc/netname/hosts/server_01

      Address = server-01_public_IP_address
      Subnet = 10.0.0.1/32
      

      Das Feld Address gibt an, wie sich andere Knoten mit diesem Server verbinden werden, und Subnet gibt an, welches Subnetz dieser Daemon bedienen wird. Speichern und schließen Sie die Datei.

      Erzeugen Sie als Nächstes mit dem folgenden Befehl ein Paar öffentlicher und privater RSA-Schlüssel für diesen Host:

      server-01

      • sudo tincd -n netname -K4096

      Nach Ausführung dieses Befehls werden Sie dazu aufgefordert, die Dateinamen einzugeben, unter denen tinc die öffentlichen und privaten RSA-Schlüssel speichern wird:

      Output

      . . . Please enter a file to save private RSA key to [/etc/tinc/netname/rsa_key.priv]: Please enter a file to save public RSA key to [/etc/tinc/netname/hosts/server_01]:

      Drücken Sie die EINGABETASTE, um bei jeder Eingabeaufforderung die Standardspeicherorte zu akzeptieren; dadurch wird tinc angewiesen, den privaten Schlüssel in einer Datei namens rsa_key.priv zu speichern und den öffentlichen Schlüssel an die Host-Konfigurationsdatei server_01 anzuhängen.

      Als Nächstes erstellen Sie tinc-up, das Skript, das bei jedem Start des VPNs netname ausgeführt wird:

      server-01

      • sudo nano /etc/tinc/netname/tinc-up

      Fügen Sie die folgenden Zeilen hinzu:

      server-01:/etc/tinc/netname/tinc-up

      #!/bin/sh
      ip link set $INTERFACE up
      ip addr add 10.0.0.1/32 dev $INTERFACE
      ip route add 10.0.0.0/24 dev $INTERFACE
      

      Im Folgenden wird erläutert, was jede dieser Zeilen bewirkt:

      • ip link …: setzt den Status der virtuellen Netzwerkschnittstelle von tinc auf up
      • ip addr …: fügt der virtuellen Netzwerkschnittstelle von tinc die IP-Adresse 10.0.0.1 mit einer Netzmaske von 32 hinzu, wodurch die anderen Rechner im VPN die IP-Adressse von server-01 als 10.0.0.1 sehen.
      • ip route …: fügt eine Route (10.0.0.0/24) hinzu, die über die virtuelle Netzwerkschnittstelle von tinc erreicht werden kann.

      Speichern und schließen Sie die Datei nach dem Hinzufügen dieser Zeilen.

      Als Nächstes erstellen Sie ein Skript, um die virtuelle Netzwerkschnittstelle zu entfernen, wenn Ihr VPN gestoppt wird:

      server-01

      • sudo nano /etc/tinc/netname/tinc-down

      Fügen Sie die folgenden Zeilen hinzu:

      server-01:/etc/tinc/netname/tinc-down

      #!/bin/sh
      ip route del 10.0.0.0/24 dev $INTERFACE
      ip addr del 10.0.0.1/32 dev $INTERFACE
      ip link set $INTERFACE down
      

      Diese Zeilen haben die entgegengesetzte Wirkung wie die des Skripts tinc-up:

      • ip route …: Löscht die Route 10.0.0.0/24
      • ip addr …: löscht die IP-Adresse 10.0.0.1 aus der virtuellen Netzwerkschnittstelle von tinc
      • ip link …: setzt den Status der virtuellen Netzwerkschnittstelle von tinc auf down

      Speichern und schließen Sie die Datei und machen Sie dann diese beiden neuen Netzwerkskripte ausführbar:

      server-01

      • sudo chmod 755 /etc/tinc/netname/tinc-*

      Fügen Sie als letzten Schritt der Konfiguration von server-01 eine Firewall-Regel hinzu, die den Datenverkehr über Port 655, den Standardport von tinc, zulässt:

      server-01

      server-01 ist nun vollständig konfiguriert und Sie können mit der Einrichtung Ihrer Client-Knoten fortfahren.

      Schritt 3 – Konfigurieren der Client-Knoten

      Ihre beiden Client-Rechner benötigen eine etwas andere Konfiguration als der Server, obwohl der Prozess im Allgemeinen recht ähnlich ist.

      Aufgrund der Einrichtung, die wir in diesem Leitfaden anstreben, werden wir client-01 und client-02 fast identisch, mit nur wenigen kleinen Unterschieden zwischen ihnen, konfigurieren. Daher müssen viele der in diesem Schritt gegebenen Befehle auf beiden Rechnern ausgeführt werden. Beachten Sie jedoch, dass, wenn client-01 oder client-02 einen bestimmten Befehl oder eine spezielle Konfiguration erfordern, diese Anweisungen in einem blauen bzw. roten Befehlsblock angezeigt werden.

      Replizieren Sie sowohl auf client-01 als auch auf client-02 die auf server-01 erstellte Verzeichnisstruktur:

      client-01 & client-02

      • sudo mkdir -p /etc/tinc/netname/hosts

      Erstellen Sie dann eine Datei tinc.conf:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/tinc.conf

      Fügen Sie auf beiden Rechnern die folgenden Zeilen in die Datei ein:

      client-01 & client-02 /etc/tinc/netname/tinc.conf

      Name = node_name
      AddressFamily = ipv4
      Interface = tun0
      ConnectTo = server_01
      

      Stellen Sie sicher, dass Sie node_name durch den Namen des jeweiligen Client-Knotens ersetzen. Auch hier ist darauf zu achten, dass dieser Name einen Unterstrich (_) und keinen Bindestrich verwendet.

      Beachten Sie, dass diese Datei eine Anweisung ConnectTo enthält, die auf server_01 verweist, während die Datei tinc.conf von server-01 diese Anweisung nicht enthält. Indem Sie keine Anweisung ConnectTo auf server-01 einbinden, bedeutet dies, dass server-01 nur auf eingehende Verbindungen lauscht. Dies funktioniert für unsere Einrichtung, da es keine Verbindung mit anderen Rechnern herstellt.

      Speichern und schließen Sie die Datei.

      Erstellen Sie als Nächstes auf jedem Client-Knoten eine Host-Konfigurationsdatei. Achten Sie auch hier darauf, dass der Dateinamen mit einem Unterstrich statt eines Bindestrichs geschrieben wird:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/hosts/node_name

      Fügen Sie für client-01 diese Zeile hinzu:

      client-01:/etc/tinc/netname/hosts/client_01

      Subnet = 10.0.0.2/32
      

      Fügen Sie für client-02 diese Zeile hinzu:

      client-02:/etc/tinc/netname/hosts/client_02

      Subnet = 10.0.0.3/32
      

      Beachten Sie, dass jeder Client ein anderes Subnetz hat, das tinc bedienen wird. Speichern und schließen Sie die Datei.

      Erzeugen Sie als Nächstes auf jedem Client-Rechner die Schlüsselpaare:

      client-01 & client-02

      • sudo tincd -n netname -K4096

      Wie auch bei server-01 drücken Sie bei der Aufforderung zur Dateiauswahl zum Speichern der RSA-Schlüssel die EINGABETASTE, um die Standardauswahl zu akzeptieren.

      Erstellen Sie anschließend das Startskript für die Netzwerkschnittstelle auf jedem Client:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/tinc-up

      Fügen Sie für client-01 diese Zeilen hinzu:

      client-01:/etc/tinc/netname/tinc-up

      #!/bin/sh
      ip link set $INTERFACE up
      ip addr add 10.0.0.2/32 dev $INTERFACE
      ip route add 10.0.0.0/24 dev $INTERFACE
      

      Fügen Sie für client-02 Folgendes hinzu:

      client-02:/etc/tinc/netname/tinc-up

      #!/bin/sh
      ip link set $INTERFACE up
      ip addr add 10.0.0.3/32 dev $INTERFACE
      ip route add 10.0.0.0/24 dev $INTERFACE
      

      Speichern und schließen Sie jede Datei.

      Erstellen Sie als Nächstes auf jedem Client das Stoppskript für die Netzwerkschnittstelle:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/tinc-down

      Fügen Sie auf client-01 den folgenden Inhalt in die leere Datei ein:

      client-01:/etc/tinc/netname/tinc-down

      #!/bin/sh
      ip route del 10.0.0.0/24 dev $INTERFACE
      ip addr del 10.0.0.2/32 dev $INTERFACE
      ip link set $INTERFACE down
      

      Fügen Sie auf client-02 Folgendes hinzu:

      client-02:/etc/tinc/netname/tinc-down

      #!/bin/sh
      ip route del 10.0.0.0/24 dev $INTERFACE
      ip addr del 10.0.0.3/32 dev $INTERFACE
      ip link set $INTERFACE down
      

      Speichern und schließen Sie die Dateien.

      Machen Sie Netzwerkskripte ausführbar, indem Sie auf jedem Client-Rechner den folgenden Befehl ausführen:

      client-01 & client-02

      • sudo chmod 755 /etc/tinc/netname/tinc-*

      Öffnen Sie zum Schluss Port 655 auf jedem Client:

      client-01 & client-02

      Zu diesem Zeitpunkt sind die Client-Knoten fast, wenn auch nicht ganz, eingerichtet. Sie benötigen noch den öffentlichen Schlüssel, den wir im vorherigen Schritt auf server-01 erstellt haben, um die Verbindung zum VPN zu authentifizieren.

      Schritt 4 – Verteilen der Schlüssel

      Jeder Knoten, der direkt mit einem anderen Knoten kommunizieren möchte, muss öffentliche Schlüssel ausgetauscht haben, die sich innerhalb der Host-Konfigurationsdateien befinden. In unserem Fall muss server-01 öffentliche Schlüssel mit den anderen Knoten austauschen.

      Austauschen von Schlüsseln zwischen server-01 und client-01

      Kopieren Sie auf client-01 seine Host-Konfigurationsdatei auf server-01. Da sich sowohl client-01 als auch server-01 im selben Datencenter befinden und beide über ein aktiviertes privates Netzwerk verfügen, können Sie hier die private IP-Adresse von server01 verwenden:

      client-01

      • scp /etc/tinc/netname/hosts/client_01 sammy@server-01_private_IP:/tmp

      Kopieren Sie dann auf server-01 die Host-Konfigurationsdatei von client-01 in das Verzeichnis /etc/tinc/netname/hosts/:

      server-01

      • sudo cp /tmp/client_01 /etc/tinc/netname/hosts/

      Kopieren Sie dann, während Sie sich noch auf server-01 befinden, dessen Host-Konfigurationsdatei nach client-01:

      server-01

      • scp /etc/tinc/netname/hosts/server_01 user@client-01_private_IP:/tmp

      Kopieren Sie auf client-01 die Datei von server-01 an den entsprechenden Ort:

      client-01

      • sudo cp /tmp/server_01 /etc/tinc/netname/hosts/

      Bearbeiten Sie auf client-01 die Host-Konfigurationsdatei von server-01, damit das Feld Address auf die private IP-Adresse von server-01 gesetzt wird. Auf diese Weise verbindet sich client-01 über das private Netzwerk mit dem VPN:

      client-01

      • sudo nano /etc/tinc/netname/hosts/server_01

      Ändern Sie die Anweisung Address so, dass sie auf die private IP-Adresse von server-01 verweist:

      client-01:/etc/tinc/netname/hosts/server_01

      Address = server-01_private_IP
      Subnet = 10.0.0.1/32
      

      Speichern und beenden. Gehen wir jetzt zu unserem verbleibenden Knoten, client-02.

      Austauschen von Schlüsseln zwischen server-01 und client-02

      Kopieren Sie auf client-02 seine Host-Konfigurationsdatei auf server-01:

      client-02

      • scp /etc/tinc/netname/hosts/client_02 sammy@server-01_public_IP:/tmp

      Kopieren Sie dann auf server-01 die Host-Konfigurationsdatei von client_02 an den entsprechenden Ort:

      server-01

      • sudo cp /tmp/client_02 /etc/tinc/netname/hosts/

      Kopieren Sie dann die Host-Konfigurationsdatei von server-01 nach client-02:

      server-01

      • scp /etc/tinc/netname/hosts/server_01 user@client-02_public_IP:/tmp

      Kopieren Sie auf client-02 die Datei von server-01 an den entsprechenden Ort:

      client-02

      • sudo cp /tmp/server_01 /etc/tinc/netname/hosts/

      Angenommen, Sie richten nur zwei Client-Knoten ein, dann sind Sie mit der Verteilung der öffentlichen Schlüssel fertig. Wenn Sie jedoch ein größeres VPN erstellen, ist jetzt ein guter Zeitpunkt, um die Schlüssel zwischen diesen anderen Knoten auszutauschen. Denken Sie daran, dass, wenn zwei Knoten direkt miteinander kommunizieren sollen (ohne einen Weiterleitungsserver dazwischen), sie ihre Schlüssel/Host-Konfigurationsdateien ausgetauscht haben müssen und auf die realen Netzwerkschnittstellen des jeweils anderen zugreifen können müssen. Es ist außerdem in Ordnung, die Konfigurationsdatei jedes Hosts einfach auf jeden Knoten im VPN zu kopieren.

      Schritt 5 – Testen der Konfiguration

      Starten Sie tinc auf jedem Knoten, beginnend mit server-01, mit dem folgenden Befehl:

      All servers

      • sudo tincd -n netname -D -d3

      Dieser Befehl enthält das Flag -n, das auf den Netznamen für unser VPN netname verweist. Dies ist nützlich, wenn Sie mehr als ein VPN eingerichtet haben und Sie angeben müssen, welches Sie starten möchten. Es enthält auch das Flag -D, das die Gabelung und Trennung von tinc verhindert sowie den automatischen Neustartmechanismus von tinc deaktiviert. Schließlich enthält es das Flag -d, das tinc anweist, im Debug-Modus mit einem Debug-Level von 3 zu laufen.

      Anmerkung: Wenn es um den tinc-Daemon geht, zeigt ein Debug-Level von 3 jede zwischen zwei beliebigen Servern ausgetauschte Anfrage, einschließlich Authentifizierungsanforderungen, Schlüsselaustausch und Aktualisierungen von Verbindungslisten. Höhere Debug-Level zeigen mehr Informationen über den Netzwerkverkehr an, aber im Moment geht es nur darum, ob die Knoten miteinander kommunizieren können. Daher ist ein Level von 3 ausreichend. In einem Produktivszenario würden Sie jedoch zu einem niedrigeren Debug-Level wechseln wollen, um die Festplatten nicht mit Protokolldateien zu füllen.

      Sie können mehr über die Debug-Level von tinc erfahren, indem Sie die offizielle Dokumentation durchsehen.

      Nachdem der Daemon auf jedem Knoten gestartet wurde, sollten Sie eine Ausgabe mit den Namen der einzelnen Knoten sehen, wenn sie sich mit server-01 verbinden. Testen wir jetzt die Verbindung über das VPN.

      Pingen Sie in einem separaten Fenster auf client-02 die VPN IP-Adresse von client-01 an. Dieser haben wir zuvor 10.0.0.2 zugewiesen:

      client-02

      Der Ping sollte korrekt funktionieren und Sie sollten in den anderen Fenstern einige Debug-Ausgaben über die Verbindung im VPN sehen. Dies zeigt an, dass client-02 über das VPN über server-01 mit client-01 kommunizieren kann. Drücken Sie STRG+C, um den Ping zu beenden.

      Sie können die VPN-Schnittstellen auch für jede andere Netzwerkkommunikation verwenden, z. B. für Anwendungsverbindungen, das Kopieren von Dateien und SSH.

      Beenden Sie in jedem Debug-Fenster des tinc-Daemons den Daemon durch drücken von STRG+.

      Schritt 6 – Konfigurieren von Tinc zum Starten beim Booten

      Ubuntu-Server verwenden systemd als standardmäßigen Systemmangager, um das Starten und Ausführen von Prozessen zu steuern. Aus diesem Grund können wir das VPN netname so aktivieren, dass es beim Booten mit einem einzigen systemctl-Befehl automatisch gestartet wird.

      Führen Sie den folgenden Befehl auf jedem Knoten aus, um das tinc-VPN so einzustellen, dass es bei jedem Booten des Rechners startet:

      All servers

      • sudo systemctl enable tinc@netname

      Tinc ist so konfiguriert, dass es auf jedem Rechner beim Booten startet, und Sie können es mit dem Befehl systemctl steuern. Wenn Sie es jetzt starten möchten, führen Sie den folgenden Befehl auf jedem Ihrer Knoten aus:

      All servers

      • sudo systemctl start tinc@netname

      Anmerkung: Wenn Sie mehrere VPN haben, aktivieren oder starten jedes sofort, so wie hier:

      All servers

      • sudo systemctl start tinc@natename_01 tinc@netname_02 … tinc@netname_n

      Damit ist Ihr tinc-VPN vollständig konfiguriert und wird auf jedem Ihrer Knoten ausgeführt.

      Zusammenfassung

      Nachdem Sie dieses Tutorial durchgearbeitet haben, sollten Sie nun eine gute Grundlage haben, um Ihr VPN entsprechend Ihren Bedürfnissen auszubauen. Tinc ist sehr flexibel und jeder Knoten kann so konfiguriert werden, dass er sich mit jedem anderen Knoten (auf den er über das Netzwerk zugreifen kann) verbindet, sodass er als Mesh-VPN fungieren kann, ohne sich auf einen einzelnen Knoten zu verlassen.



      Source link

      Como instalar o Tinc e configurar um VPN básico no Ubuntu 18.04


      Introdução

      O Tinc é um programa daemon para Rede Virtual Privada (VPN), de código aberto,com recursos úteis como a criptografia, compressão opcional e o roteamento em malha automático que pode, de maneira oportuna, rotear o tráfego da VPN diretamente entre os servidores. Tais recursos diferenciam o tinc de outras soluções para VPN e fazem com que ele seja uma boa escolha para a criação de uma VPN a partir das diversas redes pequenas, geograficamente distribuídas.

      Neste tutorial, vamos revisar como usar o tinc para criar uma VPN segura na qual seus servidores podem se comunicar como se estivessem em uma rede local. Também vamos demonstrar como usar o tinc para configurar um túnel seguro em uma rede privada. Vamos usar servidores Ubuntu 18.04, mas as configurações podem ser adaptadas para uso com qualquer outro SO.

      Objetivos

      Para abranger vários casos de uso, este tutorial define como conectar um nó de cliente à VPN em uma interface de rede privada e outro à uma pública. No entanto, você pode adaptar essa configuração para atender às suas próprias necessidades. Você precisará apenas planejar como vai querer que seus servidores acessem uns aos outros, adaptando os exemplos apresentados neste tutorial às suas próprias necessidades. Se você estiver adaptando esses procedimentos à sua própria configuração, certifique-se de substituir os valores destacados nos exemplos pelos seus próprios valores. Porem, pode ser que você prefira primeiro seguir o tutorial da forma como foi escrito, no intuito de garantir que você entenda os componentes e processos envolvidos, antes de modificar essas instruções.

      Para ajudar a deixar as coisas claras, este tutorial irá referir-se aos servidores desta forma:

      • servidor-01: todos os nós da VPN serão conectados a esse computador e a conexão deverá ser mantida para o funcionamento adequado da VPN. Se quiser, servidores adicionais podem ser configurados da mesma maneira para proporcionar redundância.
      • cliente-01: conecta-se ao nó da VPN do server-01, usando sua interface de rede privada.
      • cliente-02: conecta-se ao nó da VPN no servidor-01 por uma interface de rede pública.

      Nota: o próprio Tinc não sabe diferenciar os servidores (computadores que hospedam e entregam os serviços da VPN) dos clientes (as máquinas que se conectam à rede privada segura e a utilizam). Porém, pode ser ser útil entender e visualizar como o tinc funciona, pensando nos seus servidores dessa forma.

      Apresentamos abaixo, um diagrama da VPN que queremos configurar:

      Configuração da VPN Tinc

      A caixa azul representa nossa VPN e a rosa representa a rede privada subjacente. Todos os três servidores podem se comunicar na VPN, embora a rede privada, de qualquer forma, fique inacessível para o cliente-02.

      Pré-requisitos

      Caso queira seguir de maneira exata este, providencie dois servidores Ubuntu 18.04. (servidor-01 e cliente-01) no mesmo datacenter e habilite a conexão em rede privada em cada um. Depois, crie outro servidor Ubuntu 18.04 (cliente-02) em um datacenter separado. Cada servidor deverá ter um usuário administrativo e um firewall configurado com o ufw. Para configurar isso, siga nosso guia de configuração inicial de servidor para o Ubuntu 18.04.

      Além disso, mais adiante, neste tutorial, precisaremos transferir alguns arquivos entre cada computador usando o scp. Por isso, você precisará gerar chaves SSH em cada um dos seus servidores, adicionar ambas chaves SSH do cliente-01 e do cliente-02 ao arquivo authorized-keys do servidor-01 e, em seguida, adicionar a chave SSH do servidor-01 a ambos arquivos authorized_keys – do cliente-01 e do cliente-02. Para ajudar na configuração disso tudo, consulte nosso guia sobre Como configurar chaves SSH no Ubuntu 18.04.

      Passo 1 — Instalando o Tinc

      O Tinc está disponível nos repositórios padrão da ferramenta APT do Ubuntu, o que significa que podemos instalá-lo com apenas alguns comandos.

      Caso não tenha feito isso recentemente, execute o seguinte comando em cada servidor para atualizar seus respectivos índices de pacotes:

      All servers

      Então, instale o tinc em cada servidor executando o seguinte comando:

      All servers

      Com isso, você instalou o tinc em cada um dos seus servidores. No entanto, para colocar sua VPN em funcionamento, você precisará fazer algumas alterações na configuração do tinc em cada máquina. Vamos começar atualizando o servidor-01.

      Passo 2 — Configurando o servidor do Tinc

      O Tinc exige que cada computador que fizer parte da VPN tenha os três componentes de configuração a seguir:

      • Arquivos de configuração do Tinc: há três arquivos distintos que configuram o daemon do tinc:
        • tinc.conf, que define o netname, o dispositivo de rede no qual a VPN irá executar e outras opções da VPN;
        • tinc-up, um script que ativa o dispositivo de rede definido em tinc.conf após a inicialização do tinc;
        • tinc-down, que desativa o dispositivo de rede sempre que o tinc parar.
      • Pares de chaves públicas/privadas: o Tinc usa pares de chaves públicas/privadas para garantir que apenas os usuários com chaves válidas possam acessar a VPN.
      • Arquivos de configuração de host: cada máquina (ou host) na VPN tem seu próprio arquivo de configuração que contém o endereço IP real do host e a sub-rede onde o tinc a atenderá.

      O Tinc usa um netname para distinguir uma VPN da outra. Isso é útil nos casos em que você queira configurar várias VPN. Porém, é recomendável que você use um netname, mesmo se você estiver planejando configurar apenas uma VPN. Você pode dar à sua VPN o nome que quiser, mas, para simplificar, vamos chamar nossa VPN de netname.

      No servidor-01, crie a estrutura de diretórios de configuração para a VPN:

      server-01

      • sudo mkdir -p /etc/tinc/netname/hosts

      Use seu editor de texto preferido para criar um arquivo tinc.conf. Aqui, usaremos o nano:

      server-01

      • sudo nano /etc/tinc/netname/tinc.conf

      Adicione as linhas a seguir ao arquivo em branco. Essas linhas configuram um nó do tinc chamado server_01 com uma interface de rede chamada tun0, a qual usará o IPv4:

      server-01:/etc/tinc/netname/tinc.conf

      Name = server_01
      AddressFamily = ipv4
      Interface = tun0
      

      Aviso: note que o valor depois da diretriz Name inclui um sublinhado (_) em vez de um hífen (-). Isso é importante, pois o tinc exige que o valor Name contenha apenas caracteres alfanuméricos ou sublinhados. Se usar um hífen aqui, você encontrará um erro quando tentar iniciar a VPN mais tarde neste guia.

      Salve e feche o arquivo após adicionar essas linhas. Se usou o nano, salve e feche o arquivo, pressionando as teclas CTRL+X,Ye, depois ENTER.

      Em seguida, crie um arquivo de configuração do host, chamado server_01 no subdiretório hosts. No fim das contas, os nós do cliente usarão este arquivo para se comunicar com o servidor-01:

      server-01

      • sudo nano /etc/tinc/netname/hosts/server_01

      Novamente, note que o nome desse arquivo contém um sublinhado, em vez de um hífen. Dessa forma, ele se alinha com a diretiva de Name no arquivo tinc.conf, o que permitirá que o tinc anexe automaticamente a chave RSA pública do servidor a esse arquivo quando a gerarmos mais tarde.

      Adicione as linhas a seguir ao arquivo, certificando-se de incluir o endereço IP público do servidor-01:

      server-01:/etc/tinc/netname/hosts/server_01

      Address = server-01_public_IP_address
      Subnet = 10.0.0.1/32
      

      O campo Address especifica como outros nós se conectarão a esse servidor e o campo Subnet especifica qual sub-rede este daemon irá atender. Salve e feche o arquivo.

      Em seguida, gere um par de chaves RSA – pública e privada – para esse host, com o seguinte comando:

      server-01

      • sudo tincd -n netname -K4096

      Após executar esse comando, você será solicitado a digitar os nomes dos arquivos onde o tinc salvará as chaves RSA pública e privada:

      Output

      . . . Please enter a file to save private RSA key to [/etc/tinc/netname/rsa_key.priv]: Please enter a file to save public RSA key to [/etc/tinc/netname/hosts/server_01]:

      Pressione ENTER para aceitar os locais padrão em cada prompt; fazer isso dirá ao tinc para armazenar a chave privada em um arquivo chamado rsa_key.priv e anexar a chave pública ao arquivo de configuração de host do server_01.

      Em seguida, crie o tinc-up, o script que será executado sempre que a VPN netname for iniciada:

      server-01

      • sudo nano /etc/tinc/netname/tinc-up

      Adicione as linhas seguintes:

      server-01:/etc/tinc/netname/tinc-up

      #!/bin/sh
      ip link set $INTERFACE up
      ip addr add 10.0.0.1/32 dev $INTERFACE
      ip route add 10.0.0.0/24 dev $INTERFACE
      

      Descrevemos abaixo o que cada uma dessas linhas faz:

      • ip link ...: define o status da interface de rede virtual do tinc como up
      • ip addr ...: adiciona o endereço IP 10.0.0.1 com uma máscara de rede de 32 à interface da rede virtual do tinc, o que fará com que as outras máquinas na VPN vejam o endereço IP do servidor-01 como 10.0.0.1
      • ip route ...: adiciona uma rota (10.0.0.0/24), a qual pode ser alcançada na interface da rede virtual do tinc.

      Salve e feche o arquivo após adicionar essas linhas.

      Em seguida, crie um script para remover a interface da rede virtual quando sua VPN for interompida:

      server-01

      • sudo nano /etc/tinc/netname/tinc-down

      Adicione as linhas seguintes:

      server-01:/etc/tinc/netname/tinc-down

      #!/bin/sh
      ip route del 10.0.0.0/24 dev $INTERFACE
      ip addr del 10.0.0.1/32 dev $INTERFACE
      ip link set $INTERFACE down
      

      Estas linhas causam os efeitos opostos aos do script tinc-up:

      • ip route ...: exclui a rota 10.0.0.0/24
      • ip addr ...: exclui o endereço IP 10.0.0.1 da interface da rede virtual do tinc
      • ip link ...: define o status da interface da rede virtual do tinc como down

      Salve e feche o arquivo e, em seguida, torne esses dois novos scripts de rede executáveis:

      server-01

      • sudo chmod 755 /etc/tinc/netname/tinc-*

      Como passo final na configuração do servidor-01, adicione uma regra de firewall que permitirá o tráfego pela porta 655 – porta padrão do tinc:

      server-01

      O servidor-01 agora está totalmente configurado e você pode prosseguir com a configuração dos nós do seu cliente.

      Passo 3 — Configurando os nós do cliente

      Ambas as máquinas do seu cliente precisarão de uma configuração ligeiramente diferente da configuração do servidor, embora o processo seja no geral bastante parecido.

      Por conta da configuração que estamos almejando neste guia, vamos configurar o cliente-01 e cliente-02 de maneira quase idêntica, com apenas pequenas diferenças entre eles. Assim, muitos dos comandos dados neste passo devem ser executados em ambas as máquinas. Note, entretanto, que se o cliente-01 ou** cliente-02** precisarem de um comando específico ou de uma configuração especial, essas instruções serão exibidas em um bloco de comandos azul ou vermelho, respectivamente.

      Replique a estrutura de diretórios que você criou no servidor-01 no cliente-01 e no cliente-02:

      client-01 & client-02

      • sudo mkdir -p /etc/tinc/netname/hosts

      Depois, crie um arquivo tinc.conf:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/tinc.conf

      Adicione as linhas a seguir ao arquivo de ambas as máquinas:

      client-01 & client-02 /etc/tinc/netname/tinc.conf

      Name = node_name
      AddressFamily = ipv4
      Interface = tun0
      ConnectTo = server_01
      

      Certifique-se de substituir o node_name pelo nome de nó do cliente respectivo. Novamente, certifique-se de que esse nome use um sublinhado (_) em vez de um hífen.

      Note que esse arquivo contém uma diretiva ConnectTo apontando para o servidor_01, ao passo que o arquivo tinc.conf do servidor-01 não incluiu essa diretiva. Ao deixar de incluir uma instrução ConnectTo no servidor-01, isso significa que o servidor-01 escutará apenas as conexões de entrada. Isso funcionará para a nossa configuração, uma vez que ela não se conectará a nenhuma outra máquina.

      Salve e feche o arquivo.

      Em seguida, crie um arquivo de configuração de host no nó de cada cliente. Novamente, certifique-se de que o nome do arquivo seja escrito com um sublinhado em vez de um hífen:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/hosts/node_name

      Para o cliente-01, adicione esta linha:

      client-01:/etc/tinc/netname/hosts/client_01

      Subnet = 10.0.0.2/32
      

      Para o cliente-02, adicione esta linha:

      client-02:/etc/tinc/netname/hosts/client_02

      Subnet = 10.0.0.3/32
      

      Note que cada cliente tem uma sub-rede diferente que o tinc atenderá. Salve e feche o arquivo.

      Em seguida, gere os pares de chaves na máquina de cada cliente:

      client-01 & client-02

      • sudo tincd -n netname -K4096

      Novamente, assim como você fez com o servidor-01, quando foi solicitado a selecionar arquivos para armazenar as chaves RSA, pressione ENTER para aceitar as escolhas padrão.

      Em seguida, crie o script de inicialização da interface da rede em cada cliente:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/tinc-up

      Para o cliente-01, adicione estas linhas:

      client-01:/etc/tinc/netname/tinc-up

      #!/bin/sh
      ip link set $INTERFACE up
      ip addr add 10.0.0.2/32 dev $INTERFACE
      ip route add 10.0.0.0/24 dev $INTERFACE
      

      Para o cliente-02, adicione o seguinte:

      client-02:/etc/tinc/netname/tinc-up

      #!/bin/sh
      ip link set $INTERFACE up
      ip addr add 10.0.0.3/32 dev $INTERFACE
      ip route add 10.0.0.0/24 dev $INTERFACE
      

      Salve e feche cada arquivo.

      Em seguida, crie o script de parada da interface da rede em cada cliente:

      client-01 & client-02

      • sudo nano /etc/tinc/netname/tinc-down

      No cliente-01, adicione o seguinte conteúdo ao arquivo em branco:

      client-01:/etc/tinc/netname/tinc-down

      #!/bin/sh
      ip route del 10.0.0.0/24 dev $INTERFACE
      ip addr del 10.0.0.2/32 dev $INTERFACE
      ip link set $INTERFACE down
      

      No cliente-02, adicione o seguinte:

      client-02:/etc/tinc/netname/tinc-down

      #!/bin/sh
      ip route del 10.0.0.0/24 dev $INTERFACE
      ip addr del 10.0.0.3/32 dev $INTERFACE
      ip link set $INTERFACE down
      

      Salve e feche os arquivos.

      Torne os scripts de rede executáveis, usando o comando a seguir na máquina de cada cliente:

      client-01 & client-02

      • sudo chmod 755 /etc/tinc/netname/tinc-*

      Por fim, abra a porta 655 em cada cliente:

      client-01 & client-02

      Neste ponto, os nós do cliente estarão quase prontos – mas não totalmente. Eles ainda precisam da chave pública que criamos no servidor-01 no passo anterior para autenticar a conexão com a VPN.

      Passo 4 — Distribuindo as chaves

      Cada nó que quiser se comunicar diretamente com outro nó deve ter trocado as chaves públicas, as quais ficam dentro dos arquivos de configuração do host. No nosso caso, o servidor-01 precisa trocar chaves públicas com os outros nós.

      Troque as chaves entre o servidor-01 e o cliente-01

      No cliente-01, copie seu arquivo de configuração de host para o servidor-01. Como tanto o cliente-01 quanto o servidor-01 estão no mesmo datacenter e ambos têm a rede privada habilitada, você pode usar o endereço IP privado do server01 aqui:

      client-01

      • scp /etc/tinc/netname/hosts/client_01 sammy@server-01_private_IP:/tmp

      Em seguida, no servidor-01, copie o arquivo de configuração do host do cliente-01 para o diretório /etc/tinc/netname/hosts/:

      server-01

      • sudo cp /tmp/client_01 /etc/tinc/netname/hosts/

      Na sequência, enquanto ainda estiver no servidor-01, copie seu arquivo de configuração do host para o cliente-01:

      server-01

      • scp /etc/tinc/netname/hosts/server_01 user@client-01_private_IP:/tmp

      No cliente-01, copie o arquivo do servidor-01 para o local apropriado:

      client-01

      • sudo cp /tmp/server_01 /etc/tinc/netname/hosts/

      No cliente-01, edite o arquivo de configuração de host do** servidor-01** para que o campo Address seja definido para o endereço IP privado do servidor-01. Dessa forma, o cliente-01 se conectará à VPN através da rede privada:

      client-01

      • sudo nano /etc/tinc/netname/hosts/server_01

      Altere a diretiva de Address para que aponte para o endereço IP privado do servidor-01:

      client-01:/etc/tinc/netname/hosts/server_01

      Address = server-01_private_IP
      Subnet = 10.0.0.1/32
      

      Salve e saia. Agora, vamos prosseguir com o nó restante, no cliente-02.

      Troque as chaves entre o servidor-01 e o cliente-02

      No cliente-02, copie seu arquivo de configuração de host para o servidor-01.

      client-02

      • scp /etc/tinc/netname/hosts/client_02 sammy@server-01_public_IP:/tmp

      Na sequência, no servidor-01, copie o arquivo de configuração de host do client_02 para o local adequado:

      server-01

      • sudo cp /tmp/client_02 /etc/tinc/netname/hosts/

      Depois, copie o arquivo de configuração de host do servidor-01 para o cliente-02:

      server-01

      • scp /etc/tinc/netname/hosts/server_01 user@client-02_public_IP:/tmp

      No cliente-02, copie o arquivo do servidor-01 para o local apropriado:

      client-02

      • sudo cp /tmp/server_01 /etc/tinc/netname/hosts/

      Presumindo-se que você esteja configurando apenas dois nós de cliente, neste ponto você terá terminado de distribuir as chaves públicas. No entanto, se estiver criando uma VPN maior, agora é uma boa hora para trocar as chaves entre esses outros nós. Lembre-se de que, caso queira que dois nós se comuniquem diretamente entre si (sem um servidor de encaminhamento entre eles), eles precisarão ter trocado seus arquivos de configuração de chaves/hosts e um precisará ter acesso à interface da rede real do outro. Além disso, é aceitável copiar apenas o arquivo de configuração de cada host para todo nó na VPN.

      Passo 5 — Testando a configuração

      Em cada nó, começando pelo servidor-01, inicie o tinc com o seguinte comando:

      All servers

      • sudo tincd -n netname -D -d3

      Esse comando inclui um sinalizador -n, que aponta para o netname de nossa VPN, netname. Isso será útil se você tiver mais de uma VPN configurada e precisar especificar qual deles você deseja iniciar. Ele também inclui o sinalizador -D, que impede o tinc de bifurcar e desconectar, bem como desabilita o mecanismo de reinício automático do tinc. Por fim, ele inclui o sinalizador -d, que diz ao tinc para ser executado no modo de depuração, com um nível de depuração de 3.

      Nota: em se tratando do daemon do tinc, um nível de depuração de 3 mostrará cada pedido trocado entre quaisquer dois servidores, incluindo pedidos de autenticação, troca de chaves e atualizações da lista de conexão. Os níveis de depuração mais elevados mostram mais informações acerca do tráfego de rede, mas, por enquanto, estamos preocupados apenas se os nós podem se comunicar entre si, de modo que um nível de 3 será suficiente. Entretanto, em um cenário de produção, você talvez queira mudar para um nível de depuração inferior, de modo a não sobrecarregar os discos com arquivos de registro.

      Você pode aprender mais sobre os níveis de depuração do tinc, revisando a documentação oficial.

      Após iniciar o daemon em cada nó, você deve ver o resultado com os nomes de cada nó à medida em que se conectam ao servidor-01. Agora, vamos testar a conexão através da VPN.

      Numa janela separada, no cliente-02, execute um ping para o endereço IP daVPN do cliente-01. Anteriormente, nós atribuímos o endereço 10.0.0.2:

      client-02

      O ping deverá funcionar corretamente e você deverá ver algum resultado de depuração nas outras janelas sobre a conexão na VPN. Isso indica que o cliente-02 consegue se comunicar pela VPN, através do servidor-01 com o cliente-01. Pressione CTRL+C para parar o ping.

      Você também pode usar as interfaces com a VPN para fazer qualquer outra comunicação em rede, como conexões de aplicativo, copiar arquivos e SSH.

      Em cada janela de depuração do daemon do tinc, saia do daemon pressionando CTRL+.

      Passo 6 — Configurando o tinc para iniciar na inicialização

      Os servidores com Ubuntu usam o systemd como o gerenciador de sistema padrão para controlar os processos de inicialização e execução. Por conta disso, podemos habilitar a VPN netname para iniciar automaticamente na inicialização com um único comando systemctl.

      Execute o comando a seguir em cada nó para configurar a VPN do tinc para iniciar sempre que a máquina for inicializada:

      All servers

      • sudo systemctl enable tinc@netname

      O tinc está configurado para iniciar na inicialização de cada uma das suas máquinas e você pode controlar isso com o comando systemctl. Caso queira iniciá-lo agora, execute o seguinte comando em cada um dos seus nós:

      All servers

      • sudo systemctl start tinc@netname

      Nota: se tiver várias VPNs, habilite ou inicie cada um deles de uma vez, desta forma:

      All servers

      • sudo systemctl start tinc@natename_01 tinc@netname_02 … tinc@netname_n

      Com isso, sua VPN do tinc estará totalmente configurada e em funcionamento em cada um dos seus nós.

      Conclusão

      Agora que você concluiu este tutorial, já deve ter uma boa base para criar sua própria VPN para atender às suas necessidades. O tinc é bastante flexível e qualquer nó pode ser configurado para se conectar a qualquer outro nó (que ele possa acessar através de rede), de modo que ele pode atuar como uma malha de VPN, sem depender de um nó específico.



      Source link