Как включить ipsec на роутере

Обновлено: 05.07.2024

Обычно беспроводные роутеры используются для предоставления доступа к Интернет различным домашним устройствам. Но иногда требуется решить и в определенном смысле противоположную задачу – реализовать удаленный доступ к размещенным в домашней сети сервисам и системам. Традиционный вариант решения этой задачи обычно состоит из трех шагов – использовать сервис динамического DNS для автоматического определения внешнего IP-адреса роутера, назначить в параметрах сервиса DHCP роутера выделение фиксированного адреса для нужного клиента и создать правило трансляции портов для требуемого сервиса на этом клиенте. Заметим, что удаленный доступ в большинстве случаев возможен только при наличии «белого»/«внешнего» адреса на WAN-интерфейсе роутера (подробнее см. в статье), а DDNS может не требоваться, если ваш провайдер предоставляет фиксированный IP-адрес.

Правил трансляции портов часто вполне достаточно для реализации задачи, но у них есть определенные особенности. Например, в случае необходимости защиты передаваемой информации, вам потребуется решать этот вопрос для каждого соединения индивидуально. Вторая потенциальная проблема – ограничения в случае, когда программное обеспечение требует использования определенного номера порта, а серверов в локальной сети несколько. Кроме того, если сервисов и внутренних систем у вас много, то есть очевидные неудобства прописывания в роутер каждого правила трансляции.

В прошивках многих современных роутеров среднего и верхнего сегмента предусмотрен встроенный сервер VPN. Чаще всего он работает с протоколами PPTP и OpenVPN. Первый является популярным вариантом, который был разработан более 15-ти лет назад при участии крупных ИТ-компаний, включая Microsoft. Его клиент встроен во многие современные ОС и мобильные устройства, что упрощает реализацию. Однако считается, что в этом решении не очень хорошо решаются вопросы безопасности. Скорость защищенного соединения для этого протокола в зависимости от производительности платформы роутера обычно составляет 30-50 Мбит/с, на самых быстрых устройствах мы встречали и 80 Мбит/с (см. например статью).

OpenVPN является свободной реализацией VPN сходного возраста и выпускается по лицензии GNU GPL. Клиенты для него есть для большинства платформ, включая мобильные. Серверы можно встретить во многих альтернативных прошивках для роутеров, а также в оригинальных версиях от производителей оборудования. Минусом этого протокола является требование значительных вычислительных ресурсов для обеспечения высокой скорости работы, так что 40-50 Мбит/с можно получить только на решениях верхнего сегмента (см. например).

Еще один вариант, который чаще связывают с «серьезными» решениями безопасных сетевых коммуникаций, – IPsec (см. статью). Его история началась немного раньше и сегодня его можно встретить во многих продуктах удаленного доступа корпоративного уровня.

Тем не менее, относительно недавно его реализация появилась и в таком явно массовом оборудовании, как роутеры серии Zyxel Keenetic. Используемый в них программный модуль позволяет реализовать безопасные сценарии удаленного доступа, а также объединения сетей без сложных настроек. Кроме того, он совместим с решениями серии ZyWall. К плюсам этого производителя стоит отнести удобную базу знаний с подробными статьями о реализации типовых сценариев. По данной теме можно обратить внимание на статьи по объединению двух сетей и подключению клиента с Windows. Приводить подробные скриншоты настроек не имеет смысла, поскольку они есть по указанным ссылкам. Отметим только что все просто и понятно.

Учитывая ресурсоемкость используемых в данном сценарии алгоритмов, важным является вопрос производительности такого решения. Для его изучения были выбраны три модели роутеров последнего поколения – топовые Keenetic Ultra II и Keenetic Giga III, а также бюджетный Keenetic Start II. Первые два имеют процессоры MediaTek серии MT7621, по 256 МБ оперативной памяти и по 128 МБ флэшпамяти, гигабитные сетевые порты, два диапазона Wi-Fi, поддержку 802.11ac, порт USB 3.0. При этом в старшей используется чип с двумя ядрами, работающими на частоте 880 МГц, а во второй – такой же чип, но только с одним ядром. А третий роутер оборудован 100 Мбит/с портами (причем в количестве двух штук – один WAN и один LAN) и однодиапазонным беспроводным модулем. Процессор в нем используется MT7628N с одним ядром и частотой 575 МГц, а объем оперативной памяти составляет 64 МБ. С точки зрения программных возможностей, связанных с IPsec, устройства не отличаются.

