Как можете да използвате OpenVPN за безопасен достъп до частни ресурси на AWS

Тази статия е адаптирана от част от новия ми курс по Pluralsight „Свързване на местни ресурси към вашата AWS инфраструктура“.

Понякога трябва ли да се свържете с ресурси, които сте използвали в Amazon Web Services? Достъпът до вашите публични екземпляри на EC2 чрез SSH и криптирането на вашите S3 данни е достатъчно сигурен за всички намерения и цели. Но какво да кажем за влизане в екземпляр от база данни на RDS или работа с данни, базирани на AWS, които не са публични? Има всякакви причини, поради които администраторите държат такива ресурси извън обсега на широката публика. Но ако не можете да се справите с тях, когато имате нужда, каква полза ще ви направят?

Така че ще трябва да намерите безопасен и надежден начин да заобиколите ACL и групите за сигурност, които защитават вашите неща. Едно решение, което обхващам в моя курс „Свързване на местни ресурси към вашата AWS инфраструктура“ на Pluralsight, е Direct Connect. Но ако ценовият етикет на Direct Connect е бюджетен за вашата компания, тогава някакъв VPN тунел може да свърши работа.

Какво е виртуална частна мрежа?

Виртуалните частни мрежи (VPN) често се използват, за да позволят иначе ограничена мрежова активност или анонимно сърфиране. Но не за това става въпрос в тази статия.

VPN е връзка от точка до точка, която ви позволява да премествате данни сигурно между два сайта в обществена мрежа. На практика тунел може да бъде проектиран да комбинира два географски разделени частни сайта в една частна мрежа. В нашия контекст това би означавало да свържете вашата локална офис мрежа с AWS VPC, която хоства вашите частни ресурси.

Има два начина да направите това:

  • Управлявана VPN връзка, изградена върху AWS Virtual Private Gateway
  • Използване на вашата собствена VPN.

Тази статия ще се фокусира върху метода направи си сам.

Сървърът за достъп на OpenVPN

Както подсказва името, OpenVPN е проект с отворен код и винаги можете да изтеглите безплатното издание на общността и да настроите нещата на вашия собствен VPN сървър. Но компанията OpenVPN предлага и специално изграден сървър за достъп OpenVPN като EC2 AMI, който се предлага от AWS-приятелска интеграция и автоматизирани инструменти за конфигуриране.

От това, което виждам, стартирането на AMI във вашия AWS VPC и отварянето му за контролирани отдалечени връзки почти се превърна в „правилния“ начин да свършите тази работа.

Колко струва? Ако тествате само нещата и не планирате да осъществявате достъп до VPN, като използвате повече от две връзки едновременно, тогава самият AMI е безплатен. Все още ще ви интересуват редовните разходи за екземпляр EC2, но ако акаунтът ви все още отговаря на условията за безплатния ред, тогава можете да го получите и безплатно.

След като включите вашата VPN в активна продукция, закупеният от вас лиценз ще зависи от това колко едновременни връзки ще ви трябват. Тази страница съдържа подробностите, от които се нуждаете.

Ето какво ще направим в това ръководство:

  • Изберете, осигурете и стартирайте Ubuntu AMI с предварително инсталиран OpenVPN Access Server в моя VPC
  • Достъп до сървъра чрез SSH и конфигуриране на VPN
  • Настройте потребител на администратор
  • Настройте локална машина като клиент на OpenVPN и се свържете с частен екземпляр в моя AWS VPC

Готов?

Стартиране на OpenVPN сървър за достъп

От таблото за управление EC2 - и се уверете, че сме в правилния AWS регион - стартирайте екземпляр, който да действа като наш VPN сървър. Вместо да използвам един от AMI за бърз старт, ще щракна върху раздела AWS Marketplace и ще потърся „сървър за достъп openvpn“. OpenVPN предоставя редица официални изображения, които са обвързани с лицензи, предлагащи ескалиращ брой свързани клиенти.

Ще отида с този образ на Ubuntu, който работи чрез споразумение „Донесете си собствен лиценз“. Както писах по-рано, всъщност няма да имаме нужда от лиценз за това, което ще правим.

