Protocol 50 esp как разрешить

Обновлено: 16.05.2024

У меня есть брандмауэр / маршрутизатор (не делает NAT).

Я гуглил и видел противоречивые ответы. Кажется, UDP 500 является распространенным. Но другие сбивают с толку. 1701, 4500.

И некоторые говорят, что мне нужно также разрешить gre 50, или 47, или 50 & 51.

Хорошо, какие порты являются правильными для IPSec / L2TP для работы в маршрутизируемой среде без NAT? т.е. я хочу использовать встроенный клиент Windows для подключения к VPN за этим маршрутизатором / брандмауэром.

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

Вот порты и протоколы:

Протокол: UDP, порт 500 (для IKE, для управления ключами шифрования)
Протокол: UDP, порт 4500 (для режима IPSEC NAT-Traversal)
Протокол: ESP, значение 50 (для IPSEC)
Протокол: AH, значение 51 (для IPSEC)

Кроме того, порт 1701 используется сервером L2TP, но соединения не должны разрешать входящие к нему извне. Существует специальное правило брандмауэра, разрешающее входящий трафик только через IPSEC на этот порт.

Если вы используете IPTABLES, а ваш L2TP-сервер находится прямо в Интернете, то вам нужны следующие правила:

Где $EXT_NIC находится имя вашей внешней сетевой карты, например, ppp0.

Я обнаружил, что мне не нужны ESP и AH, так как я не использую IPSEC напрямую, а IPSEC через L2TP с NAT. Так что я могу сойти с портов 500, 500, 1701. Интересный комментарий о специальном правиле для 1701. Мне нужно будет попробовать это, как только я выясню, как настроить его с Mikrotik.

Ipsec нужен UDP-порт 500 + протокол ip 50 и 51 - но вместо этого вы можете использовать NAt-T, для которого нужен UDP-порт 4500. С другой стороны, L2TP использует порт 1701 udp. Если вы пытаетесь пропустить трафик ipsec через «обычный» Wi-Fi -Fi роутер, и нет такой опции, как сквозной IPSec, я рекомендую открыть порты 500 и 4500. По крайней мере, так работает на моем. Надеюсь это поможет.

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

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

Первый шаг. От простого к сложному: туннели с использованием 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. Туннель будет установлен, используя правильный открытый ключ второй стороны.

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

Какие VPN поддерживает Zyxel и почему

На данный момент оборудованием Zyxel поддерживаются следующие протоколы и соответствующие сценарии удалённого подключения:

IPSec VPN (ZyWALL IPSEC VPN Client / SecuExtender v3.8.XX или любой другой);
L2TP over IPSec VPN (встроенный клиент в Windows, Android и MacOS, iOS);
SSL VPN (SecuExtender v4.0.2.0 и v4.0.3.0).

Примечание. Ещё один протокол — OpenVPN применяется в мультигигабитных WiFi роутерах Armor G1/G5.

Разберём каждый пункт по порядку.

IPSec VPN

IPSec (сокращение от IP Security) — семейство протоколов защиты информации для последующей передачи по межсетевому протоколу IP.

IPSec VPN over ZyWALL IPSec VPN Client — это самый безопасный вариант туннеля из описываемых в данной статье.

Преимущества IPSec VPN

Имеет разные возможности настройки шифрования VPN туннеля (при использовании соответствующего ПО). IPSec VPN Client позволяет выбрать различные алгоритмы шифрования, контролировать нагрузку на туннель, и обеспечить высокую безопасность в отличие от L2TP over IPSec VPN.

Основные используемые порты и номера протоколов, которые необходимо разрешить для IPSec:

Протокол UDP, port 500 (IKE, управление ключами)
Протокол UDP, port 4500 (IPSEC NAT-Traversal mode)
Протокол ESP, значение 50 (for IPSEC)
Протокол AH, значение 51 (for IPSEC)

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

Ограничения IPSec VPN

В данной ситуации требуется платная лицензия для компьютеров с Windows и MAC.