На все три роутера были установлены прошивки из ветки бета версий v2.07(xxxx.2)B2. Режим подключения к сети Интернет на всех устройствах выбирался самый простой – IPoE. Работа с другими вариантам, скорее всего, приведет к снижению результатов. На следующих двух графиках приводятся результаты тестирования пар с разными настройками параметров соединения – Ultra II и Giga III, Ultra II и Start II. В первой устройства в целом сравнимы по скорости (правда у старшего два ядра), а во второй ограничения будут от младшей модели. Направление указано относительно второго устройства. Использовались сценарии передачи, приема и одновременной передачи и приема данных между подключенными к роутерам клиентами.

Как мы видим, скорости здесь достаточно низкие и даже не дотягивают до 100 Мбит/с. При этом нагрузка на процессор во время активного обмена данными очень высока, что может иметь негативные последствия и для других решаемых устройством задач.

Однако, как мы помним по другим сходным ресурсоемким сценариям (например, обработке видео), существенный рост производительности на специализированных задачах можно получить благодаря использованию выделенных блоков чипов, «заточенных» на эффективную работу с определенными алгоритмами. Что интересно, в современных SoC от MediaTek такие как раз присутствуют и программисты компании в недавних обновлениях прошивок реализовали эту возможность.

При этом максимальный эффект можно получить на чипах MT7621 и RT6856, а на MT7628 поддерживаются не все режимы. Посмотрим, что изменится при использовании данного блока. Для его включения используем команду в консоли, как на скриншоте.

Старшая пара показывает скорость в 200 Мбит/с и более, что еще раз подтверждает правильность идеи создания специализированных блоков для определенных стандартных алгоритмов, которые существенно производительнее универсальных ядер.

Для младшей однокристальной системы эффект менее заметен, но и здесь можно отметить увеличение скорости в два раза для некоторых конфигураций.

Посмотрим теперь, насколько хорошо устройства справятся с обслуживанием подключений с достаточно быстрого компьютера с процессором Intel Core i5 и ОС Windows 8.1 x64 (описание настройки соединения доступно по ссылке выше). В роли условных серверов (в соединениях IPsec участники в определенном смысле равноправны) выступили старший Keenetic Ultra II и младший Keenetic Start II.

Топовый роутер в некоторых конфигурациях разгоняется более чем до 300 Мбит/с. Так что видимо второе ядро процессора помогает и в этом сценарии. Впрочем, на практике для достижения этих результатов вам понадобится и соответствующие Интернет-каналы.

Результаты Keenetic Start II по понятным причинам практически не отличаются от того, что мы видели выше.

Стоит заметить, что использование оптимизации не сказалось на стабильности соединения. Все участники успешно выдержали все тесты без каких-либо замечаний.

Проведенные тесты еще раз подтвердили, что современные продукты сегмента ИТ представляют собой программно-аппаратные комплексы и эффективность решения ими поставленных задач существенно зависит не только от установленного «железа», но и эффективной программной реализации его возможностей.

Пока я проводил тесты, оказалось, что компания в последних отладочных прошивках серии 2.08 для энтузиастов реализовала еще одну полезную возможность, позволяющую использовать сервис IPsec с мобильными клиентами. Описанный выше сценарий создания профиля соединения требовал постоянных IP-адресов с двух сторон соединения, что для смартфонов в обычных ситуациях не встречается. Подробности и инструкции можно прочитать в этих ветках: Android, iOS/OS X, Windows (Cisco VPN Client).