Избирането на AMI отваря изскачащ прозорец, който ни казва колко ще ни струва това изображение на час, използвайки различни типове екземпляри и избор на EBS за съхранение. Това са само редовни разходи за инфраструктура на AWS и не включват лицензионни такси.

Що се отнася до типа екземпляр, ще понижа до t2.micro, за да го запазя в рамките на безплатния слой. Зает производствен сървър може да изисква малко повече енергия.

Тъй като ще искам да стартирам втори екземпляр в същата подмрежа след няколко минути, ще избера, да речем, „us-east-1b“ от страницата Configure Instance Details и ще направя бележка за по-късно.

Сега страницата на Групата за сигурност е мястото, където настройките на OpenVPN AMI наистина блестят. Представена ни е група за сигурност, която отваря всичко, от което се нуждаем. Порт 22 е за SSH трафик към сървъра, 943 е портът, който ще използваме за достъп до администраторския GUI, 443 е криптиран с TLS HTTP трафик, а OpenVPN ще слуша за входящи клиентски връзки на порт 1194.

Забележка : Ако е практично, обикновено би било добра идея да се затегнат тези правила, така че се приемат само заявки от валидни диапазони на IP адреси на компанията, но това ще бъде добре за краткосрочно тестване.

От тук ще прегледам настройките си, ще потвърдя, че имам изброения SSH ключ за криптиране и натискам спусъка.

След като екземплярът бъде стартиран, ще ми бъде показана важна информация за влизане - включително факта, че потребителският акаунт, който ще използваме за SSH в сървъра, се нарича openvpnas - и ръководство за бързо стартиране. Ще получа и имейл, съдържащ връзки към същата информация.

Обратно в конзолата за екземпляри EC2, докато новата машина завърши зареждането, ни се показва нашият публичен IP адрес. Ако някога се наложи да рестартираме екземпляра, няма гаранция, че ще получим същия IP отново, което може да причини разумно количество хаос. Така че е добра идея да зададете на екземпляра еластичен IP.

За целта ще щракна върху Еластични IP адреси и след това ще разпредели нов адрес. Запишете новия адрес и затворете страницата. Сега, когато този адрес е избран, щракнете върху Действия и „Свържете адрес“. Щракнете веднъж в полето Instance и моят екземпляр OpenVPN - с неговия полезен таг - е изброен. Трябва само да го избера, щракнете върху „Сътрудник“ и приключих. Отсега нататък това ще бъде постоянният публичен IP за достъп до нашия сървър.

Достъп до сървъра

Ще поставя публичния IP адрес в терминала като част от моята SSH команда, която извиква двойката ключове, която зададох за този екземпляр.

ssh -i KeyPairName.pem [email protected]

Ако имате достъп от машина с Windows или macOS, нещата може да работят малко по-различно, но документацията ще ви даде цялата помощ, от която се нуждаете.

Преди да напусна конзолата на Instances обаче, ще изпълня още една важна функция. С избрания екземпляр на OpenVPN щракнете върху Действия и след това в мрежа и след това „Промяна на източника / целевата проверка“. Ще се уверя, че проверката е деактивирана. Нищо особено няма да бъде възможно, ако не направя това.

Сега към моята SSH сесия. Веднага щом започне, се сблъсквам с лицензионното споразумение за OpenVPN EULA и след това съветника за настройка. Ако трябва да промените настройка по-късно, винаги можете да стартирате отново съветника, като използвате тази команда:

sudo ovpn-init — ec2.

Повечето от настройките по подразбиране на съветника ще работят добре, но си струва бързо да обясните какво се случва. Ето въпросите и някои цветни коментари, когато е необходимо:

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.]

Когато съветникът завърши, ми се показва информация за връзката и се съветва да инсталирам демона за мрежово време NTP. Това няма да е необходимо в това поле на Ubuntu, тъй като вече е инсталирано и работи по подразбиране.

Както споменах по-рано, ще трябва да дам на потребителя на openvpn парола, за да мога да я използвам за влизане в уеб GUI. Правя това като sudo с командата passwd.

sudo passwd openvpn

Това са всички неща от сървъра, от които ще се нуждаем. Сега ще използвам браузър, за да вляза в уеб GUI. Използвам публичния IP адрес на нашия сървър с защитен префикс https, последван от наклонена черта и администратор.

///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.