Примечание. IPSec VPN по умолчанию не заворачивает весь клиентский трафик в VPN туннель. Это полезно, когда для удалённых клиентов нужны такие настройки «из коробки», чтобы не нагружать сторонним Интернет-трафиком корпоративный VPN туннель.

L2TP over IPSec VPN

L2TP VPN это старый-добрый вариант подключения, известный, например, администраторам Microsoft ISA сервер. Сам по себе L2TP не имеет средств защиты, но существует возможность переложить эту функцию на плечи другого протокола шифрования‑IPSec (IP Security). Это позволяет использовать L2TP over IPSec в различных сценариях, многие платформы предлагают интегрированное программное обеспечение и драйверы L2TP клиента. Комбинацию L2TP и IPSec называют L2TP/IPSec (RFC3193).

L2TP over IPSec VPN может быть легко связан с Active Directory.

Порты и протоколы, которые необходимо разрешить для L2TP/IPSec:

порт 1701 (UDP) используется в качестве порта отправителя и получателя для инициализации туннеля;
порт 500 (UDP) — для обмена ключами шифрования;
порт 4500 (UDP) — для операций NAT;
протокол 50 (ESP) для передачи зашифрованных данных через IPSec.

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

Ограничения L2TP over IPSec

Встроенные инструменты настройки L2TP over IPSec "из коробки" не всегда понятны начинающему пользователю (по сравнению с SecuExtender это выглядит сложнее). В то же время данный тип подключения можно настроить на большом числе клиентских устройств (в первую очередь это компьютеры с Windows) без необходимости покупать дополнительное ПО.

SSL VPN

Преимущества SSL VPN

Простота настройки и использования (достаточно скачать и настроить простую программу)

Ограничения SSL VPN

Для работы с этим типом VPN в нашем случае необходимо программное обеспечение SecuExtender (IPSec и SSL VPN клиент). Это облегчает настройку и позволяет упростить и унифицировать процесс подключения пользователей.

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

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

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

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

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

Записки IT специалиста

VPN — немного теории

Virtual Private Network (VPN) — общий термин для обозначения технологий, обеспечивающих безопасную передачу трафика средствами небезопасной сети, например, Интернет.

Как это работает

Стандартные средства TCP/IP «из коробки» не включают средств для защиты трафика. На помощь приходит VPN. Передаваемый трафик шифруется и заново инкапсулируется в формат, пригодный для передачи в небезопасной сети, например, в виде IP пакетов. В свою очередь на принимающей стороне трафик деинкапсулируется, дешифруется и поступает по целевому назначению.

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

Наиболее часто используют два варианта подключений:

site-to-site — соединяются удалённые сети;
client-to-site — подключение отдельных пользователей к удалённой сети.

Как было сказано выше, эта статья посвящена проблемам именно клиентских подключений.

Какие основные показатели влияют на выбор VPN

1. Надёжность. Тут всё просто — если передача данных постоянно прерывается, зачем нужен такой канал связи?

2. Защита от взломов и перехвата трафика. Собственно, для этого и создавали VPN. Однако принцип «чем сильнее, тем лучше» нужно применять с осторожностью. За усиление защиты, например, при использовании более криптостойкого алгоритма, придётся платить аппаратными ресурсами, быстродействием и так далее. Кроме заботы о безопасности никогда не помешает здравый смысл.

3. Распространённость. Вряд ли кто-то захочет использовать инструментарий, если про него практически никто не знает и не спешит поддерживать для своего ПО и оборудования.

4. Простота настройки. Помимо того, что время и силы системных администраторов не безграничны, ещё существует такой важный момент, как квалификация конечного пользователя. Если настройка выходит за рамки инструкции в 5 шагов — рано или поздно, администратор столкнётся с пользователем, который не сможет самостоятельно настроить VPN на своей стороне. В таких случаях приходится искать обходные пути, об этом речь пойдёт ниже.

5. Цена. Собственно, тот самый показатель, который может блокировать все благие намерения.

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

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

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

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

Проект развивается. Активно пилится. Легко создать туннель между двумя пирами, имеющими статический 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.

