Публикуем любые сервисы, расположенные в домашнем гипервизоре через сервис 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:EC2.
Одним из самых важных шагов – выбираем регион (по сути дата центр) 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.
Первым делом обновляем:
# yum updateВ качестве ПО для организации 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):
# yum-config-manager --enable epelУстанавливаем необходимые пакеты:
# yum install libreswan xl2tpd -yВключаем роутинг на уровне ядра:
в файле /etc/sysctl.conf прописываем:
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.lo.secure_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.eth0.secure_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
Отключаем в текущем сеансе rp_filter, чтобы не производить перезагрузку:
# for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do
# echo 0 > $f
# done
Применяем настройки и проверяем наличие роутинга:
# sysctl -p /etc/sysctl.conf
# cat /proc/sys/net/ipv4/ip_forward
Нам нужно обеспечить проброс входящих (по отношению к публичному интерфейсу инстанса) пакетов с портов требуемых сервисов в наш будущий IPSec туннель. Для этого необходимо не только от-NAT-ить эти пакеты, но еще и сделать маскарадинг на ppp0 интерфейсе.
Воспользуемся для этого встроенными возможностями iptables, который в случае Amazon Linux изначально настроен на полное пропускание любого трафика в любом направлении:
делаем DNAT нужных портов:
# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.100.0.2:80
# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to-destination 10.100.0.2:443форвардим все пакеты, пришедшие на эти порты на адрес Windows-гейта:
# iptables -A FORWARD -p tcp -d 10.100.0.2 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# iptables -A FORWARD -p tcp -d 10.100.0.2 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTделаем маскарадинг для этих пакетов:
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Правила iptables целесообразно сохранить, чтобы они автоматически подтягивались при перезагрузке инстанса:
# service iptables saveВ данном случае используется 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:
<ip source> <port source> <ip destination> <port destination>Единственное, что нужно будет в этом случае включить в ядре, так это возможность Routing/NAT трафика.
Пришло время готовить libreswan.
В файле /etc/ipsec.conf содержится инструкция загрузки всех .conf файлов из /etc/ipsec.d/, поэтому создаем новый конфигурационный файл в данной директории /etc/ipsec.d/aws_vpn.conf и вносим в него:
config setup
# раскомментируем только в случае необходимости отладки
# plutostderrlog=/var/log/pluto.log
# logfile=/var/log/pluto.log
# plutodebug = all
# включаем NAT-T из-за наличия двух NAT-ов
nat_traversal=yes
oe=off
protostack=netkey
nhelpers=0
interfaces=%defaultroute
conn aws_vpn
type=tunnel
auto=start
forceencaps=yes
pfs=no
fragmentation=yes
authby=secret
left=%defaultroute
# здесь вместо <…> указываем публичный адрес инстанса в Elastic IP
leftid=<…>
# здесь вместо <…> указываем приватный адрес инстанса (172.х.х.х)
leftsubnet=<…>/32
leftnexthop=%defaultroute
leftprotoport=17/1701
rightprotoport=17/%any
right=%any
rightsubnetwithin=0.0.0.0/0
rightsubnet=vhost:%priv
Для простоты мы будем использовать IPSec аутентификацию на основе общего ключа (PSK), а не сертификатов, поэтому должны его явно указать. В файле /etc/ipsec.secrets содержится инструкция загрузки всех .secrets файлов из /etc/ipsec.d/, там создаем новый файл /etc/ipsec.d/aws_vpn.secrets и указываем в нем PSK в формате:
<приватный адрес инстанса в виде 172.х.х.х> %any : PSK "<строка PSK>"В качестве примера:
172.31.20.120 %any : PSK "Pa$$w0rd"Поскольку внутри IPSec тоннеля будет использоваться ppp соединение, а там присутствует собственная аутентификация, настраиваем и ее:
Вносим логин и пароль в файл /etc/ppp/chap-secrets в формате:
<user> * <password> *В качестве примера:
aws_user * Pa$$w0rd *При подключении клиенту ppp возможно передать ряд опций для настройки сетевого интерфейса и таблицы маршрутизации с его стороны.
В файле /etc/ppp/options.xl2tpd задаем эти опции:
# разрешаем xl2tpd устанавливать ip адреса тоннеля
ipcp-accept-local
ipcp-accept-remote
# запрещаем создавать новый defaultroute со стороны Windows-гейта в домашнем гипервизоре
nodefaultroute
noccp
auth
# принудительно заставляем RRAS в Windows-гейте использовать mschap-v2 для авторизации
require-mschap-v2
# принудительно устанавливаем MTU и MRU
mtu 1410
mru 1410
lock
Т.к. нам не нужно передавать клиенту адреса 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:
[global]
port=1701
ipsec saref = yes
; включаем, только если хотим отладить ошибку
;debug tunnel = yes
;debug avp = yes
;debug network = yes
;debug state = yes
;debug tunnel = yes
[lns default]
name = AWSvpnServer
; задаем желаемый диапазон для адресации в ppp
ip range = 10.100.0.2-10.100.0.2
; присваиваем адрес интерфейсу ppp0 AWS:EC2 инстанса
local ip = 10.100.0.1
require authentication = yes
require chap = yes
refuse pap = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
Проверяем все что натворили
Пробуем запускать оба сервиса и проверяем конфиги:
service ipsec start
service xl2tpd start
ipsec verify
Сервисы могут быть уже запущены, в этом случае их просто рестартим.
Если все хорошо, то результат вывода ipsec verify должен быть аналогичен скриншоту:
Отлаживать работу xl2tpd можно интерактивно, запустив его с ключом -D и подвесив в отдельное «окно» терминала SSH с помощью утилиты screen:
# xl2tpd -DВ этом случае процесс 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:
Stop-WebSite -Name "Default Web Site"либо просто через утилиту управления iisreset:
iisreset /stopПосле этого необходимо разрешить в встроенном 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-роутера. Подробнее об этой возможности.
Спасибо, что потратили время на прочтение этой статьи.
