Hogyan használhatja az OpenVPN-t a privát AWS-erőforrások biztonságos eléréséhez

Ezt a cikket az új Pluralsight tanfolyamom "On-prem erőforrások csatlakoztatása az AWS infrastruktúrához" részéből adaptáltam.

Néha csatlakoznia kell az Amazon Web Services szolgáltatásain futtatott erőforrásokhoz? SSH használatával a nyilvános EC2 példányokhoz való hozzáférés és az S3 adatok titkosítása minden szempontból elég biztonságos. De mi van azzal, ha bekerül egy háttér-RDS adatbázis-példányba, vagy olyan AWS-alapú adatokkal dolgozik, amelyek nem nyilvánosak? Mindenféle oka van annak, hogy az adminisztrátorok távol tartják az ilyen erőforrásokat a lakosság elől. De ha nem tudsz hozzájuk jutni, amikor szükséged van rá, akkor mire jóak valószínűleg?

Tehát meg kell találnia egy biztonságos és megbízható utat az ACL-ek és a biztonsági csoportok körül, amelyek megvédik a cuccait. Az egyik megoldás, amelyet a Pluralsight „On-prem erőforrások csatlakoztatása az AWS infrastruktúrához” tanfolyamán tárgyalok, a Direct Connect. De ha a Direct Connect árcédulája költségkímélő a vállalat számára, akkor valamilyen VPN-alagút teheti ezt a trükköt.

Mi a virtuális magánhálózat?

A virtuális magánhálózatokat (VPN) gyakran használják az egyébként korlátozott hálózati tevékenység vagy névtelen böngészés engedélyezésére. De ez a cikk nem erről szól.

A VPN egy pont-pont kapcsolat, amely lehetővé teszi az adatok biztonságos mozgatását két hely között egy nyilvános hálózaton keresztül. Valójában egy alagutat úgy lehet kialakítani, hogy két földrajzilag elkülönített magánterületet egyetlen magánhálózatba egyesítsen. Kontextusunkban ez azt jelentené, hogy összekapcsolja a helyi irodai hálózatot az AWS VPC-vel, amely magánforrásait tárolja.

Ennek kétféle módja van:

  • Az AWS Virtual Private Gateway tetejére épített felügyelt VPN-kapcsolat
  • Saját VPN használatával.

Ez a cikk a do it yourself módszerre összpontosít.

Az OpenVPN Access Server

Ahogy a neve is sugallja, az OpenVPN egy nyílt forráskódú projekt, és mindig le tudja tölteni az ingyenes közösségi kiadást, és beállíthatja a dolgokat a saját VPN-kiszolgálóján. De az OpenVPN vállalat egy erre a célra felépített OpenVPN Access Server-t is kínál EC2 AMI-ként, amely AWS-barát integrációval és automatizált konfigurációs eszközökkel kerül a dobozba.

Amit látok, az AMI elindítása az AWS VPC-n belül és megnyitása vezérelt távoli kapcsolatok számára nagyjából a „helyes” módszer lett a munka elvégzésére.

Mennyibe kerül? Ha csak teszteli a dolgokat, és nem tervezi a VPN-hez való hozzáférést egyszerre kettőnél több kapcsolattal, akkor maga az AMI ingyenes. Az EC2 példány szokásos költségeiért továbbra is a horgon áll, de ha fiókja továbbra is jogosult az Ingyenes szintre, akkor ezt ingyen is megszerezheti.

Miután aktiválta a VPN-jét, a megvásárolt licenc attól függ, hogy hány egyidejű kapcsolatra lesz szüksége. Ezen az oldalon megtalálhatók a szükséges adatok.

A következőket tesszük ebben az útmutatóban:

  • Válasszon ki, indítson és indítson egy Ubuntu AMI-t, amelybe előre telepítve van az OpenVPN Access Server a VPC-be
  • SSH használatával érje el a szervert, és konfigurálja a VPN-t
  • Állítson be egy adminisztrátort
  • Állítson be egy helyi gépet OpenVPN-kliensként, és csatlakozzon egy magánpéldányhoz az AWS VPC-n