Такие разные клиентские VPN. Как Secure WiFi упрощает подключение пользователей

В этой статье мы поговорим о различных вариантах удалённого подключения пользователей по VPN. Рассмотрим варианты возможных VPN туннелей, поддерживаемые Zyxel, их преимущества и недостатки, а также новую технологию Secure WiFi упрощающую построение VPN каналов.

Настройка PPTP или L2TP VPN-сервера на роутерах Mikrotik

Продолжая актуальную сегодня тему удаленного доступа, сегодня мы рассмотрим настройку роутеров Mikrotik для использования из в качестве PPTP или L2TP VPN-серверов. С одной стороны тема эта, вроде бы простая, с другой, как обычно, имеет свои особенности, которые следует учитывать еще на стадии выбора решения. Ведь хороший специалист выбирает инструмент под задачу, а не пытается делать наоборот, признавая сильные и слабые стороны каждого решения.

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Перед тем, как браться за настройку VPN-сервера на базе Mikrotik мы рекомендуем вам ознакомиться с нашим материалом: Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование. Если коротко: на моделях без аппаратной поддержки AES вы не получите для соединений L2TP/IPsec скоростей более 25-30 МБит/с, на моделях с поддержкой AES скорость упирается в 35-50 МБит/с. В большинстве случаев для сценария удаленного доступа этого достаточно, но все-таки данный момент обязательно следует иметь ввиду, чтобы не получить потом претензию, что Mikrotik работает плохо и этому объективно будет нечего противопоставить.

Что касается PPTP, то здесь все достаточно хорошо, даже недорогие модели роутеров позволяют достигать скоростей около 100 МБит/с, но при этом следует помнить, что PPTP имеет слабое шифрование и не считается безопасным в современных реалиях. Однако он может быть неплохим выбором, если вы хотите завернуть в него изначально защищенные сервисы, например, при помощи SSL.

Предварительная настройка роутера

Прежде чем начинать настройку VPN-сервера нужно определиться со структурой сети и выделить для удаленных клиентов пул адресов. Если брать сценарий удаленного доступа, то здесь есть два основных варианта: Proxy ARP, когда клиенты получают адреса из диапазона локальной сети и имеют доступ к ней без дополнительных настроек и вариант с маршрутизацией, когда клиентам выдаются адреса из диапазона не пересекающегося с локальной сетью, а для доступа в сеть на клиентах добавляются необходимые маршруты. В современных Windows-системах это можно автоматизировать при помощи PowerShell.

После того, как вы определились со структурой сети, следует перейти в IP - Pool и создать новый пул адресов для выдачи удаленным клиентам. Количество адресов в пуле должно соответствовать количеству планируемых VPN-клиентов, либо превышать его.

Эти же действия в терминале:

Затем перейдем в PPP - Profiles и настроим профиль для нашего VPN-сервера, который будет содержать базовые настройки. Если вы настраиваете сразу и PPTP и L2TP-сервера, то можете использовать для них как общий профиль, так и создать отдельные. В случае с общим профилем они будут иметь общий адрес сервера и общий пул адресов. В данном разделе уже существуют два стандартных профиля default и default-encryption, поэтому при желании можете не создавать новые профили, а настроить имеющиеся.

На вкладке General задаем параметры: Local Address - локальный адрес сервера, должен принадлежать к тому же диапазону, что и пул адресов, который вы задали выше, Remote Address - адреса для выдачи удаленным клиентам, указываем в этом поле созданный пул.

Следящая вкладка - Protocols, здесь мы рекомендуем установить параметр Use Encryption в положение required, что будет требовать от клиента обязательного использования шифрования.

Чтобы добавить новый профиль в терминале выполните (в данном случае мы создаем профиль с именем vpn):

Чтобы изменить существующий default-encryption:

Для default вместо set *FFFFFFFE укажите set *0:

Остальные параметры оставляем без изменений, для удаленных клиентов они не применяются (в том числе сжатие) и работают только при соединении между устройствами с RouterOS. Отсутствие сжатия также следует учитывать, особенно если ваши клиенты используют медленные каналы подключения, скажем 3G-модемы.

