USG к USG Site to Site OpenVPN на разных контроллерах

USG к USG Site to Site OpenVPN на разных контроллерах, UniFi Network

firefi

Guest

11.07.2017 01:53:00

Всем привет! Хотел узнать, можно ли вручную настроить site-to-site VPN между двумя USG, которые управляются разными cloud key контроллерами. Оба USG имеют публичные IP (подключены через мостовые кабельные модемы) и используют Dynamic DNS, так что публичные IP доступны через полностью квалифицированные DNS-имена. На обоих стоит 5.4.15 cloud key, а на USG — бета 4.3.48 на одном сайте и последняя публичная прошивка 4.3.41 на другом.

Вот проблема — OpenVPN для site-to-site обычно хочет, чтобы один конец был клиентом, а другой — сервером. Можно ли оставить поле «Remote Host» пустым на стороне сервера, чтобы добиться этого?

Вот мои предполагаемые настройки:
Создать новую сеть -> Site to Site VPN -> VPN тип OpenVPN

Клиентская сторона:
Remote Host: DNS-имя (публичный IP сервера)
Remote Address: туннельный IP удаленной стороны, например, 10.0.0.1/24
Port: 1194
Local Address: туннельный IP локальной стороны, например, 10.0.0.2/24
Port: 1194
Shared secret key: одинаковый с обоих сторон

Серверная сторона:
Remote Host: оставить пустым? (или DNS имя публичного IP клиента??? ужас какой-то)
Remote Address: 10.0.0.2/24 (локальный адрес клиента)
Local Address: 10.0.0.1/24 (удаленный адрес клиента)
Shared secret key: одинаковый с обоих сторон

Сработает ли такое? Я бы экспериментировал, но у меня нет двух USG с разными контроллерами для теста на стенде. Надо делать на рабочем сайте, поэтому хочется быть уверенным, что проблем не возникнет.

USG выступают роутерами на сайтах и полностью контролируют все сети, делают NAT, так что проблем с двойным NAT нет. Публичные IP берут по DHCP у провайдера, и dynamic DNS отлично работает для удаленного доступа. Сейчас оба работают как PPTP VPN серверы, и я пользуюсь ими или облачным доступом.

Зачем это нужно: чтобы сайт 1 мог получить доступ к hotspot менеджеру сайта 2 и создавать ваучеры. Если бы делал заново, наверное, объединил бы оба сайта под одним контроллером.

Буду благодарен за любую информацию!

firefi Guest	#2 02.10.2017 19:24:00 О, и я хотел предложить использовать traceroute с клиента на удалённой стороне или с интерфейса GI0/1, чтобы посмотреть, где прерывается трафик. Удачи!

unifilife Guest	#3 23.07.2018 17:24:00 Вау — больно слышать, но ладно, думаю, скоро этого стоит ждать. Спасибо за ответ!

bis Guest	#4 23.07.2018 17:15:00 Я нашёл этот запрос на функцию, так что, думаю, пока это невозможно: https://community.ui.com/feature-requests/4f4446ac-b740-4859-b471-f9f985f5493f

unifilife

Guest

23.07.2018 16:35:00

Спасибо за подробную информацию. Вопрос по поводу FQDN — как именно его вводить? Каждый раз, когда я ввожу имена динамического DNS, появляется ошибка. IP-адреса на каждом объекте будут меняться, так что указать IP невозможно. Спасибо!

benjohnson

Guest

23.02.2018 02:22:00

Спасибо всем за инструкции — у меня получилось настроить site-to-site. Единственное, что могу добавить — не забывайте про фаервол и маршруты. Мне пришлось сначала открыть доступ для трафика OpenVPN, а потом добавить маршруты с обеих сторон, чтобы указать VPN.

firefi Guest	#7 05.10.2017 12:27:00 Очень круто. Рад слышать, что ты добрался! Удачи.

alohait

Guest

04.10.2017 03:57:00

Ок, они построили маршруты, и мне пришлось добавить группы IP в файрвол USG, после чего трафик начал работать. Осталось решить пару небольших странных проблем, но в целом всё работает. Спасибо большое за помощь!

firefi

Guest

02.10.2017 19:24:00

Похоже, что роутер AT&T не знает о удалённых подсетях за удалённым USG и о подсетях за локальным USG. NAT, который происходит на локальном USG, создаёт проблему, так как роутер AT&T, если я правильно понимаю, видит только WAN-интерфейс USG. Возможно, нужно настроить статические маршруты на роутере AT&T, чтобы трафик с Gi0/1, направленный к подсетям за локальным или удалённым USG, шел на адрес Gi0/2, который использует локальный USG. Это предполагает, что Gi0/1 должен быть физически подключён и к LAN стороне USG... Или я немного запутался.