Kész?

OpenVPN Access Server indítása

Az EC2 irányítópultról - és győződjön meg arról, hogy a megfelelő AWS régióban vagyunk - indítson egy példányt, amely VPN-kiszolgálónkként működik. A Gyors indítás AMI-k helyett az AWS Marketplace fülre kattintok, és az „openvpn hozzáférési kiszolgáló” kifejezésre keresek. Az OpenVPN számos hivatalos képet kínál, amelyek licencekhez vannak kötve, amelyek egyre nagyobb számú összekapcsolt klienst kínálnak.

Megyek ezzel az Ubuntu-képpel, amely a „Hozd a saját licenszed” megállapodáson keresztül működik. Mint korábban írtam, valójában nem lesz szükségünk licencre ahhoz, amit fogunk csinálni.

Az AMI kiválasztásával egy felugró ablak nyílik meg, amely megmondja, mennyibe fog kerülni ez a kép óránként a különféle példánytípusok és az EBS-tárolási lehetőségek használatával. Ezek azonban csak rendszeres AWS infrastrukturális költségek, és nem tartalmazzák a licencdíjakat.

Ha példánytípusról van szó, akkor leminősítek egy t2.mikróra, hogy a szabad rétegben maradjon. Lehet, hogy egy forgalmas gyártókiszolgáló valamivel több energiát igényel.

Mivel néhány perc múlva szeretnék elindítani egy második példányt ugyanabban az alhálózatban, a Példányadatok konfigurálása oldalon kijelölök egy mondatot: „us-east-1b”, és jegyzetet készítek későbbre.

Most a Biztonsági csoport oldalon láthatók az OpenVPN AMI beállításai. Bemutatunk egy biztonsági csoportot, amely mindent megnyit, amire szükségünk lehet. A 22. port a szerver SSH-forgalmát szolgálja, a 943 az a port, amelyet az adminisztrációs grafikus felhasználói felület elérésére használunk, a 443 a TLS-titkosítású HTTP-forgalom, az OpenVPN pedig figyeli a bejövő klienskapcsolatokat az 1194-es porton.

Megjegyzés : Ha praktikus, célszerű szigorítani ezeket a szabályokat, így csak az érvényes vállalati IP-címtartományoktól érkező kéréseket fogadjuk el, de rövid távú tesztelés esetén ez rendben van.

Innen áttekintem a beállításokat, megerősítem, hogy megvan a felsorolt ​​SSH titkosítási kulcs, és meghúzom a ravaszt.

Miután a példány elindult, fontos bejelentkezési információkat jelenítek meg nekem - beleértve azt a tényt, hogy a felhasználói fiókot, amelyet az SSH-hoz fogunk használni a szerverhez, openvpnasnak hívunk -, és egy Gyors útmutató. Kapok egy e-mailt is, amely ugyanarra az információra mutató linkeket tartalmaz.

Visszatérve az EC2 példánykonzolba, miközben az új gép befejezi az indítást, megmutatjuk a nyilvános IP-címünket. Ha valaha is újra kell indítanunk a példányt, nincs garancia arra, hogy ugyanazt az IP-t kapjuk újra, ami ésszerű mértékű káoszt okozhat. Ezért jó ötlet a példányt Elastic IP-hez rendelni.

Ehhez kattintson a Rugalmas IP címek elemre, majd az Új cím kijelölése elemre. Jegyezze fel az új címet, és zárja be az oldalt. Miután kiválasztotta ezt a címet, kattintson a Műveletek és a „Társított cím” elemre. Egyszer rákattintok a Példány mezőben, és az OpenVPN példányom - a hasznos címkével együtt - felsorolásra kerül. Csak ki kell választanom, kattintson a „Társítás” gombra, és kész vagyok. Ezentúl ez lesz az állandó nyilvános IP-cím a szerverünk eléréséhez.

Hozzáférés a szerverhez

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.