Cómo puede utilizar OpenVPN para acceder de forma segura a los recursos privados de AWS

Este artículo fue adaptado de parte de mi nuevo curso de Pluralsight, "Conexión de recursos locales a su infraestructura de AWS".

¿A veces necesita conectarse a recursos que se ejecutan en Amazon Web Services? Acceder a sus instancias públicas de EC2 mediante SSH y cifrar sus datos de S3 es, para todos los efectos, lo suficientemente seguro. Pero, ¿qué pasa con ingresar a una instancia de base de datos RDS back-end o trabajar con datos basados ​​en AWS que no son públicos? Hay todo tipo de razones por las que los administradores mantienen estos recursos fuera del alcance del público en general. Pero si no puede acceder a ellos cuando los necesita, ¿de qué le servirán?

Por lo tanto, deberá encontrar una forma segura y confiable de evitar las ACL y los grupos de seguridad que protegen sus cosas. Una solución que cubro en mi curso "Conexión de recursos locales a su infraestructura de AWS" en Pluralsight es Direct Connect. Pero si el precio de Direct Connect es un desperdicio de presupuesto para su empresa, entonces algún tipo de túnel VPN podría ser la solución.

¿Qué es una red privada virtual?

Las redes privadas virtuales (VPN) se utilizan a menudo para permitir una actividad de red restringida o una navegación anónima. Pero de eso no se trata este artículo.

Una VPN es una conexión de punto a punto que le permite mover datos de forma segura entre dos sitios a través de una red pública. Efectivamente, se puede diseñar un túnel para combinar dos sitios privados separados geográficamente en una sola red privada. En nuestro contexto, eso significaría conectar la red de su oficina local con la AWS VPC que aloja sus recursos privados.

Hay dos maneras de hacer esto:

  • Una conexión VPN administrada construida sobre una puerta de enlace privada virtual de AWS
  • Usando su propia VPN.

Este artículo se centrará en el método hágalo usted mismo.

El servidor de acceso OpenVPN

Como sugiere su nombre, OpenVPN es un proyecto de código abierto, y siempre puede descargar la edición comunitaria gratuita y configurar las cosas en su propio servidor VPN. Pero la compañía OpenVPN también proporciona un servidor de acceso OpenVPN especialmente diseñado como una AMI EC2 que viene lista para usar con herramientas de configuración automatizadas e integración amigables con AWS.

Por lo que puedo ver, lanzar la AMI dentro de su AWS VPC y abrirla para conexiones remotas controladas se ha convertido prácticamente en la forma "correcta" de hacer este trabajo.

¿Cuanto cuesta? Si solo está probando cosas y no planea acceder a la VPN utilizando más de dos conexiones a la vez, entonces la AMI en sí es gratuita. Aún estará pendiente de los costos regulares de una instancia EC2, pero si su cuenta aún es elegible para la capa gratuita, también puede obtenerla gratis.

Una vez que ponga su VPN en producción activa, la licencia que adquiera dependerá de la cantidad de conexiones simultáneas que necesite. Esta página tiene los detalles que necesitará.

Esto es lo que haremos en esta guía:

  • Seleccionar, aprovisionar e iniciar una AMI de Ubuntu con OpenVPN Access Server preinstalado en mi VPC
  • Acceda al servidor mediante SSH y configure la VPN
  • Configurar un usuario administrador
  • Configurar una máquina local como cliente OpenVPN y conectarse a una instancia privada en mi AWS VPC

Listo?

Lanzamiento de un servidor de acceso OpenVPN

Desde el panel de EC2, y asegurándonos de que estamos en la región de AWS correcta, lance una instancia para que actúe como nuestro servidor VPN. En lugar de utilizar una de las AMI de inicio rápido, haré clic en la pestaña AWS Marketplace y buscaré "servidor de acceso openvpn". OpenVPN proporciona una serie de imágenes oficiales que están vinculadas a licencias que ofrecen un número creciente de clientes conectados.

Voy a ir con esta imagen de Ubuntu que funciona a través de un arreglo de "Traiga su propia licencia". Como escribí anteriormente, en realidad no necesitaremos una licencia para lo que vamos a hacer.

