Создать IPSec туннель от AWS до USG Pro 4

Создать IPSec туннель от AWS до USG Pro 4, UniFi Network

forthgate

Guest

15.07.2019 12:14:00

У меня есть USG Pro 4, и я хочу создать IPSec туннель с AWS к моей сети. Я скачал из AWS конфигурацию ipsec для VyattaOS и добавил её в USG через ssh. Теперь мне нужно конвертировать её в config.gateway.json, но я не знаю, какие разделы текущей конфигурации нужно добавить? Достаточно только секции «ipsec» или нужно создать ещё и «interface»?

set vpn ipsec ike-group AWS lifetime '28800'
set vpn ipsec ike-group AWS proposal 1 dh-group '2'
set vpn ipsec ike-group AWS proposal 1 encryption 'aes128'
set vpn ipsec ike-group AWS proposal 1 hash 'sha1'
set vpn ipsec site-to-site peer AWS_IP authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer AWS_IP authentication pre-shared-secret 'key'
set vpn ipsec site-to-site peer AWS_IP description 'VPC tunnel 1'
set vpn ipsec site-to-site peer AWS_IP ike-group 'AWS'
set vpn ipsec site-to-site peer AWS_IP local-address 'MY_WAN_IP'
set vpn ipsec site-to-site peer AWS_IP vti bind 'vti0'
set vpn ipsec site-to-site peer AWS_IP vti esp-group 'AWS'

set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec esp-group AWS compression 'disable'
set vpn ipsec esp-group AWS lifetime '3600'
set vpn ipsec esp-group AWS mode 'tunnel'
set vpn ipsec esp-group AWS pfs 'enable'
set vpn ipsec esp-group AWS proposal 1 encryption 'aes128'
set vpn ipsec esp-group AWS proposal 1 hash 'sha1'

set vpn ipsec ike-group AWS dead-peer-detection action 'restart'
set vpn ipsec ike-group AWS dead-peer-detection interval '15'
set vpn ipsec ike-group AWS dead-peer-detection timeout '30'

set interfaces vti vti0 address '169.254.106.114/30'
set interfaces vti vti0 description 'VPC tunnel 1'
set interfaces vti vti0 mtu '1436'

set protocols bgp 65000 neighbor 169.254.106.113 remote-as '64512'
set protocols bgp 65000 neighbor 169.254.106.113 soft-reconfiguration 'inbound'
set protocols bgp 65000 neighbor 169.254.106.113 timers holdtime '30'
set protocols bgp 65000 neighbor 169.254.106.113 timers keepalive '10'

set protocols bgp 65000 network 192.168.77.0/24

P.S. Также пробовал создать туннель через GUI контроллер — не получилось, работает только если конфиг загружать через ssh в USG.

tjwenger Guest	#2 08.11.2019 19:10:00 Любопытно — когда я пытаюсь скачать конфигурацию Vyatta с AWS, она, похоже, исчезла. У кого-нибудь есть информация по этому поводу?

UI-Team

Guest

31.10.2019 17:07:00

@geeks2you Помню, что были проблемы с устойчивостью VPN, когда в обеих конфигурациях использовался одинаковый "peer IP", но лучший способ проверить, работает ли всё, — это посмотреть конфигурацию в CLI командой "show vpn" и затем протестировать, вручную отключив один из туннелей.

geeks2you

Guest

29.10.2019 23:47:00

@UI-jaffe @chrisjcbt @it-webshark Я добавил второй сетевой интерфейс к ec2-инстансу на AWS, что дало ему ещё один приватный внутренний IP в другой подсети. Для VPN-туннеля 1 на Ubiquiti я настроил маску подсети строго только на эту отдельную подсеть (/24), так же и для VPN-туннеля 2. Это устранило пересечения и позволило поднять туннели. Сделал статические маршруты, чтобы направлять каждую подсеть на соответствующий VPN-туннель — всё сработало (туннели показываются как поднятые на AWS). Пока не тестировал устойчивость, но сейчас настроил WAN2 как балансировщик нагрузки с 1%. Всё было сделано полностью через GUI. Кто-то видит проблемы в такой конфигурации?

UI-Team

Guest

29.10.2019 16:01:00

@chrisjcbt Понимаю, я сам уже много лет продвигаю многие из этих функций. Но обычно проходит довольно много времени, прежде чем они появляются. Всё связано с особенностями нашей платформы. Если у тебя получается сделать это через CLI, скорее всего, дело только в ограничениях валидации в графическом интерфейсе, которые нужно ослабить. Дай знать.

chrisjcbt

Guest

29.10.2019 09:32:00

@UI-jaffe Согласен, справедливое замечание, беру его на заметку — это не ошибка, а запрос на новую функцию. Для меня устойчивость VPN критически важна, и я бы советовал это всем, кто использует Site-to-Site VPN, где ресурсы на другом конце VPN нужны в ежедневной работе. Большинство пользователей, возможно, имеют только один интернет-канал, но если есть возможность воспользоваться устойчивостью VPN даже при одном соединении — я бы ею воспользовался. Такая функция уже предусмотрена в AWS из коробки, и для меня её использование ничего не стоит. Постараюсь найти CLI-команды, чтобы одновременно поднять оба туннеля на USG — давно не пробовал. Надеюсь, если это реализуется через CLI, то работа по внедрению этой функции в интерфейс будет проще, чем создавать совсем новую функцию.

