Wie Sie OpenVPN verwenden können, um sicher auf private AWS-Ressourcen zuzugreifen

Dieser Artikel wurde aus einem Teil meines neuen Pluralsight-Kurses „Verbinden von lokalen Ressourcen mit Ihrer AWS-Infrastruktur“ übernommen.

Müssen Sie manchmal eine Verbindung zu Ressourcen herstellen, die auf Amazon Web Services ausgeführt werden? Der Zugriff auf Ihre öffentlichen EC2-Instanzen mit SSH und die Verschlüsselung Ihrer S3-Daten ist in jeder Hinsicht sicher genug. Aber wie wäre es, in eine Back-End-RDS-Datenbankinstanz zu gelangen oder mit AWS-basierten Daten zu arbeiten, die nicht öffentlich sind? Es gibt viele Gründe, warum Administratoren solche Ressourcen für die breite Öffentlichkeit unzugänglich machen. Aber wenn Sie sie nicht erreichen können, wenn Sie sie brauchen, was nützen sie Ihnen dann wahrscheinlich?

Sie müssen also einen sicheren und zuverlässigen Weg finden, um die ACLs und Sicherheitsgruppen zu umgehen, die Ihre Daten schützen. Eine Lösung, die ich in meinem Kurs „Verbinden von lokalen Ressourcen mit Ihrer AWS-Infrastruktur“ zu Pluralsight behandele, ist Direct Connect. Aber wenn der Preis von Direct Connect ein Budget-Buster für Ihr Unternehmen ist, könnte eine Art VPN-Tunnel den Trick tun.

Was ist ein virtuelles privates Netzwerk?

Virtuelle private Netzwerke (VPNs) werden häufig verwendet, um ansonsten eingeschränkte Netzwerkaktivitäten oder anonymes Surfen zu ermöglichen. Aber darum geht es in diesem Artikel nicht.

Ein VPN ist eine Punkt-zu-Punkt-Verbindung, mit der Sie Daten sicher zwischen zwei Standorten in einem öffentlichen Netzwerk verschieben können. Tatsächlich kann ein Tunnel so konzipiert werden, dass zwei geografisch getrennte private Standorte in einem einzigen privaten Netzwerk zusammengefasst werden. In unserem Kontext würde dies bedeuten, dass Sie Ihr lokales Büronetzwerk mit der AWS VPC verbinden, die Ihre privaten Ressourcen hostet.

Es gibt zwei Möglichkeiten, dies zu tun:

  • Eine verwaltete VPN-Verbindung, die auf einem AWS Virtual Private Gateway basiert
  • Verwenden Sie Ihr eigenes VPN.

Dieser Artikel konzentriert sich auf die Do-it-yourself-Methode.

Der OpenVPN Access Server

Wie der Name schon sagt, ist OpenVPN ein Open-Source-Projekt, und Sie können jederzeit die kostenlose Community-Edition herunterladen und auf Ihrem eigenen VPN-Server einrichten. Das Unternehmen OpenVPN bietet jedoch auch einen speziell entwickelten OpenVPN-Zugriffsserver als EC2-AMI an, der sofort mit AWS-freundlicher Integration und automatisierten Konfigurationstools geliefert wird.

Soweit ich sehen kann, ist das Starten des AMI in Ihrer AWS VPC und das Öffnen für kontrollierte Remoteverbindungen so ziemlich der „richtige“ Weg, um diese Aufgabe zu erledigen.

Was kostet es? Wenn Sie nur Dinge testen und nicht vorhaben, über mehr als zwei Verbindungen gleichzeitig auf das VPN zuzugreifen, ist das AMI selbst kostenlos. Sie sind immer noch am Haken für die regulären Kosten einer EC2-Instanz, aber wenn Ihr Konto weiterhin für die kostenlose Stufe berechtigt ist, können Sie diese auch kostenlos erhalten.

Sobald Sie Ihr VPN in die aktive Produktion versetzt haben, hängt die von Ihnen erworbene Lizenz davon ab, wie viele gleichzeitige Verbindungen Sie benötigen. Diese Seite enthält die Details, die Sie benötigen.

