Общий ключ ipsec что это keenetic

IPSec всемогущий

История вопроса

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

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

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

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

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

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

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

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

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

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

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

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

ipsecgw.example.com — домашний сервер, являющийся центром сети. Внешний IP 1.1.1.1. Внутренняя сеть 10.0.0.0/23 и еще один адрес 10.255.255.1/30 для установки приватной BGP-сессии с VPS;
mama — Linux-роутер на базе маленького беззвучного неттопа, установленный у родителей. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.3.0/24;
keenetic — маршрутизатор Keenetic с установленным модулем IPSec. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.4.0/24;
road-warriors — переносные устройства, подключающиеся из недоверенных сетей. Адреса клиентам выдаются динамически при подключении из внутренного пула (10.1.1.0/24);
rkn.example.com — VPS вне юрисдикции уважаемого РКН. Внешний IP — 5.5.5.5, внутренний адрес 10.255.255.2/30 для установки приватной BGP-сессии.

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

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

На обоих хостах открываем порты 500/udp, 4500/udp и разрешаем прохождение протокола ESP.
Правим файл /etc/strongswan/ipsec.secrects (на стороне хоста ipsecgw.example.com) и вносим следующую строку:

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

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

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

На хосте ipsecgw.example.com редактируем файл /etc/strongswan/ipsec.conf:

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

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

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

На сервере ipsecgw.example.com в настройках firewall запрещаем маскарадинг для сети 10.0.3.0/24. Разрешаем форвардинг пакетов между 10.0.0.0/23 и 10.0.3.0/24 и наоборот. На удаленном узле выполняем аналогичные настройки, запретив маскарадинг для сети 10.0.0.0/23 и настроив форвардинг.

Рестартуем 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 (с благозвучным доменным именем rkn.example.com) в тысяче километров от обезьянок, любящих размахивать банхаммером и блокировать сети размером /16 за раз. И крутилось на этой маленькой VPS прекрасное творение коллег из NIC.CZ под названием BIRD. Птичка первой версии постоянно умирала в панике от активности обезьянок с дубинками, забанивших на пике своей трудовой деятельности почти 4% интернета, уходя в глубокую задумчивость при реконфиге, поэтому была обновлена до версии 2.0.7. Если читателям будет интересно — опубликую статью по переходу с BIRD на BIRD2, в котором кардинально изменился формат конфига, но работать новая вервия стала намного быстрее и нет проблем с реконфигом при большом количестве маршрутов. А раз у нас используется протокол динамической маршрутизации, то должен быть и сетевой интерфейс, через который нужно роутить трафик. По умолчанию IPSec интерфейсов не создает, но за счет его гибкости мы можем воспользоваться классическими GRE-туннелями, которые и будем защищать в дальнейшем. В качестве бонуса — хосты ipsecgw.example.com и rkn.example.com будут аутентифицировать друга друга, используя самообновляемые сертификаты Lets Encrypt. Никаких PSK, только сертификаты, только хардкор, безопасности много не бывает.

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

На хосте ipsecgw.example.com (его IP — 1.1.1.1) описываем новый интерфейс gif0:

Зеркально на хосте vps.example.com (его IP — 5.5.5.5):

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

Готовим VPS

Первым делом получаем еще один сертификат на доменное имя rkn.example.com. Создаем симлинки в /etc/strongswan/ipsec.d как описано в предыдущем разделе.

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

На стороне хоста ipsecgw.example.com тоже добавляем в ipsec.conf в секцию setup параметр strictcrlpolicy = yes, включающий строгую проверку CRL. И описываем еще одно соединение:

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

/rkn.example.com.pem, после чего при помощи scp перекрестно копируем их между серверами в расположения, указаные в конфиге

Не забываем настроить файрвол и автообновление сертификатов. После перезапуска Strongswan на обоих серверах, запустим ping удаленной стороны GRE-туннеля и увидим успешную установку соединения. На VPS (rkn):

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

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

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

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

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

На хосте ipsecgw.example.com создадим каталог /opt/ipsec-pubkey в котором разместим 2 скрипта.

На VPS (хосте rkn.example.com) аналогично создаем каталог с тем же именем, в котором тоже создаем аналогичные скрипты, изменяя только название ключа. Код, чтобы не загромождать статью, под

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

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

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

На сервере ipsecgw.example.com в каталоге /etc/systemd/system создаем файл keyupdater.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, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.

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

