Як ви можете використовувати OpenVPN для безпечного доступу до приватних ресурсів AWS

Ця стаття була адаптована до частини мого нового курсу Pluralsight “Підключення локальних ресурсів до вашої інфраструктури AWS”.

Вам іноді потрібно підключатись до ресурсів, які у вас працюють на Amazon Web Services? Доступ до ваших загальнодоступних екземплярів EC2 за допомогою SSH та шифрування даних S3 є, для всіх намірів, достатньо безпечним. Але як щодо потрапляння у внутрішній екземпляр бази даних RDS або роботи з даними на основі AWS, які не є загальнодоступними? Існують всілякі причини, чому адміністратори тримають такі ресурси поза досяжністю широкої громадськості. Але якщо ви не можете дістатись до них, коли вам потрібно, яку користь вони вам можуть зробити?

Тож вам потрібно буде знайти безпечний та надійний спосіб обійти списки контролю доступу та групи безпеки, що захищають ваші речі. Одним із рішень, яке я висвітлюю у своєму курсі “Підключення попередніх ресурсів до вашої інфраструктури AWS” на Pluralsight, є Direct Connect. Але якщо ціна Direct Connect - це збиток бюджету для вашої компанії, тоді якийсь тунель VPN може зробити трюк.

Що таке віртуальна приватна мережа?

Віртуальні приватні мережі (VPN) часто використовуються, щоб дозволити іншу мережеву активність або анонімний перегляд. Але не про це йдеться в цій статті.

VPN - це з'єднання точка-точка, яке дозволяє безпечно переміщувати дані між двома сайтами через загальнодоступну мережу. Фактично, тунель може бути спроектований для об'єднання двох географічно відокремлених приватних сайтів в одну приватну мережу. У нашому контексті це означало б підключення локальної офісної мережі до AWS VPC, що розміщує ваші приватні ресурси.

Це можна зробити двома способами:

  • Керований VPN-з’єднання, побудований поверх віртуального приватного шлюзу AWS
  • Використання власної VPN.

Ця стаття буде зосереджена на методі «зроби сам».

Сервер доступу OpenVPN

Як випливає з назви, OpenVPN - це проект з відкритим кодом, і ви завжди можете завантажити безкоштовну версію спільноти та налаштувати ситуацію на своєму власному сервері VPN. Але компанія OpenVPN також пропонує спеціально створений сервер доступу OpenVPN як EC2 AMI, який виходить з коробки з інтегрованою AWS та автоматизованими засобами конфігурації.

З того, що я бачу, запуск AMI у вашому AWS VPC та відкриття його для контрольованих віддалених з’єднань в значній мірі стало “правильним” способом виконати цю роботу.

Що це коштує? Якщо ви лише тестуєте речі і не плануєте отримувати доступ до VPN, використовуючи більше двох з'єднань одночасно, тоді сам AMI безкоштовний. Ви все одно будете в курсі регулярних витрат на екземпляр EC2, але якщо ваш рахунок все ще має право на безкоштовний рівень, ви можете отримати його і безкоштовно.

Після того, як ви введете свою VPN у активне виробництво, придбана вами ліцензія буде залежати від кількості одночасних з'єднань, які вам знадобляться. На цій сторінці є необхідні дані.

Ось що ми будемо робити в цьому посібнику:

  • Виберіть, надайте та запустіть AMI Ubuntu з попередньо встановленим сервером доступу OpenVPN у мій VPC
  • Доступ до сервера за допомогою SSH та налаштування VPN
  • Налаштування адміністратора
  • Налаштуйте локальну машину як клієнт OpenVPN і підключіться до приватного екземпляра в моєму AWS VPC

Готові?

Запуск сервера доступу OpenVPN

