What Is Amazon Linux 2?
To help its customers take full advantage of its cloud offering, the company created its own Linux server operating system, called Amazon Linux. Based on Red Hat Enterprise Linux (RHEL), Amazon Linux stands out thanks to its tight integration with many Amazon Web Services (AWS) services, long-term support, and a compiler, build toolchain, and LTS Kernel tuned for better performance on Amazon EC2.
In December 2017, Amazon announced the second version of its Linux operating system: Amazon Linux 2. Just like its predecessor, Amazon Linux 2 will be supported for 5 years with security and maintenance updates, until June 30, 2023.
Meet Amazon Linux 2
Amazon has many customers around the world whose applications and infrastructure live entirely on its cloud servers. For such customers, it makes a lot of sense to use an operating system that has been designed to easily integrate with Amazon’s cloud-computing platform and squeeze out every ounce of performance out of it.
Stable Bleeding Edge
With Amazon Linux 2, customers also get to enjoy two benefits that don’t often go together: long-term support and access to the latest versions of popular software packages. Long-term support applies to core packages (whose full list can be found on the Amazon Linux 2 FAQ page). Amazon promises to provide security updates and bug fixes for 5 years.
One important caveat is that Amazon Linux 2 doesn’t maintain kernel-space ABI compatibility, so changes in the upstream Linux kernel that break ABI stability, then any applications that rely on third-party kernel drivers may require additional modifications.
At the time of writing, the default kernel in Amazon Linux 2, which receives long-term support from Amazon, is Linux Kernel 4.14. Users can, however, easily upgrade to an AWS-optimized Linux Kernel 4.19 by installing it from the Extras catalog, a repository of bleeding-edge software, including kernels, runtimes, toolchains, databases, web stacks, and more.
Installing the Linux Kernel 4.19 is a matter of one simple command:
Other available software in the Extras catalog can be listed using the following command:
On-Premises Development and Testing
It probably won’t surprise you that Amazon Linux 2 is available as an Amazon Machine Image (AMI) for use on Amazon Elastic Compute Cloud (AmazonEC2) and as a Docker container image compatible with Amazon Elastic Container Service (Amazon ECS).
What may surprise you is that you can also download virtual machine images for VMware, Oracle VM VirtualBox, and Microsoft Hyper-V virtualization solutions for on-premises software development and testing.
To get Amazon Linux 2 running on a local machine, all you need to do is prepare a boot image with initial configuration information, download the Amazon Linux 2 virtual machine image for your virtualization platform of choice, and boot to your new VM. The first step is also the only one that requires users to consult the Amazon Linux 2 user guide.
From SysVinit to systemd
The previous version of Amazon Linux relied on SysVinit to bootstrap the Linux user space and manage system processes afterward.
While simple and compact, SysVinit wasn’t designed to meet the needs of modern users and start the large number of processes users have come to rely on over the years. Furthermore, SysVinit starts processes serially, which means that it has to wait for each process to load before it can start loading the next process. Configuring the load order of processes is a lot of work and not a whole lot of fun.
Systemd provides a dependency-based init system capable of bootstrapping the Linux user space in parallel. This leads to significant performance improvements over SysVinit. Systemd also includes features like on-demand starting of daemons, snapshot support, process tracking, and Inhibitor Locks that make it a suite of basic building blocks for a Linux system.
Security First
Amazon Linux 2 limits exposure to security vulnerabilities by reducing the number of non-critical packages which are installed on an instance. Amazon Linux 2 yum repositories serve as the primary channel for delivering security updates, but security updates also reach users via updated Amazon Machine Images (AMIs) and VM and container images.
All security events are listed in the Amazon Linux AMI Security Center, which also provides a handy RSS feed. Users who would like to further boost their cyber defenses can take advantage of the hundreds of security solutions available on the AWS Marketplace, including Trend Micro Deep Security.
“Trend Micro loves Linux because our customers love Linux. Linux is truly a first-class citizen at Trend Micro and our launch support for AL2 another example of our commitment to protecting our customers’ evolving workloads,” stated Trend Micro on its website. “Whether you’re running your AL2 in AWS, on virtual servers or in containers, Deep Security delivers layered protection for your hybrid environment.”
Premium customer support options are available through subscriptions to AWS Support, but they don’t cover the on-premises use of Amazon Linux 2, which sets them apart from similar subscription options offered by Red Hat.
Conclusion
When it comes to running Linux workloads on AWS, Amazon Linux 2 is an easy choice. Combining long-term support with convenient access to bleeding-edge software, this RHEL-based Linux distribution provides a convenient entry-point into the world of Amazon Web Services and the infinite possibilities that come with it.
About the author
David Morelo
David Morelo is a professional content writer in the technology niche, covering everything from consumer products to emerging technologies and their cross-industry application
Amazon Linux 2
Amazon Linux 2 is a Linux operating system from Amazon Web Services (AWS). It provides a security-focused, stable, and high-performance execution environment to develop and run cloud applications. Amazon Linux 2 is provided at no additional charge. AWS provides ongoing security and maintenance updates for Amazon Linux 2.
Benefits
Optimized performance
Amazon Linux 2 includes support for the latest Amazon EC2 instance capabilities and is tuned for enhanced performance. It includes packages that help ease integration with other AWS Services.
Enhanced developer productivity
Amazon Linux 2 is offered as a virtual machine and container image for on-premises development and testing. Developers can speed up their application development by building, testing, and integrating on the same Linux distribution that is used in their production environment.
Peace of mind with long term support
Amazon Linux 2 offers long-term support. Developers, IT administrators, and ISVs get the predictability and stability of a Long Term Support (LTS) release, but without compromising access to the latest versions of popular software packages.
Large Partner ecosystem
Amazon Linux 2 has a rapidly growing community of Technology Partners that includes Independent Software Vendors (ISVs). You can install and run many popular partner applications.
Pricing
Amazon Linux 2 is provided at no additional charge. Standard Amazon EC2 and AWS charges apply for running Amazon EC2 instances and other services.
Sorry, you have been blocked
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
Cloudflare Ray ID: 7d99ecd3adc02d7f • Your IP: Click to reveal 88.135.219.175 • Performance & security by Cloudflare
Я оглянулся посмотреть не оглянулась ли она — 2 или сам себе датацентр через AWS
Публикуем любые сервисы, расположенные в домашнем гипервизоре через сервис EC2 Amazon Web Services через бесплатный инстанс под Amazon Linux AMI 2018 с помощью libreswan, xl2tpd и с небольшой толикой извращения…
У системных администраторов традиционного (не ИТ) бизнеса со стажем обычно через некоторое время дома появляется собственная серверная ферма виртуализации для теста кучи решений на «земле». Это может быть банальная имитация распределенной офисно-филиальной сети, тестирование комплексной инфраструктуры высокой доступности, развертывание новых версий каких-то решений и т.д.
Внешне это может выглядеть от простого прокаченного по памяти домашнего ПК с встроенным в ОС гипервизором и NAS-ом потребительского класса в качестве iSCSI хранилища (или вообще в виде простой виртуалки на том же ПК) до полноценных малоюнитовых стоечных серверов, купленных за недорого как списанные БУ с родословной из западных датацентров, с такими же БУ цисками для связности сети и воткнутых в Fibre Channel такого же, купленного на вторичном рынке NAS-а, но уже бизнес-класса.
Конечно, в наш век повального увлечения облаками всю инфраструктуру с легкостью можно развернуть в облачных дата-центрах, но это все же не всегда возможно, в первую очередь из-за стоимости. Не беда, если для тестов требуется несколько легковесных виртуальных машин из доступных планов, но что если по долгу службы приходится крутить уже несколько десятков или даже сотен отдельных «виртуалок» с самыми разнообразными сервисами, а еще хочется иметь архив, чтобы в любой момент под рукой был образец, что крутил в конфигах/настройках год назад. Или есть необходимость перед переводом части существующих бизнес-сервисов в тот же MS Azure вначале обкатать все подводные камни с той же синхронизацией между ADDS и ADFS.
Основной проблемой в этом случае является публикация (проброс) всей этой инфраструктуры наружу, чтобы можно было отрабатывать подключение пользователей снаружи к домашней «серверной площадке» или к собственным «облачным» сервисам, или интеграцию со сторонними сервисами etc.
Хорошо, если домашнее подключение оформлено на бизнес-тариф, в этом случае с входящими запросами нет проблем, да и IP адрес практически всегда «белый», статический.
Но что делать, когда в месте проживания присутствует обычный «домашний» провайдер, который вдобавок может предоставить только адрес из Private network. Либо даст белый адрес, но традиционно зарубит все входящие из привилегированного (<1024) диапазона портов? Либо вы банально бедный студент и просто не можете себе ежемесячно позволить тариф, предназначенный для юридических лиц. Либо вам приходится частенько менять место жительства, таская свои виртуальные серверные «пожитки» на горбу? Частным также является случай, актуальный для проживающих вне СНГ, когда провайдер принудительно предоставляет собственное оборудование для подключения к Интернету и там вы просто физически не можете настроить проброс снаружи к домашней виртуальной ферме нужных вам портов.
Одним из решений является использование любого из сторонних VPN сервисов. К сожалению, мало какие из них допускают разрешение входящих по отношению к туннелю подключений, чаще всего это отдельная платная услуга. Также в этом случае будет весьма ограниченным выбор внешних IP адресов, если захочется оттестировать ситуацию с присутствием внешнего IP адреса в какой-то конкретной стране, к тому же как правило нет никакой гарантии, что одновременно на этом адресе не висят еще куча других клиентов VPN сервиса, либо он будет статическим на протяжении длительного времени, что важно для настройки записей субдоменов сервисов в DNS.
Также из достойных (ИМХО), хотя и несколько извращенных способов является развертывание собственного «виртуального» роутера на какой-либо внешней облачной площадке с возможностью настроить VPN тоннель из фермы домашнего гипервизора на эту виртуалку в облаке, с пробросом нужных входящих подключений с внешнего сетевого интерфейса облака в сервисы домашнего гипервизора. А в идеале чтобы еще и вообще за все это дело почти ничего не платить.
Потеряв недавно работу, а вместе с ней и доступ к теплой и уютной корпоративной тестовой ферме, но взамен получив море свободного времени для актуализации своих навыков, я решил дать возможность сервисам из домашнего гипервизора увидеть входящие клиентские подключения.
Автор сих строк «любит всяческие инфраструктурные извращения», поэтому в качестве виртуального роутера мы будем использовать бесплатный Amazon Web Services (AWS) EC2 инстанс t2.micro под Linux, что вместо AWS:VPC (в теории) придаст немного больше гибкости в отладке и возможностях, а топология этого VPN-изврата показана ниже:
Что мы тут видим?
Есть бесплатная (750 часов работы в месяц в течении года) виртуальная машина (инстанс), на Linux, развернутая в AWS:EC2. Входящие обращения от неких пользователей ваших домашних сервисов падают на внешний белый IPv4 адрес Elastic IP, затем через входящие (Inbound) правила в «Security Groups» нужные нам порты мапятся внутрь на сетевой интерфейс инстанса, затем пакеты этих запросов через iptables едут через IPSec туннель в виртуальную машину под Windows 2016, где уже с помощью маршрутизации в RRAS попадают к нужному сервису внутри домашней виртуальной фермы. Особо обратим внимание на наличие сразу трех NAT-ов: одного в AWS Linux, одного на маршрутизаторе «офисной сети» и еще одного, неявного, на домашнем роутере.
В данном (моем) случае виртуальная машина под Windows Server 2016 играет роль маршрутизатора для имитации офисной сети и ее серверной площадки, на ней развернуты MS WAP в связке с отдельной машиной с MS ADFS и прочая, поэтому не проблема заменить ее на любую другую операционку или даже домашнюю железку по вкусу. С Windows RRAS кстати наоборот все усложняется, по ходу дела пришлось бороть разные неприятные моменты (о которых ниже), так что если вам выбор в качестве маршрутизатора MS Windows Server претит, то с другой операционной системой возможно будет проще.
Вначале создадим себе аккаунт на AWS, если вдруг у вас его до сих пор нет. С созданием самого аккаунта проблем никаких, потребуется лишь указать данные своей пластиковой карты, с которой спишется (и затем вернется) 1 USD в качестве проверки.
Здесь нужно упомянуть только два момента:
- Обязательно зайдите в сервис AWS:IAM (Identity and Access Management) и включите MFA (Multi-Factor Authentication) для своего нового аккаунта, а еще лучше как рекомендует AWS — создайте отдельную учетную запись также с MFA и с ограничением соответствующих прав и впредь работайте через нее. В противном случае можно попасть в неприятную ситуацию, когда какой-нибудь троянец украдет с вашего ПК учетные данные к AWS и например, кто-то намайнит от души за ваш счет на дорогих высокопроизводительных инстанс-планах…
- Из практических соображений рекомендовано настроить оповещение о превышении бюджета. Делается это в настройках учетной записи, соответствующий пункт меню называется «Billing & Cost Management Dashboard». В открывшейся панели выбираем слева пункт «Budgets» и настраиваем с помощью встроенного мастера планируемый месячный бюджет по вкусу. Не забываем там же настроить оповещение (alert): при превышении указанной суммы вам тут-же придет сообщение. Это полезно, если раньше вы не работали с AWS и боитесь нечаянно «попасть» на круглую сумму в ходе своих экспериментов.
Одним из самых важных шагов – выбираем регион (по сути дата центр) AWS, в котором будет мы хотим развернуть нашу виртуальную машину. Место размещения будет напрямую влиять на географическое положение вашего «виртуального роутера», а значит и на сетевую задержку при работе с ним. Это важно, т.к. live-миграции между регионами в AWS не предусмотрено (встроенный AWS Server Migration Service умеет только в миграцию чего-то-там в само облако AWS) и в случае ошибки с размещением проще пересоздать новый инстанс заново в нужной локации. Альтернативно придется снимать с инстанса образ (Image, встроенными средствами EC2) в AWS:S3 (сервис хранения) и уже оттуда подтягивать этот образ в EC2 инстанс в новом регионе. В моем случае изначально был выбран регион Frankfurt:
Создаем новый инстанс, выбираем слева опцию «Free tier only», что ограничит предлагаемый перечень образов только бесплатными. Я выбрал «Amazon Linux AMI 2018» (подробнее про дистрибутивы Linux в AWS), т.к. на «Amazon Linux 2 AMI» из-за особенностей собранного Амазоном ядра не работает нормально xl2tpd.
Вы можете выбрать любой другой привычный для вас образ Linux-а из предлагаемого списка. Также можно здесь же углубиться в AWS Marketplace и поискать альтернативные образы там, только внимательно читайте комментарии о стоимости: сам образ и вычислительные ресурсы могут быть бесплатными, но отдельно придется доплатить за дисковое пространство и т.п.
Выбираем предлагаемый тип «t2.micro», он предусматривает 1 vCPU, 1 GB памяти, 8-30 GB (SSD/Magnetic) дискового пространства и 750 часов работы бесплатно каждый месяц в течении года. Вполне хватит для нашего «виртуального роутера». Стоит отметить, что бесплатное дисковое пространство и рабочее время расходуется на все инстансы, поэтому в случае финансовых затруднений не нужно создавать/запускать их больше чем вы можете себе позволить кроме бесплатного.
Жмем в мастере «Next…», на 3-м шаге оставляем все значения по умолчанию, на 4-м соглашаемся с предлагаемыми 8-ю гигабайтами SSD дисковой по умолчанию и запускам инстанс кнопкой «Review and Launch»:
После мы получим окно с сообщением о создании новой пары ключей для подключения к нашему по SSH и предложением задать этой паре имя и скачать private-ключ в формате *.pem. Он нам очень понадобится в дальнейшем, поэтому желательно его сразу сохранить в надежное место. В случае если этот файл будет утерян – вы потеряете возможность удаленного подключения к инстансам, его использующим. В EC2 нет возможности перегенерировать его заново для уже существующего инстанса, единственным способом является подключение диска инстанса к другому инстансу, к которому есть доступ и последующая правка ключа.
Через некоторое время инстанс будет запущен, у него появится внутренний (приватный) и внешний (публичный) IPv4 адреса, а также два соответствующих DNS имени.
Сразу настраиваем Security Groups для обеспечения прохождения трафика для нужных вам сервисов:
Открытые входящие порты 500, 1701, 4500 UDP и 4500 TCP понадобятся нам для организации IPSec L2TP VPN туннеля, HTTP & HTTPS для публикации сервисов домашней фермы, доступ снаружи к инстансу по SSH был создан автоматически при создании инстанса, т.к. EC2 по сути не содержит никаких средств встроенного доступа к консоли виртуальных машин через свой веб-интерфейс. В наличии лишь возможность просмотра экрана:
Целесообразно настроить доступ по VPN и через SSH только со своего домашнего IP-адреса. Порядок правил в Security Groups не имеет значения.
Поскольку мы будем использовать множественный NAT документация AWS рекомендует отключать в этом случае «Network source/destination checking»:
Так как мы будем использовать именно IPSec-тунеллирование, а не транспорт, для нас эта настройка не имеет особого смысла, но на всякий случай лучше ее выключить.
Подключимся через SSH к нашему инстансу. Если вы используете для подключения графический клиент SSH, например, PuTTY, вам поможет встроенная справка по подключению, вызываемая ПКМ по инстансу -> Connect:
Amazon Linux ведет родословную от RHEL и CentOS, поэтому используется пакетный менеджер yum.
Все операции, описанные далее, нужно выполнять с повышением привилегий, поэтому предваряем их sudo либо просто работаем под root.
Первым делом обновляем:
В качестве ПО для организации VPN-сервера мы будем использовать связку libreswan и xl2tpd.
LibreSwan (форк Openswan и аналог strongSwan) – популярная реализация VPN IPSec и IKE (Internet Key Exchange). Он умеет в правильный обход различных видов NAT и их комбинаций, что особо важно при организации IPSec тунеллирования.
xl2tpd также широко используется, его основным достоинством является встроенная возможность аутентификации и передача параметров подключения клиента через ppp при подключении (например IP адреса, настроек маршрута по умолчанию, dns серверов и т.д.), что исключает необходимость дополнительного развертывания DHCP и Radius для нашей простой задачи.
Поскольку xl2tpd отсутствует в стандартных репозиториях Amazon Linux нам нужно включить EPEL (Extra Packages for Enterprise Linux):
Устанавливаем необходимые пакеты:
Включаем роутинг на уровне ядра:
в файле /etc/sysctl.conf прописываем:
Отключаем в текущем сеансе rp_filter, чтобы не производить перезагрузку:
Применяем настройки и проверяем наличие роутинга:
Нам нужно обеспечить проброс входящих (по отношению к публичному интерфейсу инстанса) пакетов с портов требуемых сервисов в наш будущий IPSec туннель. Для этого необходимо не только от-NAT-ить эти пакеты, но еще и сделать маскарадинг на ppp0 интерфейсе.
Воспользуемся для этого встроенными возможностями iptables, который в случае Amazon Linux изначально настроен на полное пропускание любого трафика в любом направлении:
делаем DNAT нужных портов:
форвардим все пакеты, пришедшие на эти порты на адрес Windows-гейта:
делаем маскарадинг для этих пакетов:
Правила iptables целесообразно сохранить, чтобы они автоматически подтягивались при перезагрузке инстанса:
В данном случае используется DNAT (Destination NAT) нужного TCP порта с сетевого интерфейса eth0 инстанса по направлению на IPv4 адрес 10.100.0.2, который является адресом на ppp интерфейсе службы RRAS нашего Windows-гейта в домашнем гипервизоре.
Далее идет очень важный момент: поскольку сервисам внутри гипервизора нужно обеспечить возможность отвечать на поступившие к ним со стороны AWS инстанса запросы, то необходимо обеспечить маскарадинг (замену адреса отправителя) на интерфейсе ppp0 инстанса перед отправкой пакета, иначе ответ пойдет совершенно по другому маршруту: с гейта Windows в гипервизоре мимо IPSec тоннеля прямиком на дефолтный маршрутизатор (домашний роутер), в результате чего конечно будет отброшен на стороне клиента сервиса, как пришедший с не запрошенного ресурса. В случае использования маскарадинга в заголовке пакета на входе в vpn тоннель адрес отправителя изменится с адреса где-то-там-в-интернете на адрес ppp0 интерфейса инстанса AWS:EC2, т.е. в моем случае на 10.100.0.1
Как альтернативу использованию iptables для других дистрибутивов Linux либо *NIX-систем можно рекомендовать старый добрый rinetd, там все это делается вообще в одну строку в его конфиге rinetd.conf:
Единственное, что нужно будет в этом случае включить в ядре, так это возможность Routing/NAT трафика.
Пришло время готовить libreswan.
В файле /etc/ipsec.conf содержится инструкция загрузки всех .conf файлов из /etc/ipsec.d/, поэтому создаем новый конфигурационный файл в данной директории /etc/ipsec.d/aws_vpn.conf и вносим в него:
Для простоты мы будем использовать IPSec аутентификацию на основе общего ключа (PSK), а не сертификатов, поэтому должны его явно указать. В файле /etc/ipsec.secrets содержится инструкция загрузки всех .secrets файлов из /etc/ipsec.d/, там создаем новый файл /etc/ipsec.d/aws_vpn.secrets и указываем в нем PSK в формате:
В качестве примера:
Поскольку внутри IPSec тоннеля будет использоваться ppp соединение, а там присутствует собственная аутентификация, настраиваем и ее:
Вносим логин и пароль в файл /etc/ppp/chap-secrets в формате:
В качестве примера:
При подключении клиенту ppp возможно передать ряд опций для настройки сетевого интерфейса и таблицы маршрутизации с его стороны.
В файле /etc/ppp/options.xl2tpd задаем эти опции:
Т.к. нам не нужно передавать клиенту адреса dns, wins и т.п. вещи — все остальные опции нужно закомментировать.
Тут необходимо пояснение конфига.
Стандартным поведением для VPN подключений является установка нового Default Route в таблице клиента, что заставляет весь трафик от него в интернет «ходить» через vpn сервер. В нашем случае это неправильно, т.к. задачей Windows-гейта является и обеспечение имитации доступа к сети интернет виртуальной офисной сети за ним в гипервизоре и публикация ресурсов внутренних сервисов наружу через AWS:EC2, поэтому нерационально гонять весь трафик через инстанс в AWS:EC2. Вот почему нужно запретить VPN подключению в RRAS менять маршрут по умолчанию (на домашний роутер).
Также важно правильно подобрать значения MTU и MRU: мы используем тунеллирование IPSec и слишком большой размер полезной нагрузки может не вписаться в лимит при инкапсуляции, что приведет к фрагментации и скорее всего к ошибке. В случае ее появления попробуйте в первую очередь уменьшить эти значения, например, до 1280. Указанные в приведенном конфиге значения совместимы с клиентом VPN Windows.
Осталось настроить xl2tpd
Настраиваем все необходимое в конфигурационном файле xl2tpd /etc/xl2tpd/xl2tpd.conf:
Проверяем все что натворили
Пробуем запускать оба сервиса и проверяем конфиги:
Сервисы могут быть уже запущены, в этом случае их просто рестартим.
Если все хорошо, то результат вывода ipsec verify должен быть аналогичен скриншоту:
Отлаживать работу xl2tpd можно интерактивно, запустив его с ключом -D и подвесив в отдельное «окно» терминала SSH с помощью утилиты screen:
В этом случае процесс xl2tpd не уйдет в фон, а будет осуществлять вывод всей своей деятельности на экран терминала.
В случае возникновения каких-то проблем нужно раскомментировать опции отладки в конфигах (см. комментарии) и смотреть содержимое системных логов и файла /var/log/pluto.log. Также стоит обратить внимание на содержимое опции virtual_private/virtual-private в файле /etc/ipsec.conf, в ней перечислены все частные сети, доступные для обмена данными через IPSec. Если у вас по каким-то причинам своя адресация, например, используется собственный пул белых IPv4 адресов, следует внести изменения в этот параметр.
Перейдем к последнему этапу – настройке RRAS службы в Windows-гейте и проверке публикаций сервисов со стороны интернета
Предполагается, что в вашем домашнем гипервизоре есть виртуальная машина под Windows 2012R2 или новее, развернутая в графическом (Desktop) режиме и в этой виртуальной машине в наличии два сетевых адаптера: один «смотрит» в домашнюю сеть и имеет в качестве маршрута по умолчанию домашний роутер, а другой – в виртуальную локальную «офисную» сеть, в которой присутствуют сервисы, публикуемые наружу. Наличие домена Windows необязательно, если конечно сами сервисы его не требуют.
Устанавливаем с помощью Server Manager-а либо с помощью командлета PowerShell Install-WindowsFeature все необходимые роли:
Здесь я демонстрирую установку ролей через графику, потому что потом все равно будет значительно удобнее вызовом мастера настройки из Server Manager-а в графике настраивать саму службу RRAS, которая порадует нас старым добрым интерфейсом времен Windows Server 2003:
Жмем ПКМ на своем сервере, выбираем «Configure and Enable Routing and Remote Access» и далее конфигурирование вручную:
Смело выбираем все галки, завершаем мастер и стартуем сервис:
Для начала выпустим свою виртуальную локальную сеть наружу. Идем в IPv4->NAT и создаем новый интерфейс, в качестве существующего интерфейса, на котором будет осуществляться NAT выбираем внешний интерфейс (который смотрит в «Инет», вернее в вашу домашнюю сеть), помечаем его как публичный и включаем на нем NAT:
Проверяем, как ходит трафик из виртуальной локальной сети наружу через наш гейт. Настройка Windows Firewall нам пока не потребуется.
Если все ок – создадим наконец то, ради чего мы боролись, VPN-подключение к нашему инстансу в AWS и проверим публикацию наших сервисов. Идем в оснастке RRAS в «Network Interfaces» и создаем новый Demand-dial интерфейс c произвольным именем:
Сразу выбираем L2TP подключение, так наш новый интерфейс не будет пытаться автоматически определить тип VPN и в результате быстрее будет подключаться:
Дальше в мастере указываем публичный адрес нашего облака (в моем случае Elastic IP). На следующих шагах оставляем все как есть, т.к. нам не нужно Site-To-Site подключение:
Указываем учетную запись пользователя, под которой мы настраивали подключение ppp (в файле /etc/ppp/chap-secrets). Имя домена указывать не нужно:
Мастер создает новое подключение. Теперь осталось его донастроить. Корректируем тайм-аут отключения по бездействию (Idle-time), убираем устаревший CHAP в пользу только MS-CHAPv2, указываем в «Advanced Properties» PSK ключ (тот что был нами прописан для xl2tpd в файле /etc/ipsec.d/aws_vpn.secrets) и убираем IPv6:
/>
После создания нового интерфейса нужно также обязательно зайти в свойства самой RRAS службы, разрешить свою политику IPSec для L2TP и указать свой PSK. Попросят перезапустить службу RRAS.
Казалось бы все, можно смело поднимать новый интерфейс и наслаждаться работой. А вот и нет. Из-за того, что мы использовали NAT на стороне инстанса AWS:EC2 клиент VPN Windows не сможет подключиться к такому Nat-Traversal узлу. Это справедливо и для клиентских версий (вплоть до последнего на момент написания этой статьи билда Windows 10) и для серверных.
К счастью, есть официальное решение этой проблемы в виде правки в реестре настроек сервиса IPSec Policy с последующей перезагрузкой:
По адресу
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
создаем DWORD (32-bit) ключ
AssumeUDPEncapsulationContextOnSendRule = 2
и перезагружаем наш Windows Gate.
Служба RRAS к сожалению славится своей капризностью в настройке и работе, да еще и после перезагрузки выполняет отложенный старт. Так что можно ее после перезагрузки поторопить.
Если все сделано правильно – подключение заработает в течении 5-10 секунд.
Осталось сделать публикацию нужных ресурсов на самом Windows гейте.
Для теста будем отрабатывать публикацию веб-сервера. Для начала проверим наш IPSec тоннель и корректность правил iptables.
Дрожащими руками проверяем с произвольного ПК, подключенного к сети Интернет:
В процессе установки нужных ролей принудительно установился «родной» MS IIS, но мы хотим еще проще. Для этого на Windows платформе хорошо подходит HFS (HTTP File Server) – он бесплатен, не требует инсталляции, отдает характерную страницу и HTTP заголовок, может работать на произвольном порту (по умолчанию это 8080, так что в нашем случае потребуется перенастроить на 80), а также сразу в своей консоли пишет откуда произошло подключение, что очень удобно для отладки публикации множества веб-ресурсов на платформе Windows. Для его использования необходимо сначала остановить сайт MS IIS, чтобы отвязать встроенный сервер от требуемого порта. Поскольку устанавливать консоль управления MS IIS мы не хотим (на самом деле будет присутствовать для совместимости консоль MS IIS 6, но через нее нельзя управлять IIS 7+), мы сделаем это через PowerShell:
либо просто через утилиту управления iisreset:
После этого необходимо разрешить в встроенном Windows Firewall входящий трафик на порт 80.
Запускаем HFS и проверяем:
Все здорово. Мы добились того, что с любой точки интернета виден веб-сервер, живущий у нас дома в виде виртуальной машины в произвольном гипервизоре.
Финальный штрих: учим RRAS форвардить все подобные запросы извне внутрь виртуальной офисной сети, где у нас согласно легенды живет еще один веб-сервер.
Для этого снова идем в оснастку управления RRAS в IPv4->NAT и ПКМ на нашем VPN интерфейсе, где выбираем вкладку «Services and Ports», отмечаем в списке Web Server и указываем веб-сервер в внутренней виртуальной сети, ресурсы которого мы хотим опубликовать в интернете:
Жмем ОК и… все готово. Проверяем – все должно прекрасно работать.
Таким нехитрым способом можно оперативно опубликовать практически любые сервисы и ресурсы, от сайтов, почтовых серверов до каких-то сложных интеграций. Естественно для большинства из них потребуется наличие собственного DNS домена с возможностью создания в нем субдоменов и редактирования нужных записей. Также желательно для публикации веб-ресурсов использовать SSL сертификаты, благо с помощью LetsEncrypt и аналогичных ACME-совместимых сервисов все это можно делать совершенно бесплатно и с автоматическим обновлением.
При перезагрузке инстанса публичный IPv4 адрес не меняется – только при останове (stop), однако все равно рекомендуется использовать в AWS:EC2 статический IPv4 адрес. Статический в том смысле, что при выключении вашего инстанса он останется закрепленным за ним, а не выпадет в общий свободный пул. Конечно это нужно чтобы не заморачиваться каждый раз с перенастройкой DNS записей в доменах, да и TTL с кешированием никто не отменял. Стоит это очень недорого и зовется, как уже указывалось выше Elastic IP.
Примитивная автоматизация процесса
Напоследок хочу упомянуть об еще одной замечательной фиче AWS:EC2 – быстром конфигурировании разворачиваемого инстанса. Вариантов быстрого развертывания в AWS:EC2 много, вплоть до специальных (и довольно сложных, но весьма могучих) сервисов, но есть самый простой: на шаге № 3 в мастере создания нового инстанса в самом низу есть поле «User data». В него можно поместить скрипт на bash или даже PowerShell (в случае инстанса под Windows) и этот скрипт будет выполнен автоматически сразу после создания инстанса.
Т.е. вы можете, слегка подредактировав все указанные выше команды и конфиги создать свой собственный сценарий bash и использовать его для быстрого поднятия вот такого виртуального AWS:EC2-роутера. Подробнее об этой возможности.