Надеюсь коллеги в комментариях подскажут правильное решение.

Источник

Настройка L2TP VPN-сервера на роутерах Keenetic

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

Для организации защищенных каналов я предпочитаю использовать OpenVPN, о настройке которого уже не раз рассказывал на страницах блога. Но что делать, если у вас нет возможности, желания или навыков поднимать OpenVPN-сервер? Для небольшого офиса, а уж тем более домашнего использования, подобное решение не всегда оправдано. Гораздо проще организовать безопасное подключение к ресурсам вашей сети используя готовый L2TP VPN-сервер на базе роутера Keenetic и сегодня я наглядно покажу как это делается.

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

Настройка L2TP-сервера на роутерах Keenetic

Со времени появления первых «кинетиков», проделана большая работа и теперь эти роутеры обладают весьма не плохим функционалом, оставаясь простыми в настройке (тут засылаю огромный булыжник в огород MikroTik). Для примера, взял роутер Keenetic Extra II с прошивкой версии 2.14.C.0.0-4.

Итак, расширение функциональности Keenetic OS, на которой работает роутер, достигается за счёт установки дополнительных компонентов. Как вы уже поняли, нам потребуется установить компонент L2TP/IPsec VPN-сервера:

В поле Общий ключ IPsec пишем любой набор символов или секретную фразу, которая будет использоваться в качестве ключа шифрования (чем сложнее, тем лучше).

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

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

Остаётся только отметить галочками пользователей (мы их создали в третьем пункте) и активировать L2TP VPN-сервер.

Настройка соединения L2TP/IPsec на Windows и маке

Настройка VPN L2TP соединений под macOS или Windows делается штатными средствами. Если требуется подробная инструкция по их настройке, пишите в комментариях. А не сегодня это всё. Не забывайте ставить лайки и подписываться.

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Комментариев: 4

Уахаха, видимо просто руки не из того места растут!

Константин, сравнивать Кинетик с ТП-линк, это как Мерседес с Жигулями.

Обе машины, но сильно разные.

Источник

Объединение сетей с помощью L2TP/IPsec на Mikrotik и Keenetic Ultra II

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

Объединять сети будем через VPN туннели по технологии L2TP/IPsec без поднятия дополнительных серверов и использования дорогостоящего оборудования, непосредственно на роутерах Mikrotik и Keenetic Ultra II. Поводом для такого объединения, помимо удобства пользователей и моей лени, послужила некорректная работа встроенного L2TP/IPsec клиента в Windows.

Как видно из схемы, пользователи в филиалах должны иметь доступ к терминальному серверу, расположенному за роутером Keenetic Ultra II. Так как на «Кинетике» уже был настроен и благополучно работал L2TP/IPsec сервер, то «Микротикам» досталась роль клиентов. Кроме того, такой вариант существенно проще в настройке, по сравнению с поднятием VPN сервера на «микротике».

Обязательное условие: адреса объединяемых сетей не должны пересекаться между собой.

Настройка L2TP VPN-сервера на роутере Keenetic

С подробностями настройки L2TP/IPsec сервера на Keenetic Ultra можно ознакомиться перейдя по этой ссылке. Там всё просто, потому не буду повторяться. В дополнение к той статье, необходимо остановиться на паре существенных моментов, без которых не возможна нормальная работа VPN туннелей:

Для удалённых филиалов я выбрал имена office_01 и оffice_02 и назначил им соответсенно статические адреса 172.16.2.35 и 172.16.2.35. Эти адреса, указываются в качестве шлюзов при создании статических маршрутов для сетей, расположенных за ними. У office_01 внутренняя сеть 192.168.11.0/24, office_02 — 192.168.0.0/24

Настройка Mikrotik в качестве клиента L2TP/IPsec

Настройку удаленного клиента начнём с добавления нового интерфейса L2TP Client в разделе интерфейсов. Указываем IP-адрес L2TP сервера, свои учётные данные и общий ключ шифрования IPSec.

Если вы думаете, что этого достаточно для успешной установки соединения с сервером, поднятом на Keenetic Ultra II, то глубоко заблуждаетесь, ибо настройка «микротов» это всегда боль и страдания. Складывается впечатление, что компания Mikrotik намеренно лишает себя прибыли. Я не понимаю, что мешает выпустить нормальные пошаговые руководства по настройке своих железок и стать ведущим игроком на рынке.

Далее требуется указать нужные алгоритмы шифрования SA (Security Association) в настройках IP->IPsec->Proposals и изменить значение параметра PFS Group с modp1024 на none.

Аббревиатура PFS расшифровывается как Perfect Forward Secrecy — что-то связанное со второй фазой обмена ключами в IPsec. Честно говоря, так глубоко в эту тему не вникал и если не ошибаюсь, то на устройствах от Apple данный параметр в настройках IPsec по умолчанию тоже выключен. В общем, чтобы канал до Keenetic Ultra II поднялся, значение параметра PFS Group должно быть none.

Также скорректируем и профиль шифрования по-умолчанию IP->IPsec->Profiles:

Нажимаем «Применить», и если мы всё сделали правильно, соединение должно быть установлено.

Туннель у нас поднялся. Осталась самая малость, чтобы компьютеры за роутером получили доступ в удалённую сеть 192.168.99.0/24, где находится терминальный сервер. Для этого необходимо добавить правило маскарада и новый статический маршрут.

Переходим во вкладку IP->Firewall->NAT:

Firewall->NAT»>

На вкладке IP->Routes в качестве шлюза указываем созданный интерфейс l2tpMainOffice, а в поле Pref. Source – наш IP-адрес в виртуальной сети:

Аналогичным образом настраивается и клиент для второй сети.