В настоящий момент этот режим не полностью поддерживается в Web-интерфейсе, однако это не помешало провести несколько быстрых тестов с Keenetic Giga III. С Apple iPhone 5S реальная скорость составила 5-10 Мбит/с в зависимости от направления, а Xiaomi Mi5 оказался побыстрее – 10-15 Мбит/с (оба устройства подключались через Wi-Fi). Штатный клиент Cisco IPsec в OS X 10.11 на современной системе показал 110 Мбит/с на передачу и 240 Мбит/с на прием (при использовании гигабитной локальной сети и с учетом описанной выше операции по настройке роутера в консоли). Windows с известным, хотя и уже не поддерживающимся клиентом Cisco VPN Client, работала также достаточно быстро – 140 Мбит/с на передачу и 150 Мбит/с на прием. Таким образом, данная реализация IPsec явно может быть интересна широкому кругу пользователей для реализации быстрого и безопасного удаленного доступа к своей локальной сети с мобильных устройств и компьютеров из любой точки мира.

Изначально VPN планировался только для организации канала между мини-роутером родителей и домашним «подкроватным» сервером, по совместительству выступающим в роли маршрутизатора.

Спустя небольшой промежуток времени к этой компании из двух устройств добавился Keenetic.
Но единожды начав, остановиться оказалось сложно, и вскоре на схеме появились телефоны и ноутбук, которым захотелось скрыться от всевидящего рекламного ока MT_Free и прочих нешифрованных WiFi-сетей.

Потом у всеми любимого РКН наконец-то окреп банхаммер, которым он несказанно полюбил прилюдно размахивать во все стороны, и для нейтрализации его заботы о простых смертных пришлось ~~поддержать иностранный IT-сектор~~ приобрести VPS за рубежом.

К тому же некоей гражданке, внешне напоминающей Шапокляк, всюду бегающей со своим ~~ридикюлем~~ Пакетом и, вероятно, считающей что «Кто людям помогает — тот тратит время зря. Хорошими делами прославиться нельзя», захотелось тайком подглядывать в чужой трафик и брать его на карандаш. Придется тоже защищаться от такой непрошенной любви и VPN в данном случае именно то, что доктор прописал.

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

Объединить сети между Linux-маршрутизаторами
Построить туннель между Linux и бытовым Keenetic
Дать доступ к домашним ресурсам и интернету носимым устройствам (телефоны, ноутбуки) из недоверенных сетей
Создать надежно зашифрованный туннель до удаленной VPS

Обзор существующих решений

Коротко пройдемся по тому что есть сейчас:

Дедушка Ленин всех протоколов. Умер, «разложился на плесень и на липовый мёд».

Кто-то, кроме одного провайдера, это использует?

Проект развивается. Активно пилится. Легко создать туннель между двумя пирами, имеющими статический IP. В остальных случаях на помощь всегда готовы придти костыли, велосипеды с квадратными колёсами и синяя изолента, но это не наш путь.

Поддержка множества платформ — Windows, Linux, OpenWRT и её производные, Android
Стойкое шифрование и поддержка сертификатов.
Гибкость настройки.

Работа целиком и полностью в user-space.
Ограниченная поддержка со стороны домашних машрутизаторов — кривенько-косенько на Mikrotik (не умаляя остальных достоинств железок) и нормально в OpenWRT.
Сложности с настройкой мобильных клиентов: нужно скачивать, либо создавать свой инсталлятор, копировать куда-то конфиги.
В случае наличия нескольких туннелей ждут танцы с правкой systemd-юнитов на сервере.

Относительно широкая поддержка различных платформ — Windows, Android, Mac на базе родного приложения Cisco Anyconnect из магазина — идеальный вариант предоставить доступ ко внутренней сети носимым устройствам.
Стойкое шифрование, поддержка сертификатов, возможность подключения 2FA
Сам протокол полностью TLS-based (в отличие от OpenVPN, который легко детектится на 443 порту). Кроме TLS поддерживается и DTLS — во время установленного сеанса клиент может переключится на передачу данных через UDP и обратно.
Прекрасное сосуществование на одном порту как VPN, так и полноценного web-сервера при помощи sniproxy.
Простота настройки как сервера, так и клиентов.

Работа целиком и полностью в user-space.
TCP поверх TCP плохая идея.
Поддержки со стороны customer-grade оборудования нет.
Сложность установки туннелей между двумя Linux: теоретически можно, практически — лучше потратить время на что-то более полезное.
В случае наличия нескольких туннелей ждут танцы с несколькими конфигами и правкой systemd-юнитов.