Al seleccionar la AMI, se abre una ventana emergente que nos indica cuánto nos costará esta imagen por hora utilizando varios tipos de instancias y opciones de almacenamiento de EBS. Sin embargo, esos son solo costos de infraestructura de AWS regulares y no incluyen las tarifas de licencia.

Cuando se trata del tipo de instancia, lo degradaré a un t2.micro para mantenerlo dentro del nivel gratuito. Un servidor de producción ocupado puede requerir un poco más de energía.

Como voy a querer iniciar una segunda instancia en la misma subred en unos minutos, seleccionaré, digamos, “us-east-1b” en la página Configurar detalles de instancia y tomaré una nota para más adelante.

Ahora, la página del Grupo de seguridad es donde realmente brilla la configuración de OpenVPN AMI. Se nos presenta un grupo de seguridad que abre todo lo que necesitamos. El puerto 22 es para el tráfico SSH en el servidor, el 943 es el puerto que usaremos para acceder a la GUI del administrador, el 443 es el tráfico HTTP cifrado con TLS y OpenVPN escuchará las conexiones entrantes del cliente en el puerto 1194.

Nota : Si es práctico, normalmente sería una buena idea endurecer esas reglas para que solo se acepten solicitudes de rangos de direcciones IP válidos de la empresa, pero esto estará bien para pruebas a corto plazo.

Desde aquí, revisaré mi configuración, confirmaré que tengo la clave de cifrado SSH listada y apretaré el gatillo.

Una vez que se lanza la instancia, se me mostrará información de inicio de sesión importante, incluido el hecho de que la cuenta de usuario que usaremos para SSH en el servidor se llama openvpnas, y una guía de inicio rápido. También recibiré un correo electrónico con enlaces a la misma información.

De vuelta en la consola de instancias EC2, mientras la nueva máquina termina de iniciarse, se nos muestra nuestra dirección IP pública. Si alguna vez tuviéramos que reiniciar la instancia, no hay garantía de que obtengamos la misma IP nuevamente, lo que podría causar una cantidad razonable de caos. Por lo tanto, es una buena idea asignar a la instancia una IP elástica.

Para hacer eso, haré clic en IP elásticas y luego en Asignar nueva dirección. Anote la nueva dirección y cierre la página. Ahora, con esa dirección seleccionada, haga clic en Acciones y "Asociar dirección". Haré clic una vez en el cuadro Instancia y aparecerá mi instancia de OpenVPN, con su etiqueta útil. Solo necesito seleccionarlo, hacer clic en "Asociar" y listo. A partir de ahora, esa será la IP pública permanente para acceder a nuestro servidor.

Accediendo al servidor

I’ll paste the public IP address into the terminal as part of my SSH command that calls the key pair I set for this instance.

ssh -i KeyPairName.pem [email protected]

If you’re accessing from a Windows or macOS machine, things might work a bit differently, but the documentation will give you all the help you’ll need.

Before I leave the Instances console, however, I’ll perform one more important function. With the OpenVPN instance selected, I’ll click Actions and then Networking and then “Change Source/Dest checking”. I’ll make sure that checking is disabled. Nothing much will be possible unless I do this.

Now over to my SSH session. As soon as it begins, I’m confronted by the OpenVPN EULA license agreement, and then the setup wizard. If you need to change a setting later you can always run the wizard again using this command:

sudo ovpn-init — ec2.

Most of the wizard’s defaults will work fine, but it’s worth quickly explaining what’s happening. Here are the questions and some color commentary where necessary:

primary Access Server node? yes [You’d answer no if you were setting up a backup or failover node.] specify the network interface and IP address to be used by the Admin Web UI [1 — For all interfaces; can be changed to static later.] specify the port number for the Admin Web UI [default] specify the TCP port number for the OpenVPN Daemon [default] Should client traffic be routed by default through the VPN? [no--That’s not the kind of VPN we’re building here. What we’re doing is only about getting remote clients safely and securely into our VPC. The same applies to client DNS traffic.] Should client DNS traffic be routed by default through the VPN? [no] Use local authentication via internal DB? [no — can be useful, but we’ll use Linux/AWS authentication for simplicity.] Should private subnets be accessible to clients by default? [yes — that’s the whole point of the VPN, after all.] login to the Admin UI as “openvpn”? [yes] Provide OpenVPN Access Server license key [Unnecessary for testing.]