Теперь добавим пользователей, для этого откроем PPP - Secrets и создадим новую учетную запись. Обязательно заполняем поля: Name и Password, а также Profile, где указываем созданный на предыдущем шаге профиль, если профили клиента и сервера не будут совпадать - подключение окажется невозможным. Поле Service позволяет ограничить действие учетных данных только одним сервисом, для этого нужно указать его явно, если же вы хотите использовать одни учетную запись для всех видов подключения - оставьте значение по умолчанию any.

В терминале:

При создании учетных данных уделите должное внимание политике паролей, особенно для PPTP.

Настройка PPTP-сервера

Настроить PPTP-сервер в RouterOS просто. Откройте PPP - Interface и нажмите кнопку PPTP Server, в открывшемся окне установите флаг Enabled, в поле Default Profile укажите созданный на подготовительном этапе профиль и в разделе Authentication оставьте только mschap2.

Это же действие в терминале:

Следующим шагом следует разрешить подключения к нашему VPN-серверу в брандмауэре, для этого следует разрешить входящие подключения для порта 1723 TCP. Открываем IP - Firewall и создаем новое правило: Chain - input, Protocol - tcp, Dst. Port - 1723, в поле In. Interface указываем внешний интерфейс роутера, в нашем случае ether1. Так как действие по умолчанию - accept то просто сохраняем правило.

В терминале создать правило можно командой:

На этом настройку PPTP-сервера можно считать законченной, он готов принимать подключения.

Настройка L2TP/IPsec -сервера

Точно также, как и при настройке PPTP-сервера переходим в PPP - Interface и нажмите кнопку L2TP Server. В открывшемся окне ставим флаг Enabled, в Default Profile указываем созданный ранее профиль, а в Authentication оставляем только mschap2. Затем включаем использование IPsec - Use IPsec - yes и в поле IPsec Secret вводим предварительный ключ соединения:

Для включения сервера с указанными настройками в терминале выполните:

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

Данные настройки в терминале:

Затем откроем IP - IPsec - Profiles и изменим настройки профиля default: Encryption Algorithm - aes256, DH Group - modp2048, ecp256, ecp384.

В терминале:

Для окончания настройки разрешим подключения к L2TP-серверу в брандмауэре. Для этого нам понадобится создать два правила, первое должно разрешать подключения для протоколов IKE (порт 500 UDP) и протокол NAT-T (порт 4500 UDP), второе для протокола 50 ESP (Encapsulating Security Payload). Переходим в IP - Firewall и создаем первое правило: Chain - input, Protocol - udp, Dst. Port - 500, 4500, в поле In. Interface указываем внешний интерфейс роутера, в нашем случае ether1. Затем второе: Chain - input, Protocol - ipsec-esp, In. Interface -внешний интерфейс (ether1). Так как действие по умолчанию accept достаточно просто сохранить правила.

Для терминала выполните следующие команды:

На этом настройка L2TP/IPsec-сервера закончена.

Secure WiFi — новое в клиентских подключениях

Что это такое и как работает

Сервис безопасности Secure WiFi— это построение L2 туннеля между точкой доступа и шлюзом посредством NVGRE over IPSec.

Работает и в Nebula (с USG FLEX), и с автономными шлюзами: USG FLEX, ATP, VPN.

Рисунок 1. Принцип работы Secure WiFi.

Более подробно об этом можно узнать из вебинаров:

Межсетевые экраны USG FLEX в централизованной системе управления Nebula Межсетевые экраны и точки доступа Zyxel: что нового в микропрограммах 5 00 и 6 20

Причины использования

Привычная схема «один клиент — одно устройство — одно подключение» является достаточно простой, но не всегда удобной.

Например, если у пользователя несколько устройств: стационарный ПК, ноутбук и ещё изредка использует планшет для чтения документов. Придётся выделять на VPN шлюзе на каждое устройство по выделенному каналу для подключения? Это хорошо, когда клиентов мало, а если их достаточно много и на счету каждый канал?