IKEv2 IPSEC

Необходимо потратить немного времени на изучение и понять как это работает
Особенность, которая может сбить с толку новичка: IPSec, в отличие от привычных VPN решений, не создает сетевые интерфейсы. Задаются только политики обработки трафика, всё остальное разруливается средствами firewall.

Приступаем к настройке

Определившись с решением приступаем к настройке. Схема сети в моем случае имеет следующий вид (убрал под спойлер)

Первый шаг. От простого к сложному: туннели с использованием pre-shared keys (PSK)

На обоих Linux-box устанавливаем необходимые пакеты:

На второй стороне аналогично:

В данном случае в качестве ID выступает вымышленный адрес элестронной почты. Больше информации можно подчерпнуть на официальной вики.

Секреты сохранены, движемся дальше.

Аналогично редактируем на удаленном пире /etc/strongswan/ipsec.conf:

Если сравнить конфиги, то можно увидеть что они почти зеркальные, перекрёстно поменяны местами только определения пиров.

Директива auto = route заставляет charon установить ловушку для трафика, подпадающего в заданные директивами left/rightsubnet (traffic selectors). Согласование параметров туннеля и обмен ключами начнутся немедленно после появления трафика, попадающего под заданные условия.

Рестартуем strongswan на обоих серверах и пробуем выполнить ping центрального узла:

Нелишним будет так же убедиться что в файле /etc/strongswan/strongswan.d/charon.conf на всех пирах параметр make_before_break установлен в значение yes. В данном случае демон charon, обслуживающий протокол IKEv2, при выполнении процедуры смены ключей не будет удалять текущую security association, а сперва создаст новую.

Шаг второй. Появление Keenetic

Приятной неожиданностью оказался встроенный IPSec VPN в официальной прошивке Keenetic. Для его активации достаточно перейти в Настройки компонентов KeeneticOS и добавить пакет IPSec VPN.

Готовим настройки на центральном узле, для этого:

Правим /etc/strongswan/ipsec.secrects и добавляем PSK для нового пира:

Правим /etc/strongswan/ipsec.conf и добавляем в конец еще одно соединение:

Со стороны Keenetic настройка выполняется в WebUI по пути: Интернет → Подключения →
Другие подключения. Всё довольно просто.

Если планируется через тоннель гонять существенные объемы трафика, то можно попробовать включить аппаратное ускорение, которое поддерживается многими моделями. Включается командой crypto engine hardware в CLI. Для отключения и обработки процессов шифрования и хеширования при помощи инструкций CPU общего назначения — crypto engine software

После сохранения настроек рестрартуем strongswan и даём подумать полминуты Keenetic-у. После чего в терминале видим успешную установку соединения:

Шаг третий. Защищаем мобильные устройства

После чтения стопки мануалов и кучи статей решено было остановиться на связке бесплатного сертификата от Let's Encrypt для проверки подлинности сервера и классической авторизации по логину-паролю для клиентов. Тем самым мы избавляемся от необходимости поддерживать собственную PKI-инфраструктуру, следить за сроком истечения сертификатов и проводить лишние телодвижения с мобильными устройствами, устанавливая самоподписанные сертификаты в список доверенных.

Устанавливаем недостающие пакеты:

Получаем standalone сертификат (не забываем предварительно открыть 80/tcp в настройках iptables):

После того как certbot завершил свою работу мы должны научить Strongswan видеть наш сертификат:

Перезапускаем Strongswan и при вызове sudo strongswan listcerts мы должны видеть информацию о сертификате:

После чего описываем новое соединение в ipsec.conf:

Не забываем отредактировать файл /etc/sysconfig/certbot указав, что обновлять сертификат тоже будем как standalone, внеся в него CERTBOT_ARGS="--standalone".

Так же не забываем включить таймер certbot-renew.timer и установить хук для перезапуска Strongswan в случае выдачи нового сертификата. Для этого либо размещаем простенький bash-скрипт в /etc/letsencrypt/renewal-hooks/deploy/, либо еще раз редактируем файл /etc/sysconfig/certbot.