alohait

Guest

#10

02.10.2017 17:18:00

Спасибо за помощь! Я подключил оба сайта! Сейчас моя конфигурация немного нестандартная (спасибо AT&T): мой USG, который работает с двойным NAT, на самом деле подключён к второму сетевому интерфейсу (Gi0/2) роутера AT&T (чтобы избежать сбоев в обслуживании), а мой ноутбук подключён к LAN-порту этого USG. С моего ноутбука я могу пропинговать подсеть на другом USG через site-to-site соединение и подсети на другом интерфейсе AT&T (Gi0/1). Но с любого устройства в подсети Gi0/1 я могу пропинговать IP-адрес на Gi0/2, но не сам USG и ничего за ним. С удалённой стороны я могу пропинговать USG и мой ноутбук, но не могу достучаться до устройств в подсети Gi0/1. Это понятно? Мне пока непонятно, проблема на моём USG или на роутере AT&T, где связь прерывается. Любая помощь будет очень признательна!

bis

Guest

#11

02.10.2017 05:04:00

Я особо не тестировал этот конкретный сценарий, но вот что: для настройки VPN на роутере за первым NAT нужно использовать публичный IP адрес роутера, выходящего в интернет, а затем перенаправлять трафик OpenVPN на приватный IP адрес (внешний интерфейс второго роутера). Это должно работать с OpenVPN (а вот насчёт ipsec не уверен).

alohait

Guest

#12

02.10.2017 04:25:00

У меня с одной стороны двойной NAT, так что на USG с этой ситуацией двойного NAT нужно ли использовать частный IP для Локального адреса? Если да, то что использовать в качестве Удалённого адреса на другом USG? Тот же частный IP или публичный IP, который проброшен на этот частный IP? Заранее спасибо за помощь!

firefi

Guest

#13

14.09.2017 13:17:00

Возможно, можно использовать JSON-файл для дополнительной настройки OVPN (кажется, с IPsec они так часто делают). Я пользовался PPTP для удалённого доступа, и, к сожалению, похоже, что там нет опций для добавления маршрутов через PPP-интерфейс к удалённому клиенту, подключённому к USG.

Возможно, после того, как будет настроена конфигурация OpenVPN, можно попробовать зайти по SSH на USG и вручную отредактировать конфиг OpenVPN, а затем перезапустить демон, чтобы временно запустить его с одной стороны в режиме клиента, а с другой — в режиме сервера с TCP-соединением. Так вы сможете проверить, работает ли это, прежде чем заморачиваться с JSON-файлом для более сложных конфигураций OVPN.

USG крутая штука, и хочется верить, что со временем гибкость настроек будет улучшаться с новыми релизами. Мне реально нравится, что всё это под крышкой Unifi.

ChipH

Guest

#14

14.09.2017 01:17:00

Спасибо за информацию, firefi. Да, было бы лучше, если бы я мог настроить один экземпляр как клиент (за двойным NAT), а тот, который на виду — как сервер. Похоже, такой вариант невозможен, но я собираюсь попробовать вариант клиент/сервер с PPTP VPN, чтобы посмотреть, смогу ли настроить это с правильной маршрутизацией (хочу, чтобы маршрутизация была двунаправленной).

firefi

Guest

#15

13.09.2017 18:59:00

Хмм… Думаю, проблема в том, что каждая сторона отправляет пакеты на тот порт, который настроен (по умолчанию 1194 для OVPN), даже если та, что за двойным NAT, отправляет пакет с исходящим портом X (который при двойном NAT переназначается дважды — это нормально) на порт 1194 у напрямую подключённой стороны. Прямое подключение будет отправлять пакеты обратно на порт 1194 у стороны с двойным NAT, хотя исходящие пакеты от неё имеют высокий порт, который открыт через настройки NAT. Понимаешь, о чём я? Вот почему это, вероятно, ломается.

Если бы это были две машины на Linux с полным контролем над конфигурацией ovpn, я бы подумал о переключении на TCP и настройке так, чтобы сторона с двойным NAT была клиентом, который всегда обращается к публичному IP удалённой стороны, а та — просто сервер, который слушает. Тогда всё бы работало, так как TCP-ответы маппятся обратно на исходный порт через оба NAT на стороне с двойным NAT. Поскольку UDP-пакеты всегда идут на выделенный порт, на стороне с двойным NAT нужно делать проброс портов — дважды: сначала на роутере, которым ты не управляешь, и снова на том, что контролируешь (или, если это USG, то оно само держит порт 1194 или тот, что задан, открытым на WAN-интерфейсе, так что с этим всё в порядке).

Отстой, конечно, но если у тебя кабельный модем или DSL в режиме «роутера», нужно переключить его в режим моста (bridge mode). Даже при DHCP от провайдера поддержка динамического DNS на USG отличная — можно использовать DNS-имя для публичных адресов конечных точек туннеля, так что при смене публичного IP туннель продолжит работать. Я успешно настраивал это на объекте, где надо было управлять удалённым hotspot-менеджером и выдавать ваучеры на кемпинге, не выезжая туда.

Клиент владеет двумя кемпингами в разных частях города.

Удачи!

ChipH

Guest

#16

13.09.2017 13:35:00

Спасибо, firefi. К сожалению, я не могу контролировать роутер провайдера на стороне двойного NAT, поэтому проброс портов невозможен... Но это действительно обязательно, если USG, который находится в интернете, может принимать исходящие запросы на соединение с USG за двойным NAT?

Итак, сети настроены и работают, как обсуждалось в этом посте. Я пока не видел успешного установления соединения, но в логах интернет-доступного USG заметил повторяющуюся картину — он перезапускается каждую минуту:

Sep 13 09:32:54 HatGateway openvpn[9392]: Inactivity timeout (--ping-restart), restarting
Sep 13 09:32:54 HatGateway openvpn[9392]: SIGUSR1[soft,ping-restart] received, process restarting
Sep 13 09:32:54 HatGateway openvpn[9392]: Restart pause, 2 second(s)
Sep 13 09:32:56 HatGateway openvpn[9392]: Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sep 13 09:32:56 HatGateway openvpn[9392]: Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 13 09:32:56 HatGateway openvpn[9392]: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sep 13 09:32:56 HatGateway openvpn[9392]: Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 13 09:32:56 HatGateway openvpn[9392]: Socket Buffers: R=[294912->131072] S=[294912->131072]
Sep 13 09:32:56 HatGateway openvpn[9392]: UDPv4 link local (bound): [undef]
Sep 13 09:32:56 HatGateway openvpn[9392]: UDPv4 link remote: [AF_INET]IP:Port

То есть каждую минуту происходит таймаут... Это нормально или это другая проблема?

firefi

Guest

#17

13.09.2017 12:31:00

Я бы не стал ожидать изменений в настройках на USG — когда сайт с двойным NAT отправляет UDP-пакет на публичный IP другого сайта, он должен пройти через оба роутера с NAT и дойти до публичного IP другой стороны. На роутере, который владеет публичным IP той стороны, где есть двойной NAT (я предполагаю, что роутер с публичным IP — это первый NAT, а USG за ним — второй NAT), скорее всего, нужно настроить проброс порта OVPN с этого роутера на WAN IP USG, чтобы первый пакет, идущий на известный порт OVPN, доходил до USG за ним. Удачи!

ChipH

Guest

#18

13.09.2017 03:33:00

Это отлично объясняет настройку, спасибо. У меня есть один нюанс: один из моих USG находится за двойным NAT (то есть за другим роутером). Как нужно изменить конфигурацию, чтобы это работало с двойным NAT? Я смотрел похожие посты, но у меня никак не получается настроить. Буду признателен за любую помощь!

FifthEchelon Guest	#19 13.08.2017 20:58:00 Понятно, и сработало отлично. Спасибо!

firefi Guest	#20 11.08.2017 14:17:00 Попробую ответить: вам нужны всего две IP-адреса для туннельных интерфейсов, и этого достаточно, чтобы всё настроить. Нужно выбрать, какие подсети с удалённой стороны вы хотите сделать доступными — в этом примере я возьму LAN и обе VLAN для удалённого доступа. Я выбрал 10.0.0.1 и 10.0.0.2 для туннельных интерфейсов, вот пример настройки: На сервере USG Удалённый хост: FQDN или публичный статический IP клиента USG Удалённые подсети: добавьте 10.50.0.0/24, 10.50.10.0/24 и 10.50.20.0/24 Удалённый адрес: 10.0.0.2 Порт: 51194 Локальный адрес: 10.0.0.1 Порт: 51194 На клиенте USG Удалённый хост: FQDN или публичный статический IP сервера USG Удалённые подсети: добавьте 10.90.0.0/24, 10.90.10.0/24 и 10.90.20.0/24 Удалённый адрес: 10.0.0.1 Порт: 51194 Локальный адрес: 10.0.0.2 Порт: 51194 Когда туннель поднимется, стоит проверить /var/log/messages на вашем USG. Обычно я делаю так: egrep -i openvpn /var/log/messages Или просто пробую пропинговать удалённый адрес. На клиенте вы должны иметь доступ к любому устройству из 10.50.0.x, 10.50.10.x и 10.50.20.x. На сервере — к любому устройству из 10.90.0.x, 10.90.10.x и 10.90.20.x. Например, попробуйте пропинговать 10.50.0.1 с клиента. Удачи и всего хорошего!

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