Виртуальная частная сеть для удаленного оборудования

Однажды к нам прилетел интересный запрос: необходимо обеспечить резервирование каналов связи (2х3G/4G и/или Ethernet+3G/4G) для подключения серверов к удаленному оборудованию, которые работают по принципу запрос-ответ, и обязательное условие – обеспечить постоянный статический IP адрес для подключения к каждой единице оборудования.

Имея большой опыт организации удаленной работы для различных компаний в наше ковидное время и, после внутреннего мозгового штурма, была рождена концепция:

1. Создаем закрытую виртуальную сеть на базе нашего действующего решения

2. Подключаем в нее сервера заказчика

3. Подключаем оборудование

4. Назначаем статические адреса всем

Концепция согласована и утверждена и начинается самое интересное:

1. Почему VPN? Потому что далеко не на всех объектах Заказчика можно было вообще организовать статический IP и даже динамический, при использовании каналов 3-х лиц. А так при включении резервного канала IP будет изменен, что потребует ручной перенастройки сервера, и так каждый раз при смене IP

2. Нужен роутер, который умеет:

a. переключаться между каналами в случае недоступности основного;

b. каждый раз восстанавливать VPN соединение;

c. поддерживать статический IP на виртуальном интерфейсе VPN;

d. поддерживать NAT с пробросом портов на том же виртуальном интерфейсе;

Эта задача нам не казалось сложной, как оказалось – мы сильно ошибались. Изучив ТТХ с десяток роутеров – мы выбрали лучшие варианты, как нам казалось, и приступили к испытаниям:

Основная масса роутеров ставит VPN интерфейс на тот же уровень, что и основные интерфейсы и не позволяет настроить резервирование на связку 2х3G/4G или Ethernet+3G/4G, а потом осуществить подключение VPN. Как только мы настраивали VPN – он появлялся в общем списке и ПО роутера предлагала настраивать связки для резервирования VPN+3G/4G и VPN+Ethernet. Такие особенности не позволяли реализовать концепцию, которую мы согласовали и в целом мы не до конца поняли, как применять такой подход.

Вторая часть роутеров имела крайне кастрированные настройки для VPN соединений либо вообще роутеры стабильно могли работать только по своим проприетарным протоколам в связке с железом того же производителя на другой стороне.

Отдельная эпопея была со статическими адресами, но об этом чуть ниже.

Наступил момент истины – мы нашли нужный роутер. На длительный тест у нас остался один претендент, чему мы были несказанно рады. Потому что мы уже начинали терять надежду подобрать рабочее решение за адекватные деньги - Заказчик не готов был платить 50+ тысяч рублей за роутер.

Что мы получили – роутер умеет:

1. Гибко настраивать резервирование как 2х3G/4G, так и Ethernet+3G/4G

2. До бесконечности пытаться переподключаться к VPN

3. Умеет маршрутизировать весь трафик в VPN

4. Позволяет настраивать NAT на VPN интерфейс

5. Не умеет настраивать статический IP на стороне роутера (мы посчитали это не существенным и так же за это поплатились)

Далее мы:

1. Настроили отдельный хаб на своем VPN сервере, настроили DHCP c резервированием IP адресов по MAC.

2. Настроили роутер: резервирование, NAT, пробросили необходимые порты и т.д.

Связка заработала, и мы тестировали разные режимы более 2-х недель – всё было отлично.

Добавили в эту связку еще один роутер и опять всё отлично. Суммарно 4 недели тестов без нареканий в нашей лаборатории и принимается решение провести тесты на стороне Заказчика сначала на 2-х доступных модемах и добавить еще 3-й по мере его поставки.

Два модема были размещены на реальных объектах и так началась большая опытная эксплуатация, которая планировалась на срок не менее 2-х месяцев. В целом железо работало хорошо. Добавили 3-й модем и опять все хорошо. Мы искренне радовались, что смогли собрать решение, которое на 100% удовлетворяет Заказчика.

Но, примерно, на 3-ю неделю испытаний произошло странное: модем 2 и 3 поменялись IP адресами, что было критично для Заказчика, потому что начали поступать некорректные данные на сервера. Мы начали проверки всех систем и логов и результат был не радужный.

Что произошло:

1. Модем 2 и 3 на какое-то время отключались от сети по электропитанию

2. Модем 3 вернулся в сеть раньше 2

3. Модем 3 на интерфейсе VPN представился MAC адресом 2 модема

4. Соответственно DHCP отдал IP, который был привязан к этому MAC адресу

5. Модем 2 представился MAC от 3-го модема и т.д.

Эта была катастрофа, т.к. мы не могли гарантировать статический адрес, что было основным требованием Заказчика.

Два роутера были возвращены в нашу лабораторию, и мы начали воспроизводить выявленную проблему:

Логика роутера была проста:

1. Если роутер первый в сети, то он присваивает себе на VPN интерфейсе MAC XX:XX:XX:XX:XX:XX:XX

2. Если в сети есть MAC XX:XX:XX:XX:XX:XX:XX, то роутер присвоит MAC вида XX:XX:XX:XX:XX:XX:XY и т.д.

3. И так при каждом подключении к VPN

Т.е. при восстановлении связи роутер принимает первый свободный MAC и DHCP присваивает ему соответствующий IP адрес…

После мозгового штурма была обозначено 3 направления, куда стоит попробовать двигаться:

1. Разворачивание альтернативного VPN сервера, который позволит привязывать IP к аккаунту (мы его успели развернуть и протестировать);

2. Подбор нового оборудования и весь процесс тестирование заново;

3. Доработка логики работы текущего роутера.

Соответственно т.к. сроки горели мы начали прорабатывать все 3 направления сразу. В последний пункт мы верили слабо, но написали большое письмо в службу поддержки китайского производителя и начали активно работать по пункту 1 и 2. Был развернут новый VPN сервер c нужно функциональностью, так же заказаны несколько новых роутеров и… Мы получили ответ от вендора с радостной новостью, что они реализовали функцию статического IP адреса в новых прошивках для другого проекта и с радостью с нами поделятся данной прошивкой!

Проекту уже год – полет нормальный. Подключаем новые объекты.

Спасибо, кто дочитал до конца.

Теперь у нас есть интересное решение для подключения удаленного оборудования