Перезапускаем Strongswan, включаем в iptables маскарадинг для сети 10.1.1.0/24 и переходим к настройке мобильных устройств.

Android

Устанавливем из Google Play приложение Strongswan.

Запускаем и создаем новый

Сохраняем профиль, подключаемся и, спустя секунду, можем не переживать о том, что кто-то сможет подсматривать за нами.

Windows

Windows актуальных версий приятно удивил. Вся настройка нового VPN происходит путем вызова двух командлетов PowerShell:

И еще одного, в случае если Strongswan настроен на выдачу клиентам IPv6 адреса (да, он это тоже умеет):

Часть четвертая, финальная. Прорубаем окно в Европу

Считаем что VPS подготовлена, Strongswan и Certbot уже установлены.

Поднимаем интерфейсы, но поскольку в iptables нет правила, разрешающего GRE-протокол, трафик ходить не будет (что нам и надо, поскольку внутри GRE нет никакой защиты от любителей всяких законодательных «пакетов»).

Готовим VPS

Правим ipsec.secrets, внося в него единственную строку:

Конфиги почти зеркальные. Внимательный читатель мог сам уже обратить внимание на пару моментов:

И на стороне хоста ipsecgw

Туннель установлен, пинги ходят, в tcpdump видно что между хостами ходит только ESP. Казалось бы можно радоваться. Но нельзя расслабляться не проверив всё до конца. Пробуем перевыпустить сертификат на VPS и…

Шеф, всё сломалось

Начинаем разбираться и натыкаемся на одну неприятную особенность прекрасного во всём остальном Let's Encrypt — при любом перевыпуске сертификата меняется так же ассоциированный с ним закрытый ключ. Изменился закрытый ключ — изменился и открытый. На первый взгляд ситуация для нас безвыходная: если даже открытый ключ мы можем легко извлечь во время перевыпуска сертификата при помощи хука в certbot и передать его удаленной стороне через SSH, то непонятно как заставить удаленный Strongswan перечитать его. Но помощь пришла откуда не ждали — systemd умеет следить за изменениями файловой системы и запускать ассоциированные с событием службы. Этим мы и воспользуемся.

Создадим на каждом из хостов служебного пользователя keywatcher с максимально урезанными правами, сгенерируем каждому из них SSH-ключи и обменяемся ими между хостами.

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

Скрипт pubkey-copy.sh нужен для извлечения открытой части ключа и копирования его удаленному хосту во время выпуска нового сертификата. Для этого в каталоге /etc/letsencrypt/renewal-hooks/deploy на обоих серверах создаем еще один микроскрипт:

Половина проблемы решена, сертификаты перевыпускаются, публичные ключи извлекаются и копируются между серверами и пришло время systemd с его path-юнитами.

Аналогично на VPS хосте:

И, напоследок, на каждом сервере создаем ассоциированную с данным юнитом службу, которая будет запускаться при выполнении условия (PathChanged) — изменении файла и его закрытии его после записи. Создаем файлы /etc/systemd/system/keyupdater.service и прописываем:

Не забываем перечитать конфигурации systemd при помощи sudo systemctl daemon-reload и назначить path-юнитам автозапуск через sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater.path.

Как только удаленный хост запишет файл, содержащий публичный ключ, в домашний каталог пользователя keywatcher и файловый дескриптор будет закрыт, systemd автоматически запустит соответствующую службу, которая скопирует ключ в нужное расположение и перезапустит Strongswan. Туннель будет установлен, используя правильный открытый ключ второй стороны.

Можно выдохнуть и наслаждаться результатом.

Вместо заключения

Как мы только что увидели ~~чёрт~~ IPSec не так страшен, как его малюют. Всё, что было описано — полностью рабочая конфигурация, которая используется в настоящее время. Даже без особых знаний можно настроить VPN и надежно защитить свои данные.

Конечно за рамками статьи остались моменты настройки iptables, но и сама статья уже получилась и без того объемная и про iptables написано много.

Есть в статье и моменты, которые можно улучшить, будь-то отказ от перезапусков демона Strongswan, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.

