4.7-Filling the bucket

We'll need a specific hierarchy of folders and files in our S3 bucket, so that the bootstrap script (enabling our OpenVPN server auto-configuration at startup) finds all the required elements to do its job.

We'll first prepare this entire hierarchy locally, so that we can :

  • easily check/edit/recheck our file contents and the names of all files and sub-folders

  • use both transfer options later on :

Important : Save files in LF / Unix format

The files we'll put in the bucket will mostly be used in a Linux environment, so they should be saved in "Unix mode" for End-Of-Line control characters :

  • Windows is the world of CRLF (Carriage Return + Line Feed)

  • Unix/Linux-based systems use LF (Line Feed) exclusively and DON'T LIKE the CR pseudo-character (you can usually see them in error messages, listed as $13 or Ctrl-M or ^M)

Saving your files in another mode than LF will lead to problems that will kill your server boot-up sequence !

So please use a proper editor which enables you to choose LF/Unix "end-of-line" mode before saving your files :

Choosing "Unix (LF)" with a right-click in Notepad++
Choosing LF as "End of Line Sequence" in VS Code

Building the hierarchy locally

We'll create a hierarchy of folders actually designed to "host" not only our own current setup, but also several similar setups if needed.

Do you remember the my-fg-ovpn-s3 sub-folder we created long ago ? That's what we'll use it for.

We'll begin by 2 folders at the top level : deploy and userdata

Then within deploy, we'll create 3 sub-folders : conf, init and refresh like this :

userdata NEEDS You ! 👋

This folder will contain one bootstrap file for each "configuration name" that has an auto-configuration script : our own my-fg-ovpn will shortly have one, so we'll give it a UserData file.

This type of file is in fact a set of commands executed by an AWS EC2 "Instance" (=a virtual server) only when it boots for the first time.

So these files are like mini-shell scripts and we'll call them "configuration name"-userdata.sh

In our setup, the "userdata script" will download and run a much bigger setup script that will do the auto-configuration work, as well as start OpenVPN.

Let's look at the beginning of the sample userdata file :

You will NEED to customize the values at lines 4 to 6 below, according to your own choices

We have 2 (or 3) values here, that have to reflect the choices you made earlier :

  • at line 4 you need to give YOUR chosen "configuration name"

  • at line 5 you need to give the exact name of YOUR S3 bucket

  • at line 6 you see the VPN Private IP network

The VPN private IP network

Just like you have a private IP on your home network connection, when you are connected to the VPN you get another private IP with it, and that VPN private IP will be in the IP network of line 6 above.

You have to check that the VPN private IP network does not overlap with any of your other private IP networks (home/WIFI network, other VPNs you may be connected to...)

It also must not overlap with the AWS VPC IPv4 CIDR block that you noted before

In most cases :

  • your home network is : 192.168.0.0/24 or 192.168.1.0/24

  • your VPC IPv4 block is 172.31.0.0/16

  • so you should be fine keeping the default 10.10.10.0/24 for the VPN

But If you need, change the VPN private IP network at line 6, from the default 10.10.10.0/24 to any other private block of 256 IPv4 addresses (this setup supports only /24 subnets).

I suggest using a 10.x.y.0/24 block (with your chosen x and y between 0 and 254).

For our my-fg-ovpn demo, having no issue with the default VPN private IP block, we'll edit our UserData file so that it looks like :

Sample userdata file to copy + rename + edit

Here is the complete UserData file for a configuration called "sample-conf-name", that you will copy/paste and rename, then edit lines 4-6 so that it matches your own choices/requirements :

Your own resulting userdata script being kept safe, both in your machine and in S3, will come to use when you create a Launch Template, or when you manually Launch your virtual server.

The init script : fgovpn001-init.sh

This has been adapted from other init scripts taken from my VPN servers, I won't dive into the details there because that would be 100%...

Tech blurb !

For those interested, the actual port forwarding is setup at lines 85-86 with iptables PREROUTING and POSTROUTING rules

Just copy/paste this (200+ lines) shell script to the init sub-folder and give it the proper name : it must be the same as what you see at line 34 of the userdata script above : fgovpn001-init.sh

The main initialization script, stored "as-is".

Files for OpenVPN go into conf

Now we have to put the things OpenVPN itself will need.

We'll create a sub-folder with our "configuration name" in the conf folder :

In this folder, we need 6 properly named (config.name -prefixed) files :

  • the CA public certificate (.crt)

  • the TLS-Auth key (.key)

  • the DH file (.pem)

  • the OpenVPN Server public certificate (.crt) + private key (.key) + certificate signing request (.csr)

For our demo, these will be :

  • my-fg-ovpn-ca.crt

  • my-fg-ovpn-ta.key

  • my-fg-ovpn-dh2048.pem

  • my-fg-ovpn-srv.crt

  • my-fg-ovpn-srv.key

  • my-fg-ovpn-srv.csr

conf : most of OpenVPN required files

We're just missing one item : the CRL to filter out revoked certificates.

refresh is for the CRL

The CRL (Certificate Revocation List) is one of those things that can evolve over time, as you revoke certificates to prevent them from connecting to the server...

It's likely you won't create/revoke many certificates, but we have to make sure everything is in the right place, just in case - and anyway our setup requires it ! 😛

We'll create a sub-folder with our "configuration name" in the refresh folder...

...and a sub-folder called crl inside this one, where we'll drop our latest CRL file :

Our OpenVPN server will always search for his CRL file in that folder : we only need the properly named (config.name -prefixed) CRL file (.pem) there.

For our demo, it is my-fg-ovpn-crl.pem :

Ready to transfer !

...and with that, our S3 bucket "image" is now ready for transfer to S3 :

We'll do the actual transfer in Step 5, but before that let's build a Launch Template

Previous4.6-Creating an AWS Security GroupNext4.8-Building the Launch Template

Last updated

Was this helpful?