In diesem Handbuch werden wir Folgendes tun:

  • Wählen Sie ein Ubuntu AMI aus, stellen Sie es bereit und starten Sie es, wobei OpenVPN Access Server in meiner VPC vorinstalliert ist
  • Greifen Sie mit SSH auf den Server zu und konfigurieren Sie das VPN
  • Richten Sie einen Administrator ein
  • Richten Sie einen lokalen Computer als OpenVPN-Client ein und stellen Sie eine Verbindung zu einer privaten Instanz in meiner AWS VPC her

Bereit?

Starten eines OpenVPN Access Servers

Starten Sie über das EC2-Dashboard - und stellen Sie sicher, dass wir uns in der richtigen AWS-Region befinden - eine Instanz, die als VPN-Server fungiert. Anstatt eine der Schnellstart-AMIs zu verwenden, klicke ich auf die Registerkarte AWS Marketplace und suche nach "openvpn access server". OpenVPN bietet eine Reihe von offiziellen Images, die an Lizenzen gebunden sind und eine steigende Anzahl verbundener Clients bieten.

Ich werde mit diesem Ubuntu-Image arbeiten, das über eine "Bring Your Own License" -Vereinbarung funktioniert. Wie ich bereits geschrieben habe, benötigen wir für das, was wir tun werden, keine Lizenz.

Durch Auswahl des AMI wird ein Popup geöffnet, in dem angegeben wird, wie viel uns dieses Image pro Stunde bei Verwendung verschiedener Instanztypen und EBS-Speicheroptionen kostet. Dies sind jedoch nur reguläre AWS-Infrastrukturkosten und enthalten keine Lizenzgebühren.

Wenn es um den Instanztyp geht, werde ich ein Downgrade auf ein t2.micro durchführen, um es innerhalb der freien Ebene zu halten. Ein ausgelasteter Produktionsserver benötigt möglicherweise etwas mehr Strom.

Da ich in wenigen Minuten eine zweite Instanz im selben Subnetz starten möchte, wähle ich auf der Seite "Instanzdetails konfigurieren" beispielsweise "us-east-1b" aus und mache mir eine Notiz für später.

Auf der Seite Sicherheitsgruppe leuchten jetzt die OpenVPN AMI-Einstellungen wirklich. Wir erhalten eine Sicherheitsgruppe, die alles öffnet, was wir brauchen. Port 22 ist für den SSH-Verkehr zum Server vorgesehen, 943 ist der Port, über den wir auf die Administrator-GUI zugreifen, 443 ist TLS-verschlüsselter HTTP-Verkehr und OpenVPN wartet auf eingehende Client-Verbindungen auf Port 1194.

Hinweis : Wenn dies praktikabel ist, ist es normalerweise eine gute Idee, diese Regeln zu verschärfen, damit nur Anforderungen aus gültigen IP-Adressbereichen des Unternehmens akzeptiert werden. Dies ist jedoch für kurzfristige Tests in Ordnung.

Von hier aus überprüfe ich meine Einstellungen, bestätige, dass ich den aufgelisteten SSH-Verschlüsselungsschlüssel habe, und drücke den Auslöser.

Sobald die Instanz gestartet ist, werden mir wichtige Anmeldeinformationen angezeigt - einschließlich der Tatsache, dass das Benutzerkonto, das wir für SSH auf dem Server verwenden, openvpnas heißt - und eine Kurzanleitung. Ich erhalte auch eine E-Mail mit Links zu denselben Informationen.

Zurück in der EC2-Instanzkonsole wird unsere öffentliche IP-Adresse angezeigt, während der neue Computer den Startvorgang beendet. Wenn wir die Instanz jemals neu starten müssten, gibt es keine Garantie dafür, dass wir dieselbe IP erneut erhalten, was zu einem angemessenen Chaos führen könnte. Es ist daher eine gute Idee, der Instanz eine elastische IP zuzuweisen.

Dazu klicke ich auf Elastic IPs und dann auf Neue Adresse zuweisen. Notieren Sie die neue Adresse und schließen Sie die Seite. Klicken Sie nun bei ausgewählter Adresse auf Aktionen und dann auf Adresse zuordnen. Ich werde einmal in das Feld Instanz klicken und meine OpenVPN-Instanz - mit ihrem hilfreichen Tag - wird aufgelistet. Ich muss es nur auswählen, auf "Verknüpfen" klicken und fertig. Von nun an ist dies die permanente öffentliche IP für den Zugriff auf unseren Server.

Zugriff auf den Server

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.