З інформаційної панелі EC2 - і переконавшись, що ми знаходимось у правильному регіоні AWS - запустіть екземпляр, який буде виконувати функції нашого сервера VPN. Замість того, щоб використовувати один із AMI для швидкого запуску, я натисну на вкладку AWS Marketplace і шукаю “сервер доступу openvpn”. OpenVPN надає ряд офіційних зображень, прив'язаних до ліцензій, що пропонують ескалаційну кількість підключених клієнтів.

Я збираюся піти з цим образом Ubuntu, який працює за домовленістю “Принесіть власну ліцензію”. Як я вже писав раніше, насправді нам не потрібна буде ліцензія на те, що ми будемо робити.

Вибір AMI відкриває спливаюче вікно, яке повідомляє нам, скільки коштуватиме це зображення за годину, використовуючи різні типи екземплярів та вибір сховища EBS. Однак це лише регулярні витрати на інфраструктуру AWS, і вони не включають плату за ліцензію.

Що стосується типу екземпляра, я перейду на t2.micro, щоб зберегти його в межах вільного рівня. Зайнятий робочий сервер може зажадати трохи більше енергії.

Оскільки я хочу запустити другий екземпляр у тій самій підмережі за кілька хвилин, я виберу, скажімо, “us-east-1b” на сторінці Налаштування деталей екземпляра та зроблю примітку на потім.

Тепер сторінка групи безпеки - це те місце, де налаштування OpenVPN AMI дійсно сяють. Нам представлена ​​група безпеки, яка відкриває все, що нам потрібно. Порт 22 призначений для SSH-трафіку на сервері, 943 - це порт, який ми будемо використовувати для доступу до адміністраторського графічного інтерфейсу, 443 - зашифрований TLS-трафік HTTP, а OpenVPN буде прослуховувати вхідні підключення клієнта через порт 1194.

Примітка . Якщо це практично, звичайно було б непогано посилити ці правила, тому приймаються лише запити з дійсних діапазонів IP-адрес компанії, але це буде добре для короткострокового тестування.

Звідси я перегляну свої налаштування, підтверджу, що у мене є перелічений ключ шифрування SSH, і натискаю на курок.

Після запуску екземпляра мені буде показана важлива інформація для входу - в тому числі той факт, що обліковий запис користувача, який ми використовуватимемо для SSH на сервері, називається openvpnas - та короткий посібник. Я також отримаю електронний лист із посиланнями на ту саму інформацію.

Ще в консолі екземплярів EC2, поки нова машина закінчує завантаження, нам показують нашу загальнодоступну IP-адресу. Якщо нам коли-небудь доведеться перезавантажити екземпляр, немає гарантії, що ми знову отримаємо той самий IP, що може спричинити розумну хаос. Тож непогано призначати екземпляру еластичний IP.

Для цього я натисну еластичні IP-адреси, а потім виділить нову адресу. Запишіть нову адресу та закрийте сторінку. Тепер, вибравши цю адресу, натисніть Дії та “Приєднати адресу”. Я клацну один раз у полі Екземпляр, і мій екземпляр OpenVPN - з його корисним тегом - буде перелічено. Мені потрібно лише вибрати його, натиснути «Пов’язати», і я закінчив. Відтепер це буде постійний загальнодоступний IP для доступу до нашого сервера.

Доступ до сервера

Я вставлю загальнодоступну IP-адресу в термінал як частину моєї команди SSH, яка викликає пару ключів, яку я встановив для цього екземпляра.

ssh -i KeyPairName.pem [email protected]

Якщо ви отримуєте доступ із комп'ютера Windows або macOS, все може працювати трохи інакше, але документація надасть вам всю необхідну допомогу.

Однак перед тим, як залишити консоль Instance, я виконаю ще одну важливу функцію. Вибравши екземпляр 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 пароль, щоб я міг використовувати його для входу в веб-графічний інтерфейс. Я роблю це як sudo за допомогою команди passwd.

sudo passwd openvpn

Це все, що нам знадобиться на сервері. Тепер я буду використовувати браузер для входу в веб-графічний інтерфейс. Я використовую загальнодоступну 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.