When the wizard completes, I’m shown some connection information and advised to install the network time daemon NTP. That won’t be necessary on this Ubuntu box, as it’s already installed and running by default.

As I mentioned earlier, I will need to give the openvpn user a password so I can use it to log into the web GUI. I do that as sudo with the passwd command.

sudo passwd openvpn

That’s all the server-side stuff we’ll need. Now I’m going to use a browser to log into the web GUI. I use our server’s public IP address with the secure https prefix, followed by slash and admin.

///admin

You’ll get a “Your connection is not private” warning because we’re using a self-signed certificate rather than one provided by a Certificate Authority.

That’s not a problem for us, since we’re only exposing our VPN to select users from within our company, and they should be able to trust our certificate. So I’ll click through the warning, sign in, and agree to the EULA .

Feel free to spend some time exploring the features provided by the OpenVPN admin console on your own.

Setting up a VPN client

Right now, however, I’m going to open the client UI page using the web access address we were shown before, but this time without the slash admin. This is nothing more than a login screen where you can authenticate using the same openvpn user as before. (You can always create new users back in the admin console.)

Behind the login screen, there’s just this set of links with directions for installing the OpenVPN client app on any of those platforms. The final link, however, is called “Yourself.”

Clicking it will prompt you to download and save a file called client.ovpn. This file contains the configuration settings to match the server and the actual keys we’ll use to authenticate. You definitely want to treat this file with care so it doesn’t fall into the wrong hands. That would include not sending it through plain email across unencrypted connections.

I’ll open the file locally and copy the contents. Then, in a shell within a Linux virtual machine running in my local network, I’ll create a new file called client.ovpn and paste the contents in. If you had clicked through to the “OpenVPN for Linux” link in the client UI earlier, you would have seen that the only additional step necessary was to install OpenVPN using the Apt package manager — or Yum if you’re on a CentOS or Red Hat machine. Well that’ll take just one command. When it’s done its job, we’ll be all set.

nano client.ovpnsudo apt updatesudo apt install openvpn

Next we’ll open the VPN connection. As root — using sudo — I’ll type openvpn with the config flag pointing to the client.ovpn configuration file I just created.

sudo openvpn — config client.ovpn

When prompted to authenticate, use the openvpn account along with the password you created for it back on the server.

Now I’ll open a second shell session on my local client so I can try to ssh in to the OpenVPN server using its local IP address — something that would be impossible without a working VPN connection.

First though, run ip a to list all the network interfaces active on this machine.

ip a

Besides your local network, you should also see one called tun0. This interface was created by OpenVPN and will usually lie within the 172.16.x.x range.

I’ll ssh into the remote server using my private key — which, of course, needs to exist locally — and the server’s private IP address. If it works, you’ll have yourself a VPN!

ssh -i KeyPairName.pem [email protected]

Finally, I’ll demonstrate that the VPN, as it’s currently configured, will allow us access to other private resources within our Amazon VPC. This could be useful if, for instance, you’ve got a database instance running in the VPC that you can’t expose to the public network.

I’m going to launch a standard Ubuntu EC2 instance but I won’t give it a public IP. I’ll specify the same us-east-1b subnet we used for the OpenVPN server to keep things simple. The security group I’ll use will permit SSH access through port 22 but nothing else.

Once that’s running, I’ll note its private IP address and head back to my local client. Once I’m sure the instance is fully launched, I’ll ssh in using the same private key, the “ubuntu” username — since that’s the default for normal Ubuntu EC2 instances — and the private address I just copied.

Again. If it works, you’ll have a fully-configured VPN connection into your AWS private resources. Savor the moment.

Don’t forget to shut down all your servers and release your Elastic IP address when you’re done using them. You don’t want to incur costs unnecessarily.

This article was adapted from part of my new Pluralsight course, “Connecting On-prem Resources to your AWS Infrastructure.” There’s lots more where that came from at my Bootstrap IT site, including links to my book, Linux in Action, and a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action.