Впрочем и рестарты демона оказались не страшны: происходит потеря одного-двух пингов между пирами, мобильные клиенты тоже сами восстанавливают соединение.

Интернет, наполненный духом свободы, становится все более и более контролируемым — провайдеры блокируют все подряд на свое усмотрение, поисковые системы следят за каждым вашим шагом, да и злоумышленники не дремлют. Неудивительно, что многие задумываются о том, чтобы обойти ограничения, вернувшись во времена «свободного Интернета». И VPN — один из таких способов.

Что такое VPN и зачем он нужен

VPN (Virtual Private Network, виртуальная частная сеть) — технология, позволяющая организовать локальную сеть поверх другой сети (чаще всего интернета). Чтобы пояснить, приведем такой пример. Допустим, вы военнослужащий срочной службы и хотите написать письмо девушке. Вы не собираетесь выдавать каких-либо секретов, но вам наверняка будет неприятно, что вашу переписку будут читать военные цензоры. Поэтому вы идете к прапорщику Семенову и договариваетесь с ним, что он будет отправлять ваши письма с городского почтового ящика. Семенов предлагает также, чтобы девушка писала ответы на адрес его городской квартиры, а он будет носить эти письма вам. Таким образом, прапорщик организовал виртуальную частную почту поверх обычной почты.

VPN-сервисы делают то же самое, подменяя ваш IP-адрес адресом своего сервера, зачастую расположенного в другой стране. Трафик между вами и VPN-сервером зашифрован, поэтому никто, даже ваш провайдер, не сможет определить, на какие сайты вы ходили и что там делали. Минус такой схемы в том, что бесплатные VPN-сервисы не отличаются высокой скоростью, да и уровень предоставляемой ими конфиденциальности зачастую сомнителен. А надежные и высокоскоростные VPN-сервисы требуют хоть и небольшой, но регулярной оплаты — в среднем, 2-5 долларов в месяц. Ну, так ведь и прапорщик Семенов вряд ли будет носить чужие письма «за спасибо».

Зачем подключать роутер к VPN

Подключить компьютер к VPN несложно. Вам не нужно разбираться, «как все устроено», достаточно скачать с сайта провайдера VPN-сервиса специальную утилиту, запустить ее, ввести полученные при регистрации логин/пароль — и все. Но при этом «свободный Интернет» будет только на этом компьютере. Все остальные устройства — пусть даже и подключенные к тому же роутеру — будут по-прежнему «под колпаком». Можно, конечно, установить ту же утилиту на все остальные компьютеры, а на смартфоны — аналогичные мобильные приложения (которые тоже можно скачать с сайта провайдера сервиса). Но это слишком хлопотно, намного удобнее подключить через VPN сам роутер. Правда, тут уже потребуется немного разобраться.

Во-первых, не всякий роутер в принципе может работать VPN-клиентом. Если настроить подключение не удается, то вполне возможно, что прошивка вашего роутера просто не позволяет подключаться к VPN-серверу поверх обычного интернета. В этом случае можно воспользоваться альтернативной прошивкой для роутеров DD-wrt или Tomato, но это потребует определенных знаний и навыков.

Во-вторых, многие, способные подключаться к VPN, роутеры предлагают небольшой выбор протоколов для подключения (OpenVPN, PPTP, L2TP и т.д.), а иногда выбора нет вообще и доступный протокол только один. Если вы подсоединяетесь к определенному VPN-серверу, убедитесь, что у него найдется хотя бы один общий протокол с вашим роутером.

Как подключить роутер к VPN

Зайдите в веб-интерфейс роутера, как это описано в руководстве по эксплуатации (обычно он находится по адресу 192.168.0.1 или 192.168.1.1). Если в меню найдется раздел «VPN-клиент», воспользоваться следует именно им — ваш роутер подготовлен для работы с VPN, и никаких проблем не предвидится.

Если такого раздела нет, попробуйте создать новое WAN-подключение. Для этого надо найти пункт меню «WAN» или «Internet». Иногда этот пункт расположен в корневом меню, иногда — в разделах «Connections», «Network» или «Settings». На открывшейся странице следует создать новое подключение и выбрать необходимый протокол.