Напоследок хотелось поделиться несколькими ссылками с сайта центра поддержки KEENETIC (https://help.keenetic.com/hc/ru/):

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Комментариев: 2

Спасибо тебе добрый человек.

Источник

Создание подключений VPN на шлюзах Zyxel

VPN шлюзы Zyxel Zywall серий VPN, ATP и USG обладают обширными возможностями создания защищенных виртуальных сетей (VPN) для подключения как конечных пользователей (узел-сеть), так и создания подключения между шлюзами (сеть-сеть). В этой статье мы пройдем по всем моментам создания и настройки VPN подключения удаленных сотрудников.

Выбор подходящего VPN

Шлюзы позволяют создать три сценария подключения:

Рассмотрим настройку каждого из них.

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

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

Для корректной работы L2TP VPN по средствам встроенного клиента на Windows требуется проверить включение службы «IKEEXT» (Модули ключей IPsec для обмена ключами в Интернете и протокола IP с проверкой подлинности)

Остальные советы из интернета о правке реестра стоит воспринимать с осторожностью, так как они могут только навредить.

В связи с таможенными ограничениями по отношению ввоза сетевого оборудования на территорию РФ, реализующее шифровально-криптографические функции, на шлюзах Zyxel «из коробки» доступно только шифрование DES.

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

Для активации остальных режимов (3DES) — нужно через консоль ввести команды:

После ввода команды reboot шлюз перезапустится и позволит выбрать нужные режимы шифрования.

С нюансами разобрались, приступим непосредственно к настройке соединений.

Все примеры будут описаны с применением шлюза VPN50, VPN2S, ПК под управлением Windows, Android смартфона и иногда iPhone смартфона.

VPN50 выступает в роли «головного шлюза» находящегося в офисе/серверной.

Настройка L2TP подключения

Настройка L2TP на VPN50

Проще всего настроить VPN через Wizard. Он сразу создаст все правила и подключение.
После ввода логина\пароля открывается Easy mode (упрощенный режим управления)

Настоятельно рекомендуем использовать его только в информационном режиме, так как создаваемые через Easy Wizard режимы VPN потом нельзя корректировать в Expert Mode.
Нажимаем верхнюю правую кнопку “Expert Mode” и попадаем в полноценный Web интерфейс управления

Слева сверху иконка «волшебная палочка» — быстрая настройка:

Если настройки интернета отличаются от DHCP, первоначально требуется настроить WAN interface. Для настройки VPN выбираем правую иконку

Для настройки L2TP выбрать последний пункт «VPN Setting for L2TP».

Здесь нам предлагают ввести имя подключения, интерфейс, через который будет проходить трафик (стоит иметь в виду: если подключение к интернету происходит через PPPOE подключение, то и здесь соответственно нужно выбрать wan_ppp) и предварительный ключ.

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

DNS сервер можно не прописывать, если не требуется пускать весь трафик (клиентский интернет) через VPN, что выбирается галочкой ниже.

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

Всё! Подключение создано. Осталось создать пользователей для подключения к шлюзу.

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

На вкладке VPN-L2TP VPN в пункте Allowed user выбираем созданную ранее группу или единичного пользователя, которые смогут подключаться по L2TP.

На этом создание подключения по L2TP на шлюзе можно считать настроенным.
Перейдем к настройке клиентов.

Настройка клиентов L2TP

Настройка L2TP на клиентах Windows

На Windows 10 настройка L2TP производится штатными средствами:

Выставляется правильные шифрование и протоколы как на изображении.

Во вкладке Дополнительные параметры меняется предварительный ключ

Так же рекомендуется на вкладке Сеть отключить протокол IPv6

На этом подключение готово.

Настройка L2TP на клиентах Android

Иногда требуется подключать и мобильных сотрудников к корпоративной сети.

На Android смартфонах это делается в меню:

Здесь вводится имя подключения, выбирается тип VPN L2TP/IPSec PSK, вводится общий ключ, имя пользователя и пароль.

После подключения должен появиться значок «Ключ», который информирует о VPN соединении.

Настройка L2TP на клиентах Iphone

Настройка Iphone практически не отличается от клиентов android

По пути
создается новое подключение, где прописывается Описание (название подключения), Сервер (ip адрес шлюза), имя пользователя с паролем и общий ключ. Готово.

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

Тапнув по конфигурации так же можно увидеть информацию о соединении.

Настройка L2TP на аппаратном клиенте VPN2S

А теперь покажем, как подключить к корпоративной сети удаленного клиента, у которого дома установлен недорогой шлюз Zyxel VPN2S.

Для подключения VPN2S клиентом L2TP настройка так же не составит труда. Тут даже не требуется «Wizard», все правила изначально созданы.

В Gateway конфигурации ввести Peer Gateway Address (IP адрес шлюза) и ключ.

На вкладке L2TP VPN поставить галочку Enable, на против IPsec (имя дефолтной конфигурации) Enforce, ввести имя и пароль пользователя и, если требуется, включить NAT.

После этого перейти обратно на вкладку IPsec VPN и убедиться, что в Connection Tunnel горит «зеленый глобус», сигнализирующий о поднятом соединении.

Настройка SSL подключения

Настойка SSL на шлюзе VPN50

Для настройки SSL VPN (которых к слову без лицензии меньше, чем L2TP, но имеющие более защищенное подключение) потребуется:

Важное замечание! Для работы SSL VPN протокол HTTPS должен быть добавлен в конфигурацию протоколов

В группе “Default_Allow_Wan_To_ZyXall” добавить HTTPS. Он так же потребуется и для доступа на Web интерфейс шлюза извне.

Настройка клиентов SSL

Настройка SSL на клиентах Windows

Для подключения клиента Windows используется программа ZyWALL SecuExtender 4.0.3.0.

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

В процессе подключения согласиться со всплывающим предупреждением

После подключения во вкладке Status будет показана информация о соединении.

Настройка VPN IPsec подключения

Настройка VPN IPsec на VPN50

Где указывается имя, версия IPsec, ключ, режим согласования и варианты шифрования.

В соседней вкладке VPN Connection создается новое подключение, настройки по аналогии с созданием L2TP.

Настройка VPN IPsec на клиентах

Настройка VPN IPsec на клиентах Windows

Программа для подключения IPSec VPN на Windows располагается по ссылке.

Подключение создается через «мастер создания туннеля IKE V1» (так как на шлюзе был выбран именно он).

На этой вкладке вводится IP адрес шлюза, ключ и подсеть шлюза- далее- готово.

В первой фазе проверяется соответствие параметров шифрования.

Так же и во второй фазе

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

Настройка VPN IPsec на VPN50 с предоставлением конфигурации

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

После этого в ZyWALL IPSec VPN Client будет доступна возможность загрузки конфигурации прямо со шлюза.

В меню Конфигурация выбрать пункт «Получить с сервера»

Где нужно ввести только IP адрес шлюза, логин и пароль пользователя.

После успешного соединения будут получены все нужные настройки и создано новое подключение.

Заключение

Были рассмотрены самые популярные варианты подключения VPN с различными клиентскими устройствами. Но самих вариантов еще очень много.

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

Больше информации вы можете найти на странице технической поддержки Zyxel

Обсудить статью и получить поддержку вы можете в нашем телеграм-чате.

Источник