Это интересно. Услуга Secure WiFi увеличивает количество каналов для подключения до максимального значения (снимает ограничение) для межсетевых экранов ATP, USG FLEX и VPN.

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

Ещё один интересный момент, когда несколько сотрудников вынуждены работать на удалённой площадке, например, в другом здании. Приходится настраивать каждому VPN подключение, при том, что они сидят «бок о бок».

Ну, и наконец, весьма распространённый случай, когда пользователь не может сам выполнить настройки своего клиента, например, по причине конфликта с существующим ПО, устаревшей операционной системой и так далее. Можно запросто попасть в ситуацию, когда чтобы решить проблему с VPN клиентом пользователя, нужно подключить VPN канал, а, чтобы подключить VPN канал, нужно решить проблему с VPN клиентом.

В статье «Удалённая работа набирает обороты» мы уже описывали одно из решений подобных проблем. Смысл заключается в том, чтобы передать пользователю заранее настроенный недорогой роутер для создания VPN подключения. Однако набор функций роутера может оказаться избыточен, особенно если речь идёт о 1-2 устройствах. И далеко не так просто наладить работу второго роутера внутри домашней или офисной сети. Если пользователь обладает нужной квалификацией, тогда всё замечательно, а вот если не обладает и не может сам настроить?

Secure WiFi помогает решить подобные проблемы с меньшими затратами практически для любого пользователя.

Как выглядит процесс конфигурации доступа для Secure WiFi

На стороне администратора (центральный офис):

Настройка точек доступа в LAN;
Выбор туннельных точек доступа и SSID;
Конфигурация WAN IP шлюза как адрес контроллера.

На стороне пользователя:

Некоторые особенности работы:

Трафик туннельных SSID шифруется через IPsec VPN;
Шифрование беспроводного трафика осуществляется посредством L2 NVGRE over IPSec VPN;
Не требуется настройка туннеля.

Это интересно. При настройке на туннельных точках автоматически включается контроль штормов доступа. Это нужно для ограничения количества широковещательных и мультикастовых пакетов и снижения нагрузки на шифровку/дешифровку пакетов

Преимущества Secure WiFi

Унификация решения — администратору не нужно разбираться с особенностями клиентов для различных операционных систем, шлюзов, и так далее.
Пользователи проходят полноценную WPA2 Enterprise аутентификацию. Есть возможность использовать двухфакторную аутентификацию.
Поддерживаются динамические VLAN, то есть пользователи при подключении автоматически оказываются в нужном сегменте сети, что повышает безопасность и упрощает настройки окружения.
Удаленный сотрудник получает тот же уровень безопасности, то же сетевое и программное окружение и такой же IP-адрес, как если бы он был в офисе. Пользователю не нужно приспосабливаться к новым условиям, что значительно упрощает поддержку со стороны ИТ службы.
Повышение производительности за счёт устранения широковещательных штормов и оптимизация использования полосы пропускания.

Ограничения Secure WiFi

Тут, собственно, всё ограничение упирается в приобретение дополнительных точек доступа (если это необходимо).

Какое нужно оборудование для Secure WiFi

На стороне центрального офиса должен стоять контроллер (с прошивкой ZLD5.00) — то есть минимум один шлюз серии ATP, USG Flex, VPN.

На стороне клиента — точки доступа WAX650S, WAX610D, WAX510D, WAC500, WAC500H (с прошивкой 6.20)

Рисунок 2. Семейство шлюзов серии USG FLEX — самой новая, прогрессивная линейка с централизованным управлением Zyxel Nebula.

Более подробно можно прочитать в описании на сайте.

Рисунок 3. Точки доступа с прошивкой 6.20, пригодные для работы с Secure WiFi.

IPSec всемогущий

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

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

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

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

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

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

Резюме

Существуют различные стандарты для подключения удалённых пользователей по VPN (client-to-site). Оборудование Zyxel поддерживает клиенты ZyWALL IPSEC, L2TP over IPSec и SSL VPN.

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

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