Если вариантов выбора больше одного (и VPN-сервер, и роутер имеют несколько общих протоколов), то имейте в виду, что OpenVPN считается более безопасным, но он довольно сильно нагружает процессор роутера и может снижать скорость соединения.

При выборе PPTP и L2TP вам потребуется ввести данные, полученные от VPN-сервиса при регистрации: адрес сервера, пароль и логин. Иногда также требуется ввести IP-адреса DNS-серверов. Также следует задать получение IP-адреса от сервера (Dynamic IP).

Поищите на сайте VPN-сервиса описание настроек роутеров — даже если вашей модели там нет, посмотрите какие именно параметры требуется ввести.

При выборе OpenVPN вам может потребоваться загрузить конфигурационный файл с расширением .ovpn — он содержит настройки, относящиеся к конкретному серверу. Этот файл также можно загрузить с сайта VPN-сервиса.

Сохраните настройки и дождитесь подключения к WAN (возможно, потребуется перезагрузка роутера). Если подключения не происходит, попробуйте отключить в настройках роутера IPv6, найти опцию VPN Passthrough и убедиться, что она включена или отключить NAT для клиентов.

IPsec (сокращение от IP Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP. Позволяет осуществлять подтверждение подлинности (аутентификацию), проверку целостности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет. Ознакомиться более подробнее можно в статье IPSec.

Довольно часто данный протокол используют между шлюзами для защиты туннелей, организованных каким-нибудь другим способом. Например: L2TP, GRE.

В нашем примере, мы будем использовать туннель IPsec в "чистом" варианте.

Настройка IPsec на базе OpenWrt

Данный вид шифрования настраивается зеркально на обоих устройствах на базе операционной системы OpenWrt.

Cхема работы IPsec представлена на картинке:

Шифрование осуществляется поверх установившегося соединения. Перейдем к основным настройкам туннеля.

1.1 Основные настройки IPsec

В WEB-интерфейсе перейдем в меню "Сервисы (Services)" - "IPsec", после чего создадим новую конфигурацию.

Далее зададим основные параметры туннеля, нажимаем кнопку "Редактировать (Edit)"

В открывшемся окне ставим галочку "Включить (Enable)" и настраиваем параметры туннеля:

IKE version (Версия IKE) - протокол, связывающий компоненты IPsec, и заставляющий работать все как единое целое. Существует две версии протокола IKE: IKEv1 и IKEv2.

Mode (Режим) - данный параметр доступен только для протокола IKEv1. Рекомендуется использовать Main.

My identifier type (Тип локального идентификатора) - идентификаторы для локального устройства, в зависимости от типа идентификатора: FQDN (полностью квалифицированное доменное имя), User FQDN (пользовательское, по user@dns), а также по Address (адрес WAN-интерфейса).

My identifier (Локальный идентификатор)- IP-адрес устройства, используемый для установки соединения

Remote identifier type (Удаленный идентификатор) - идентификатор для удаленного устройства.

Pre shared key (Общий ключ) - ключ для аутентификации, задается произвольным.

Remote VPN endpoint (удаленная точка туннеля) - адрес сервера, с которым будет поднят туннель.

Local IP addres/Subnet mask (Локальная подсеть/маска подсети) - локальный IP-адрес устройства.

Remote IP addres/Subnet mask (Удаленная подсеть/маска подсети) - локальный удаленный адрес сервера, локальные сети должны различаться.

Enable keepalive (Включить поддержку активности) - рекомендовано включить, повышает отказоустойчивость.

Host - I P-адрес, на который будут направляться ICMP-запросы (ping).

Ping period (sec) - устанавливаем частоту ICMP-запросов.

1.2 Настройка фазы аутентификации и шифрования

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

Phase 1:

Phase 2:

Encryption algorithm - необходимо выбрать алгоритм шифрования

Authentication - метод аутентификации

DH group - Группа Диффи-Хеллмана

Lifetime - Продолжительность фазы

Основные настройки применены! Осталось нажать на кнопку "Save & Apply" (Сохранить и применить).

1.3 Проверяем статус туннеля

Чтобы просмотреть статус работы туннеля IPsec, подадим в консоль роутера команду:

Читайте также: