Sådan kan du bruge OpenVPN til sikker adgang til private AWS-ressourcer

Denne artikel blev tilpasset fra en del af mit nye Pluralsight-kursus, "Tilslutning af lokale ressourcer til din AWS-infrastruktur."

Har du nogle gange brug for at oprette forbindelse til ressourcer, du har kørt på Amazon Web Services? Adgang til dine offentlige EC2-forekomster ved hjælp af SSH og kryptering af dine S3-data er under alle omstændigheder sikker nok. Men hvad med at komme ind i en back-end RDS-databaseinstans eller arbejde med AWS-baserede data, der ikke er offentlige? Der er alle mulige grunde til, at administratorer holder sådanne ressourcer utilgængeligt for offentligheden. Men hvis du ikke kan få fat i dem, når du har brug for, hvad godt kan de sandsynligvis gøre dig?

Så du bliver nødt til at finde en sikker og pålidelig måde omkring ACL'er og sikkerhedsgrupper, der beskytter dine ting. En løsning, jeg dækker i mit ”Tilslutning af lokale ressourcer til din AWS-infrastruktur” -kursus på Pluralsight, er Direct Connect. Men hvis Direct Connect's prisskilt er en budget-buster for din virksomhed, så kan en slags VPN-tunnel muligvis gøre tricket.

Hvad er et virtuelt privat netværk?

Virtuelle private netværk (VPN'er) bruges ofte til at tillade ellers begrænset netværksaktivitet eller anonym browsing. Men det er ikke det, denne artikel handler om.

En VPN er en punkt-til-punkt-forbindelse, der giver dig mulighed for at flytte data sikkert mellem to steder på tværs af et offentligt netværk. Effektivt kan en tunnel konstrueres til at kombinere to geografisk adskilte private steder i et enkelt privat netværk. I vores sammenhæng ville det betyde, at du forbinder dit lokale kontornetværk med AWS VPC, der er vært for dine private ressourcer.

Der er to måder at gøre dette på:

  • En administreret VPN-forbindelse bygget oven på en AWS Virtual Private Gateway
  • Brug af din egen VPN.

Denne artikel vil fokusere på gør det selv-metoden.

OpenVPN Access Server

Som navnet antyder, er OpenVPN et open source-projekt, og du er altid i stand til at downloade den gratis community-udgave og indstille tingene på din egen VPN-server. Men OpenVPN-firmaet leverer også en specialbygget OpenVPN Access Server som en EC2 AMI, der kommer ud af kassen med AWS-venlig integration og automatiserede konfigurationsværktøjer.

Fra hvad jeg kan se, er lanceringen af ​​AMI i din AWS VPC og åbning af den for kontrollerede fjernforbindelser stort set blevet den "rigtige" måde at få dette job ud.

Hvad koster det? Hvis du kun tester ting ud og ikke planlægger at få adgang til VPN ved hjælp af mere end to forbindelser ad gangen, er AMI i sig selv gratis. Du vil stadig være på krogen for de almindelige omkostninger ved en EC2-forekomst, men hvis din konto stadig er berettiget til det gratis niveau, kan du også få det gratis.

Når du har sat din VPN i aktiv produktion, afhænger den licens, du køber, af hvor mange samtidige forbindelser du har brug for. Denne side har de detaljer, du har brug for.

Her er hvad vi skal gøre i denne vejledning:

  • Vælg, klargør og start en Ubuntu AMI med OpenVPN Access Server forudinstalleret i min VPC
  • Få adgang til serveren ved hjælp af SSH og konfigurer VPN
  • Opret en administratorbruger
  • Opret en lokal maskine som en OpenVPN-klient, og opret forbindelse til en privat forekomst i min AWS VPC

Parat?

Lancering af en OpenVPN Access Server

Fra EC2-dashboardet - og sørg for, at vi er i den rigtige AWS-region - start en instans for at fungere som vores VPN-server. I stedet for at bruge en af ​​hurtigstart-AMI'erne, skal jeg klikke på fanen AWS Marketplace og søge efter "openvpn-adgangsserver". OpenVPN leverer et antal officielle billeder, der er bundet til licenser, der tilbyder stigende antal forbundne klienter.

Jeg vil gå med dette Ubuntu-billede, der fungerer gennem et "Bring Your Own License" -arrangement. Som jeg skrev tidligere, behøver vi faktisk ikke en licens til det, vi skal gøre.

Valg af AMI åbner en popup, der fortæller os, hvor meget dette billede vil koste os i timen ved hjælp af forskellige instanstyper og EBS-lagringsvalg. Disse er dog kun regelmæssige AWS-infrastrukturomkostninger og inkluderer ikke licensgebyrer.

Når det kommer til forekomsttype, nedgraderes jeg til en t2.micro for at holde den inden for det gratis niveau. En travl produktionsserver kan kræve lidt mere strøm.

Fordi jeg vil starte en anden forekomst i det samme undernet om et par minutter, vælger jeg, siger "us-east-1b" fra siden Konfigurer instansdetaljer, og laver en note til senere.

Nu er sikkerhedsgruppens side, hvor OpenVPN AMI-indstillingerne virkelig skinner. Vi præsenteres for en sikkerhedsgruppe, der åbner alt, hvad vi har brug for. Port 22 er til SSH-trafik til serveren, 943 er den port, vi bruger til at få adgang til admin GUI, 443 er TLS-krypteret HTTP-trafik, og OpenVPN vil lytte efter indgående klientforbindelser på port 1194.

Bemærk : Hvis det er praktisk, ville det normalt være en god ide at stramme disse regler, så kun anmodninger fra gyldige IP-adresseintervaller for virksomheder accepteres, men dette vil være fint til kortvarig test.

Herfra gennemgår jeg mine indstillinger, bekræfter at jeg har den anførte SSH-krypteringsnøgle og trækker udløseren.

Når forekomsten er startet, får jeg vist vigtige loginoplysninger - herunder det faktum, at den brugerkonto, vi bruger til SSH til serveren, kaldes openvpnas - og en hurtig startvejledning. Jeg modtager også en e-mail, der indeholder links til de samme oplysninger.

Tilbage i EC2-forekomsten, mens den nye maskine er startet, får vi vist vores offentlige IP-adresse. Hvis vi nogensinde har brug for at genstarte forekomsten, er der ingen garanti for, at vi får den samme IP igen, hvilket kan forårsage en rimelig mængde kaos. Så det er en god ide at tildele forekomsten en elastisk IP.

For at gøre det skal jeg klikke på elastiske IP'er og derefter tildele ny adresse. Bemærk den nye adresse, og luk siden. Nu, med den valgte adresse, skal du klikke på Handlinger og “Tilknyt adresse”. Jeg klikker en gang i boksen Forekomst, og min OpenVPN-forekomst - med sit nyttige mærke - vises. Jeg behøver kun at vælge det, klik på "Associer" og jeg er færdig. Fra nu af vil det være den permanente offentlige IP til at få adgang til vores server.

Adgang til serveren

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.

Denne artikel blev tilpasset fra en del af mit nye Pluralsight-kursus, "Tilslutning af lokale ressourcer til din AWS-infrastruktur." Der er meget mere, hvor det kom fra på mit Bootstrap IT-websted, herunder links til min bog, Linux in Action, og et hybridkursus kaldet Linux in Motion, der består af mere end to timers video og omkring 40% af Linux-teksten i aktion.