UI-Team

Guest

28.10.2019 16:34:00

@chrisjcbt Я бы не сказал, что это «исправление», скорее — добавленная «функция». У нас запланировано много улучшений VPN для линейки UDM, и избыточность VPN *возможно* станет одной из них, но пока я не видел ничего такого в разработке.

chrisjcbt

Guest

26.10.2019 08:02:00

Я не могу найти, как настроить это в интерфейсе. AWS не разделяет два VPN-туннеля на активный и пассивный, у них оба работают в режиме Active/Active (по моему мнению, это правильный подход). Это потому, что эти два туннеля обеспечивают устойчивость к сбоям, подключаясь к двум разным физическим локациям в этом регионе с их стороны. Если у них проблема с дата-центром, мой туннель останется активным. Я не хочу создавать вторую сеть в AWS только ради управления вторым туннелем — это слишком сильно усложнит управление сетью в AWS. Я хочу, чтобы Unifi позволял создавать два туннеля, которые ведут к одной и той же сетевой локации. Судя по всему, это можно сделать через CLI, но не через интерфейс. Если это возможно через CLI, то разве нельзя исправить это программно и в интерфейсе?

geeks2you

Guest

24.10.2019 23:37:00

@it-webshark @UI-jaffe Я сейчас пытаюсь сделать это сам через AWS. AWS дает два туннеля, так что с их стороны, кажется, всё нормально. На стороне USG у меня настроен s2s vpn на wan1. Как добавить второй s2s vpn туннель на wan2? Когда вбиваю все данные в GUI, выдает ошибку, что сети не могут перекрываться. Решение — создать вторую сеть специально для AWS-инстанса, чтобы у него было два внутренних IP: один для s2s на wan1, другой для s2s на wan2, чтобы они не пересекались внутри Ubiquiti? С AWS стороны, глядя на USG, трафик всегда будет направлен на один и тот же IP. Как AWS-инстанс поймет, что пакеты надо отправлять через s2s на wan1, а не на wan2? С USG, глядя на AWS, можно пинговать инстанс по двум разным IP. Значит, при переключении на резервный канал достаточно просто обращаться ко второму IP?

UI-Team

Guest

#10

02.10.2019 19:33:00

@chrisjcbt Я упомянул Azure лишь потому, что там похожая концепция с резервными туннелями к облачному провайдеру. Судя по ответу @it-webshark, у него получилось полностью настроить через GUI резервный шлюз / vnet. Это публичный IP-адрес для этого резервного шлюза, а также приватная подсеть IP, @it-webshark? Насчёт проверки в контроллере UniFi: нельзя использовать одинаковую удалённую подсеть для двух разных VPN-конфигураций, и, насколько я знаю, нельзя повторять и адрес пира. А при отключении WAN1 вы пользуетесь другим диапазоном приватных адресов для доступа к ресурсам в Azure? @chrisjcbt и @it-webshark несколько дней и недель пробовали разные варианты VPN-фейловера. По сути, USG/UniFi этого не поддерживает, чтобы подключаться через WAN2, так что, насколько я понимаю, нужно использовать отдельный внешний адрес пира и отдельную внутреннюю удалённую подсеть (почти как совсем другой VPN-туннель), чтобы всё работало.

chrisjcbt

Guest

#11

01.10.2019 09:15:00

Спасибо всем. Но, думаю, мы немного ушли в сторону. Вопрос не про интеграцию с Azure, а про несколько туннелей к AWS! Есть у кого-то готовое руководство по AWS с обеспечением отказоустойчивости через несколько туннелей? В интерфейсе это настроить не получается, так что предполагаю, что изменения нужно вносить через CLI.

norinchea

Guest

#12

30.09.2019 22:15:00

@chrisjcbt @UI-jaffe Мы всё-таки заставили работать резервные туннели! В общем, нам пришлось настроить резервный шлюз и VNet в Azure, запиарить его в Azure с тем, к которому нужно было оставаться подключёнными, и теперь у нас два IPsec туннеля на USG: один через WAN1 — к изначальному VPN в Azure, и второй через WAN2 — к резервному VPN в Azure. За два постоянно активных туннеля придётся немного доплатить, но это гарантирует: если WAN1 упадёт, WAN2 сразу подхватит туннель, и наши локальные ресурсы по-прежнему будут иметь доступ к ресурсам в основном VNet Azure. Немного мороки, но работает отлично!

UI-Team

Guest

#13

23.09.2019 19:57:00

@chrisjcbt Я подробно обсуждал это с @mattwebshark в личных сообщениях несколько месяцев назад насчёт резервных туннелей в Azure. Не уверен, пришёл ли он тогда к какому-то выводу или решению по их настройке, но помню, что было много ограничений с обеими реализациями IPsec (на основе политики и маршрутизации) при попытках это запустить в EdgeOS.

chrisjcbt Guest	#14 23.09.2019 13:13:00 Могу я быстро спросить, пробовали ли вы выполнить эти шаги и добавить два VPN-эндпоинта, которые можно использовать для подключения к AWS? Я пытался указать оба туннеля в интерфейсе, но это не срабатывало, потому что диапазон IP-адресов назначения уже указан в политике первого туннеля. На данный момент у меня работает только один туннель, а хотелось бы использовать оба для повышения надежности.

Читают тему (гостей: 2)