Ovaj je članak adaptiran iz dijela mog novog tečaja Pluralsight, „Povezivanje lokalnih resursa s vašom AWS infrastrukturom“.
Trebate li se ponekad povezati s resursima koje imate na Amazon Web Services? Pristup vašim javnim EC2 instancama pomoću SSH-a i šifriranje vaših S3 podataka je, za sve namjere i svrhe, dovoljno sigurno. Ali što je s ulaskom u back-end instancu RDS baze podataka ili radom s podacima koji se temelje na AWS-u i nisu javni? Postoje sve vrste razloga zašto administratori drže takve resurse nedostupnima široj javnosti. Ali ako ne možete doći do njih kad zatrebate, što će vam oni vjerojatno učiniti?
Stoga ćete morati pronaći siguran i pouzdan način zaobilaženja ACL-ova i sigurnosnih grupa koje štite vaše stvari. Jedno od rješenja koje pokrivam u tečaju "Povezivanje lokalnih resursa s vašom AWS infrastrukturom" na Pluralsightu je Direct Connect. Ali ako je cijena Direct Direct-a proračun za vašu tvrtku, tada bi nekakav VPN tunel mogao učiniti trik.
Što je virtualna privatna mreža?
Virtualne privatne mreže (VPN) često se koriste za omogućavanje inače ograničenih mrežnih aktivnosti ili anonimno pregledavanje. Ali o tome nije riječ u ovom članku.
VPN je veza od točke do točke koja vam omogućuje sigurno premještanje podataka između dviju web lokacija putem javne mreže. Učinkovito, tunel se može dizajnirati za kombiniranje dvaju geografski odvojenih privatnih mjesta u jednu privatnu mrežu. U našem kontekstu to bi značilo povezivanje vaše lokalne uredske mreže s AWS VPC-om koji je domaćin vašim privatnim resursima.
Postoje dva načina za to:
- Upravljana VPN veza izgrađena na vrhu AWS virtualnog privatnog prolaza
- Korištenje vlastitog VPN-a.
Ovaj će se članak usredotočiti na metodu uradi sam.
Pristupni poslužitelj OpenVPN
Kao što i samo ime govori, OpenVPN je projekt otvorenog koda i uvijek možete preuzeti besplatno izdanje zajednice i postaviti stvari na svoj vlastiti VPN poslužitelj. No, tvrtka OpenVPN također nudi namjenski izgrađeni OpenVPN pristupni poslužitelj kao EC2 AMI koji se isporučuje s integriranim AWS i alatima za automatiziranu konfiguraciju.
Koliko vidim, pokretanje AMI-a unutar vašeg AWS VPC-a i otvaranje za kontrolirane daljinske veze postalo je prilično „pravi“ način za obavljanje ovog posla.
Koliko košta? Ako stvari samo testirate i ne planirate pristupiti VPN-u koristeći više od dvije veze odjednom, tada je sam AMI besplatan. I dalje ćete biti u prilici za redovne troškove EC2 instance, ali ako vaš račun još uvijek ispunjava uvjete za besplatni nivo, tada to možete dobiti i besplatno.
Jednom kada svoj VPN stavite u aktivnu proizvodnju, licenca koju kupite ovisit će o tome koliko će vam istodobnih veza trebati. Ova stranica sadrži detalje koji će vam trebati.
Evo što ćemo učiniti u ovom vodiču:
- Odaberite, omogućite i pokrenite Ubuntu AMI s OpenVPN pristupnim poslužiteljem unaprijed instaliranim u moj VPC
- Pristupite poslužitelju koristeći SSH i konfigurirajte VPN
- Postavite administratora
- Postavite lokalni stroj kao OpenVPN klijent i povežite se s privatnom instancom u mom AWS VPC-u
Spreman?
Pokretanje OpenVPN pristupnog poslužitelja
S nadzorne ploče EC2 - i osiguravajući da se nalazimo u ispravnoj AWS regiji - pokrenite instancu koja će djelovati kao naš VPN poslužitelj. Umjesto da koristim jedan od AMI-ja za brzi početak, ja ću kliknuti karticu AWS Marketplace i potražiti "openvpn pristupni poslužitelj". OpenVPN pruža brojne službene slike povezane s licencama koje nude povećan broj povezanih klijenata.
Idem s ovom Ubuntu slikom koja funkcionira kroz aranžman "Donesite vlastitu licencu". Kao što sam ranije napisao, zapravo nam neće trebati licenca za ono što ćemo raditi.
Odabirom AMI-ja otvara se skočni prozor koji nam govori koliko će nas ova slika koštati po satu koristeći razne vrste instanci i izbore EBS pohrane. To su međutim redovni troškovi infrastrukture AWS-a i ne uključuju naknade za licencu.
Kada je riječ o tipu instance, prebacit ću se na t2.micro kako bi ga zadržao u okviru besplatne razine. Zauzet proizvodni poslužitelj možda će trebati malo više energije.
Budući da ću za nekoliko minuta poželjeti pokrenuti drugu instancu u istoj podmreži, na stranici Konfiguriranje detalja instance ću odabrati, recimo, "us-east-1b" i zabilježiti za kasnije.
Stranica Security Group sada je mjesto na kojem OpenVPN AMI postavke zaista sjaje. Predstavljamo vam sigurnosnu grupu koja otvara sve što trebamo. Port 22 je za SSH promet na poslužitelj, 943 je port koji ćemo koristiti za pristup administratorskom GUI-u, 443 je TLS-šifrirani HTTP promet, a OpenVPN će slušati dolazne veze klijenta na portu 1194.
Napomena : Ako je praktično, bilo bi dobro pooštriti ta pravila pa se prihvaćaju samo zahtjevi iz valjanih raspona IP adresa tvrtke, ali to će biti u redu za kratkotrajno testiranje.
Odavde ću pregledati svoje postavke, potvrditi da imam navedeni SSH ključ za šifriranje i povući okidač.
Kad se instanca pokrene, prikazat će mi se važni podaci za prijavu - uključujući činjenicu da se korisnički račun koji ćemo koristiti za SSH na poslužitelj naziva openvpnas - i brzi vodič. Također ću primiti e-poštu s vezama do istih podataka.
Natrag u konzoli instanci EC2, dok se novi stroj završava s dizanjem, prikazana nam je naša javna IP adresa. Ako bismo ikada trebali ponovno pokrenuti instancu, ne postoji jamstvo da ćemo ponovno dobiti isti IP, što bi moglo prouzročiti razumnu količinu haosa. Stoga je dobro instanci dodijeliti elastični IP.
Da bih to učinio, kliknite Elastične IP adrese, a zatim Dodijeli novu adresu. Zabilježite novu adresu i zatvorite stranicu. Sada, s odabranom adresom, kliknite Akcije i "Pridruži adresu". Kliknut ću jednom u okvir Instance i navedena je moja instanca OpenVPN - s korisnom oznakom. Trebam ga samo odabrati, kliknuti “Associate” i gotov sam. Od sada će to biti trajna javna IP adresa za pristup našem poslužitelju.
Pristup poslužitelju
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 openvpnas@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 openvpnThat’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.
///adminYou’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 openvpnNext 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.ovpnWhen 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 aBesides 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 openvpnas@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.