Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Ipsec

L2TP amp IPsec with pre shared key vs MITM

31.05.2021 12:16:05 | Автор: admin

В статье рассмотрены основные vpn протоколы, которые на текущий момент применимы в бизнес процессах, а также углубленно освещен вопрос использования L2TP в связке с IPsec в режиме pre shared key. На практике разобраны подходы к организации виртуальных сетей на оборудовании MikroTik и выполнен практический аудит безопасности передачи данных с позиции анализа третьими лицами исходящего трафика при возможности MITM атаки.

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

Для начала разберем, в каких случаях бизнесу нужен vpn:
при подключении удаленных сотрудников к сетевым ресурсам компании (site-to-client vpn) и
при объединении территориально разнесенных сетевых элементов (site-to-site vpn). Самих протоколов vpn сейчас много: GRE , PPTP, SSTP, OVPN, L2TP, Wireguard и т.д.

Здесь важно не путать протоколы с сервисами vpn, которых еще больше: ExpressVPN, CyberGhost, NordVPN и т.д. Вторые по сути являются провайдерами услуг, обеспечивая доступ клиентов к собственным ресурсам с целью обхода блокировок со стороны ISP, а также анонимности серфинга в интернете. Про них сейчас речь не идет.

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

Во-вторых, Wireguard хоть молодой, простой и очень перспективный, но на офисном маршрутизаторе Cisco или MikroTik его не поднять, вендоры даже не планируют внедрять. PPTP очень легок в настройке, однако будет либо не шифрованным, либо шифрованным протоколом MPPE, который не имеет аппаратной разгрузки, в следствие чего, многопользовательскую сеть замедлит в работе. SSTP отличный протокол, работает по TLS в UDP на 443 порту, пролезет через любой Firewall, а может даже и IDS. У некоторых вендоров, например, MikroTik, может работать по pre shared key вместо сертификата, запускается на Windows клиентах из коробки.
Из минусов: определенные танцы с бубном при настройке Linux клиентов (протокол все-таки от Microsoft) и отсутствие поддержки со стороны вендоров в аппаратной разгрузке. OpenVPN всем хорош, особенно высокой гибкостью. Можно туннелировать на L2, можно на L3, всего не перечислить. Не даром он open soft. Роутер MikroTik скоро научится работать с ним по UDP (ожидается в следующем поколении RouterOS), так как смысла в TCP нет, ведь соединение все равно проверяется во вложенном туннеле. Однако, скорее всего ваша офисная Cisco не умеет с ним работать, поэтому vpn сервер из нее не организовать.

Фактически, стандартом де-факто в корпоративной среде является протокол L2TP. Он работает на UDP, порт по умолчанию 1701. С шифрованием все хорошо, особенно наличие возможности аппаратной разгрузки IPsec. Есть вероятность, что ваш корпоративный MikroTik (несмотря на то, что он софтовый маршрутизатор) умеет шифровать IPsec на железе (смотри таблицу Hardware acceleration на сайте производителя ). У Cisco в этом вопросе дела обстоят еще лучше. Даже если ваш офисный роутер не умеет шифровать железом, никто кроме вас это знать не должен не будет.

Итак, подведем промежуточный итог: vpn технологии бизнесу нужны, использовать лучше всего L2TP. Закончив с затянувшейся вводной частью, перейдем непосредственно к теме статьи. Рассмотрим на примере оборудования MikroTik безопасность передачи данных в туннеле при возможности MITM атаки со стороны третьих лиц. Этот вопрос возникает в следствие того, что почти всегда в корпоративной среде используют L2TP в связке с IPsec в туннельном режиме и общим ключем для всей сети, вместо создания PKI и задействования сертификатов. Это удобно, сеть быстро разворачивается и легко обслуживается. Безопасно ли это в условиях компрометации pre shared key? Разберем на практике.

Начнем с того, что L2TP может быть не шифрованным:

/ppp profile name=test use-encryption=no


с интегрированным в протокол шифрованием MPPE:

/ppp profile name=test use-encryption=yes (или require, при этом IPsec отключен)



с качественным внешним шифрованием от IPsec, вроде AES:

/ppp profile name=test use-encryption=yes (или require, при этом IPsec включен)



Настройка L2TP сервера осуществляется достаточно просто, активируем его и указываем тип аутентификации:

/interface l2tp-server server set authentication=mschap2 default-profile=test enabled=yes


Здесь же появляется возможность сразу активировать IPsec и настроить pre shared key. Если это сделать, то общий ключ будет закреплен за всей vpn сетью и передан всем ее участникам в качестве настроечной информации. Один и тот же на всех. На самом деле, если активировать IPsec таким образом, то RouterOS автоматически создает необходимые настройки в соответствующем разделе /ip ipsec сразу после установления L2TP соединения.

Конкретно речь идет:

  • IPsec Policy с указанными протоколом UDP и портом подключения 1701;
  • IPsec Peer c IP адресами сервера и клиента;
  • IPsec Identity с указанным ранее pre shared key.

Автоматически созданные настройки IPsec

Очень удобно. Особенно, когда IP адреса динамические и вообще натированные. Клиентам не нужно выполнять лишние процедуры по отслеживанию их текущих значений. В RouterOS в разделе L2TP есть дополнительная настройка, определяющая общий секрет при конфигурировании в сетях Virtual Private DialUp Network протяженных соединений точка-точка между удаленным сервером PPPOE и L2TP сетью, но это к теме статьи не относиться, поэтому просто ее упомянем всуе:

/ppp l2tp-secret add address=0.0.0.0/0 secret=

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

/ip ipsec peer add address=IP local-address=IP name=peer1/ip ipsec identity add peer=peer1 auth-method=digital-signature certificate=u01.crt_0/ip ipsec policy add dst-address=IP dst-port=1701 peer=peer1 protocol=udp src-address=IP src-port=1701

Здесь нас поджидает кропотливая работа, ведь, скорее всего, адреса у клиентов меняются (и достаточно часто), кроме этого клиенты сидят за провайдорским NAT. Все это можно накрутить кастомными скриптами на RouterOS, и все будет отлично работать. Нужно ли это? Cмоделируем ситуацию, когда общий для всех pre shared key стал известен злоумышленнику, который целенаправленно хочет нам навредить. Или клиент vpn нам больше не клиент. Сразу баним его учетную запись, и теперь аутентификацию mschap2 (или какая у вас там выбрана) он не пройдет и доступ не получит:

/ppp secret disable bad_user

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

/ppp secret add name=good_user password=12345 service=l2tp

Шифрованный трафик L2TP туннеля

Исследовательский интерес нас ведет дальше. Может все-таки что-то можно сделать с трафиком? И в результате извлечь передаваемую информацию? Попробуем дешифровать трафик в лабораторных условиях. MikroTik позволяет нам выполнить debug соединения и увидеть подробную информацию об установленной IPsec сессии:

/ip ipsec installed-sa print

Как видно, сессия установилась на 30 минут, имеются разные ключи аутентификации и шифрования. Применим их в Wireshark, после приведения шестнадцатеричных значений к корректному формату: SPI 0x0ada181b, вместо MikroTik-овского 0xADA181B, ключи начинаются со значения 0x. Если все сделано правильно, тогда трафик откроется.

Ввод данных сессии для дешифрования IPsec

Дешифрованный IPsec

Подведем результаты

Насколько безопасно использовать L2TP c общим секретом? Абсолютно безоапасно. По сути IPsec с помощью pre shared key выполняет функцию аутентификации, но в нашем случае процедура аутентификации выполняется ранее при установлении L2TP соединения. Нет практической необходимости выполнять аутентификацию повторно. По сути MikroTik, введя возможность настройки IPsec в разделе создания L2TP сервера, автоматизирует рутинные задачи по настройке шифрованного туннеля в ручном режиме (история про танцы с бубном). Это еще один плюс в сторону использования не дорогостоящего, но качественного оборудования MikroTik. Конечно, в ручном режиме гораздо больше вариаций на тему шифрования, но по умолчанию задаются, по авторскому мнению, идеальные значения: aes256 и sha1.


Как рекомендации для бизнеса, смело можно использовать L2TP с IPsec pre shared key. При планировании политик информационной безопасности, нет необходимости в задании сложных значений для pre shared key. Важно выставить не угадываемые и не словарно подбираемые значения для аутентификации L2TP (/ppp secret). Удобно, безопасно и качественно, админ доволен, клиенты не замучены.


Подробнее..
Категории: Блог компании ruvds.com , Информационная безопасность , Сетевые технологии , Mikrotik , Vpn , Ipsec , Mitm , Ruvds_статьи , Routeros , L2tp

Простой UDP hole punching на примере IPIP-туннеля

12.07.2020 22:04:29 | Автор: admin
Доброе время суток!
В этой статье хочу рассказать как я реализовал (еще один) скрипт на Bash для соединения двух компьютеров, находящимися за NAT, с использованием технологии UDP hole punching на примере ОС Ubuntu/Debian.

Организация соединения состоит из нескольких шагов:
1. Запуск узла и ожидание готовности удаленного узла;
2. Определение внешнего IP-адреса и UDP-порта;
3. Передача внешнего IP-адреса и UDP-порта удаленному узлу;
4. Получение внешнего IP-адреса и UDP-порта от удаленного узла;
5. Организация IPIP-туннуля;
6. Мониторинг соединения;
7. При обрыве соединения удалять IPIP туннель.

Я долго думал и еще думаю, что можно использовать для обмена данными между узлами, самое простое и быстрое для меня на данный момент, это работа через Яндекс.диск.
  • Во первых, это простота в использовании нужно 3 действия: создать, прочитать, удалить. С помощью curl это:
    Создать:
    curl -s -X MKCOL --user "$usename:$password" https://webdav.yandex.ru/$folder

    Прочитать:
    curl -s --user "$usename:$password" -X PROPFIND -H "Depth: 1" https://webdav.yandex.ru/$folder

    Удалить:
    curl -s -X DELETE --user "$usename:$password" https://webdav.yandex.ru/$folder
  • Во вторых, это простота в установке:
    apt install curl


Для определения внешнего IP-адреса и UDP-порта используется stun-client командой:
stun stun.sipnet.ru -v -p $1 2>&1 | grep "MappedAddress"

Установка командой:
apt install stun-client


Для организации туннеля используются штатные средства ОС из пакета iproute2. Существует множество туннелей которые можно поднять штатными средствами (L2TPv3, GRE и т.п.), но я выбрал IPIP потому что он создаёт минимальную дополнительную нагрузку на систему. Я пробовал L2TPv3 поверх UDP и разочаровался, скорость упала в 10 раз, но это могут быть различные ограничения связанные с провайдерами или еще чего-то. Так как IPIP-туннель работает на уровне IP, то используется FOU-туннель для того, что бы работать на уровне UDP-портов. Для организации IPIP-туннеля нужно:

загрузить модуль FOU:
modprobe fou

слушать локальный порт:
ip fou add port $localport ipproto 4

создать туннель:
ip link add name fou$name type ipip remote $remoteip local $localip encap fou  encap-sport $localport encap-dport $remoteport

поднять интерфейс туннеля:
ip link set up dev fou$name

назначить внутренний локальный и внутренний удаленный IP-адрес тунеля:
ip addr add $intIP peer $peerip dev fou$name


Удалить туннель:
ip link del dev fou$name


ip fou del port $localport


Мониторинг состояния туннеля происходит с помощью периодического пинга внутреннего IP-адреса туннеля удаленного узла, командой:
ping -c 1 $peerip -s 0

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

Собственно сам скрипт:
#!/bin/bashusername="username@yandex.ru"password="password"folder="vpnid"intip="10.0.0.1"localport=`shuf -i 10000-65000 -n 1`cid=`shuf -i 10000-99999 -n 1`tid=`shuf -i 10-99 -n 1`function yaread {        curl -s --user "$1:$2" -X PROPFIND -H "Depth: 1" https://webdav.yandex.ru/$3 | sed 's/></>\n</g' | grep "displayname" | sed 's/<d:displayname>//g' | sed 's/<\/d:displayname>//g' | grep -v $3 | grep -v $4 | sort -r}function yacreate {        curl -s -X MKCOL --user "$1:$2" https://webdav.yandex.ru/$3}function yadelete {        curl -s -X DELETE --user "$1:$2" https://webdav.yandex.ru/$3}function myipport {        stun stun.sipnet.ru -v -p $1 2>&1 | grep "MappedAddress" | sort | uniq | awk '{print $3}' | head -n1}function tunnel-up {modprobe fouip fou add port $4 ipproto 4ip link add name fou$7 type ipip remote $1 local $3 encap fou encap-sport $4 encap-dport $2ip link set up dev fou$7ip addr add $6 peer $5 dev fou$7}function tunnel-check {sleep 10        pings=0        until [[ $pings == 4 ]]; do                if ping -c 1 $1 -s 0 &>/dev/null;                        then    echo -n .; n=0                        else    echo -n !; ((pings++))                fisleep 15        done}function tunnel-down {ip link del dev fou$1ip fou del port $2}trap 'echo -e "\nDisconnecting..." && yadelete $username $password $folder; tunnel-down $tunnelid $localport; echo "IPIP tunnel disconnected!"; exit 1' 1 2 3 8 9 14 15until [[ -n $end ]]; do    yacreate $username $password $folder    until [[ -n $ip ]]; do        mydate=`date +%s`        timeout="60"        list=`yaread $username $password $folder $cid | head -n1`        yacreate $username $password $folder/$mydate:$cid        for l in $list; do                if [ `echo $l | sed 's/:/ /g' | awk {'print $1'}` -ge $(($mydate-65)) ]; then#echo $list                        myipport=`myipport $localport`                        yacreate $username $password $folder/$mydate:$cid:$myipport:$intip:$tid                        timeout=$(( $timeout + `echo $l | sed 's/:/ /g' | awk {'print $1'}` - $mydate + 3 ))                        ip=`echo $l | sed 's/:/ /g' | awk '{print $3}'`                        port=`echo $l | sed 's/:/ /g' | awk '{print $4}'`                        peerip=`echo $l | sed 's/:/ /g' | awk '{print $5}'`peerid=`echo $l | sed 's/:/ /g' | awk '{print $6}'`if [[ -n $peerid ]]; then tunnelid=$(($peerid*$tid)); fi                fi        done        if ( [[ -z "$ip" ]] && [ "$timeout" -gt 0 ] ) ; then                echo -n "!"                sleep $timeout        fi    done    localip=`ip route get $ip | head -n1 | sed 's|.*src ||' | cut -d' ' -f1`    tunnel-up $ip $port $localip $localport $peerip $intip $tunnelid    tunnel-check $peerip    tunnel-down $tunnelid $localport    yadelete $username $password $folder    unset ip port myipportdoneexit 0

Переменные username, password и folder должны быть одинаковые на обоих сторонах, а вот intip разные, например: 10.0.0.1 и 10.0.0.2. Время на узлах должно быть синхронизированно. Запускать скрипт можно так:
nohup script.sh &

Обращаю внимание на то, что IPIP-теннель небезопасен с точки зрения того, что трафик не шифруется, но это легко решается при помощи IPsec по этой статье, она мне показалось простой и понятной.
Использую данный скрипт для подключения к рабочим ПК уже несколько недель и проблем не замечал. Удобно в плане того, что настроил и забыл.
Возможно у Вас будут замечания и предложения, буду рад выслушать)
Спасибо за внимание!
Подробнее..
Категории: Информационная безопасность , Сетевые технологии , Разработка для интернета вещей , Udp hole punching , Ipsec , Ipip

Удаленная работа или обзор VPN в Sophos XG Firewall

07.10.2020 18:18:13 | Автор: admin


Всем привет! Данная статья будет посвящена обзору функционала VPN в продукте Sophos XG Firewall. В предыдущей статье мы разбирали, как получить бесплатно данное решение по защите домашней сети с полной лицензией. Сегодня мы поговорим о функционале VPN который встроен в Sophos XG. Я постараюсь рассказать, что умеет данный продукт, а также приведу примеры настройки IPSec Site-to-Site VPN и пользовательского SSL VPN. Итак, приступим к обзору.

Первым делом посмотрим на таблицу лицензирования:



Более подробно о том, как лицензируется Sophos XG Firewall можно прочитать тут:
Ссылка
Но в данной статье нас будут интересовать только те пункты, которые выделены красным.

Основной функционал VPN входит в базовую лицензию и приобретается только один раз. Это пожизненная лицензия и она не требует продления. В модуль Base VPN Options входит:

Site-to-Site:

  • SSL VPN
  • IPSec VPN

Remote Access (клиентский VPN):

  • SSL VPN
  • IPsec Clientless VPN (с бесплатным пользовательским приложением)
  • L2TP
  • PPTP

Как видим, поддерживаются все популярные протоколы и типы VPN соединений.

Также, в Sophos XG Firewall есть еще два типа VPN соединений, которые не включены в базовую подписку. Это RED VPN и HTML5 VPN. Данные VPN соединения входят в подписку Network Protection, а это значит, чтобы использовать данные типы необходимо иметь активную подписку, в которую, также входит и функционал защиты сети IPS и ATP модули.

RED VPN это проприетарный L2 VPN от компании Sophos. Данный тип VPN соединения имеет ряд преимуществ по сравнению с Site-to-site SSL или IPSec при настройке VPN между двумя XG. В отличии от IPSec, RED туннель создает виртуальный интерфейс на обоих концах туннеля, что помогает при траблшуте проблем, и в отличии от SSL, данный виртуальный интерфейс полностью настраиваемый. Администратор имеет полный контроль над подсетью внутри RED туннеля, что позволяет проще решать проблемы маршрутизации и конфликты подсетей.

HTML5 VPN или Clientless VPN Специфический тип VPN, позволяющий прокидывать сервисы через HTML5 прямо в браузере. Типы сервисов, которые можно настроить:

  • RDP
  • Telnet
  • SSH
  • VNC
  • FTP
  • FTPS
  • SFTP
  • SMB

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

Практика


Разберем на практике, как настроить несколько из данных типов туннелей, а именно: Site-to-Site IPSec и SSL VPN Remote Access.

Site-to-Site IPSec VPN


Начнем с того, как настроить Site-to-Site IPSec VPN туннель между двумя Sophos XG Firewall. Под капотом используется strongSwan, что позволяет подключиться к любому маршрутизатору с поддержкой IPSec.

Можно использовать удобный и быстрый wizard настройки, но мы пойдем общим путем, чтобы на основе данной инструкции можно было совместить Sophos XG с любым оборудованием по IPSec.

Откроем окно настроек политик:



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





Настроим параметры шифрования для первой и второй фазы и сохраним политику. По аналогии, делаем такие же действия на втором Sophos XG и переходим к настройке самого IPSec туннеля



Вводим название, режим работы и настраиваем параметры шифрования. Для примера будем использовать Preshared Key



и укажем локальные и удаленные подсети.



Наше соединение создано



По аналогии, делаем такие же настройки на втором Sophos XG, за исключением режима работы, там поставим Initiate the connection



Теперь у нас есть два настроенных туннеля. Далее, нам надо их активировать и запустить. Делается это очень просто, надо нажать на красный кружок под словом Active чтобы активировать и на красный кружок под Connection, чтобы запустить коннект.
Если мы видим такую картинку:


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

Отдельно хочу выделить, что можно из IPSec туннелей создавать Failover группы для отказоустойчивости:



Remote Access SSL VPN


Перейдем к Remote Access SSL VPN для пользователей. Под капотом крутится стандартный OpenVPN. Это позволяет пользователям подключаться через любой клиент, который поддерживает .ovpn конфигурационные файлы (например, стандартный клиент подключения).

Для начала, надо настроить политики OpenVPN сервера:



Указать транспорт для подключения, настроить порт, диапазон ip адресов для подключения удаленных пользователей



Также, можно указать настройки шифрования.

После настройки сервера, приступаем к настройке клиентских подключений.



Каждое правило подключения к SSL VPN создается для группы или для отдельного пользователя. У каждого пользователя может быть только одна политика подключения. По настройкам, из интересного, для каждого такого правила можно указать, как отдельных пользователей, кто будет использовать данную настройку или группу из AD, можно включить галочку, чтобы весь трафик заворачивался в VPN туннель или указать доступные для пользователей ip адреса, подсети или FQDN имена. На основе данных политик будет автоматически создан .ovpn профайл с настройками для клиента.



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



Заключение


В данной статье мы вкратце пробежались по функционалу VPN в продукте Sophos XG Firewall. Посмотрели, как можно настроить IPSec VPN и SSL VPN. Это далеко не полный список того, что умеет данное решение. В следующих статьях постараюсь сделать обзор на RED VPN и показать, как это выглядит в самом решении.

Спасибо за уделенное время.

Если у Вас будут вопросы по коммерческой версии XG Firewall, Вы можете обращаться к нам компанию Фактор груп, дистрибьютору Sophos. Достаточно написать в свободной форме на sophos@fgts.ru.
Подробнее..
Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Сетевые технологии , Vpn , Ipsec , Ngfw , Фильтрация трафика , Блог компании фактор груп , Фактор груп , Sophos , Xg firewall , Межсетевой экран , Домашний firewall

На коленке агрегация VPN, или Надежная связь на ненадежных каналах

25.03.2021 14:07:14 | Автор: admin

Представьте задачу: необходимо обеспечить стабильным интернетом и покрыть бесшовным Wi-Fi здание площадью 300 м2 с возможной расчетной нагрузкой до 100 человек. На первый взгляд, "вроде изян". Но стоит добавить пару деталей, и задача усложняется:

  • здание стоит в лесопарковой зоне, где нет оптики, так что наш вариант мобильная связь;

  • нужно обеспечить регулярные видеотрансляции, то есть добиться стабильного интернета при единственном GSM-провайдере;

  • бюджет ограничен.

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

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

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

Схема решения вкратце

Итак, при первом столкновении с проблемой отвалов я начал с агрегации частот и убедился, что это не поможет. Смена категории LTE-модема с Cat4 на Cat6 или еще круче Cat12 давала преимущество в скорости, но в потерях и отвалах нет. Пришел к выводу, что нужен второй LTE-провайдер. При этом при переключении не должен потеряться ни один кадр и трансляция не должна отвалиться.

На помощь пришла такая связка: агрегация, она же bonding, и TCP-OpenVPN-туннель поверх этого.

  • в облаке создал "сервер агрегации" виртуалку с CLOUD HOSTED ROUTER (CHR) на базе Router OS;

  • на ней поднял L2TP-сервер с включенным шифрованием IPsec;

  • поверх L2TP over IPsec создал два EoIP-туннеля;

  • EoIP-туннели агрегированы bonding-интерфейсом;

  • вишенка на торте TCP-шный OpenVPN-туннель.

Итоговая схема:

Вместо виртуальной машины в дата-центре в качестве R1 может выступать любая железка с достаточной производительностью. Например, тот же MikroTik серии CCR, компьютер, размещенный где угодно. Главное позаботиться о производительности и стабильных каналах связи, использовать схемы активного резервирования (VRRP в помощь).

Поддержка OpenVPN UDP реализована только в 7-й версии RouterOS, поэтому в этой конфигурации безальтернативно используется протокол TCP.

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

Теперь расскажу подробнее о строительстве схемы. Начнем с R1 (облачного маршрутизатора) и далее R2 (филиального).

Маршрутизатор R1

  1. Сначала берем второй белый IP в дата-центре. У меня CHR находился за Edge в облаке VMware, так что обязательно пробрасываем порты на Edge UDP 1701, 500 и 4500 NAT-T IPSec Network Address Translator Traversal. Также делаем разрешающее правило в межсетевом экране Edge.

  2. Добавляем в таблицу firewall filter разрешающее правило доступа к маршрутизатору извне для портов UDP 1701, 500 и 4500. Если у вас белые IP непосредственно на маршрутизаторе без пробросов через Edge, галочку NAT Traversal НУЖНО СНЯТЬ!

    Проверяем дефолтный IPsec-профиль:

    /ip ipsec profile set [ find default=yes ] dh-group=modp1024 enc-algorithm=3de

  3. Создаем профиль для L2TP-туннелей:

    /ppp profile add change-tcp-mss=no name=profile01 use-compression=no use-encryption=no use-mpls=no use

    и настраиваем учетные записи:

    /ppp secretadd local-address=172.16.0.1 name=l2tp_R1-R2_ISP1 password=ros7.elements.forever profile=profile01 remote-address=172.16.0.2 service=l2tpadd local-address=172.16.0.5 name=l2tp_R1-R2_ISP2 password=ros7.elements.forever profile=profile01 remote-address=172.16.0.6 service=l2tp

  4. Активируем L2TP-сервер и включаем шифрование IPsec:

    /interface l2tp-server server set authentication=mschap2 caller-id-type=number default-profile=profile01 enabled=yes ipsec-secret=ВАШ КРУТОЙ ПАРОЛЬ use-ipsec=yes

  5. Поднимаем два EoIP-туннеля поверх L2TP/IPsec-туннелей:

    /interface eoipadd keepalive=1s,5 local-address=172.16.0.1 mac-address=00:00:00:00:00:A1 name=eoip-tun1_over_l2tp_R1-R2_ISP1 remote-address=172.16.0.2 tunnel-id=1add keepalive=1s,5 local-address=172.16.0.5 mac-address=00:00:00:00:00:B1 name=eoip-tun2_over_l2tp_R1-R2_ISP2 remote-address=172.16.0.6 tunnel-id=2

    Обязательно указываем минимальный keepalive timeout равным 1 секунде и для каждого EoIP-туннеля указываем уникальный ID.

  6. Настраиваем bonding и назначаем на него IP-адрес:

    /interface bondingadd lacp-rate=1sec mii-interval=1ms mode=broadcast name=bonding1 slaves=eoip-tun1_over_l2tp_R1-R2_ISP1,eoip-tun2_over_l2tp_R1-R2_ISP2

    /ip address add address=172.16.1.1/30 interface=bonding1

    Тут важно заметить, что в поле mode (режим работы bonding-интерфейса) я указал broadcast, чтобы пакеты отправлялись сразу по двум тоннелям. Таким образом потеря пакета на любом из двух интерфейсов не приведет к потере пакета на bonding-интерфейсе. Остальные значения устанавливаем, как на картинке.

Активируем OpenVPN-сервер

Так как у меня OpenVPN использовался еще и для внешних подключений, то я предварительно сгенерировал сертификаты и импортировал их в CHR. На этом останавливаться подробно не буду. Создаем /ppp profile и /ppp secret для OpenVPN:

/ppp profile add change-tcp-mss=no name=profile02 use-compression=no use-encryption=no use-mpls=no use/ppp secret add local-address=172.16.2.1 name=ovpn_over_bonding1 password=ros7.elements.forever profile=profile02 remote-address=172.16.2.2 service=ovpn/interface ovpn-server serverset auth=sha1 certificate=server.crt_0 cipher=aes256 default-profile=profile02 enabled=yes keepalive-timeout=30 port=1194 require-client-certificate=yes

Обязательно прописываем в nat-таблицу межсетевого экрана правило для нашей серой филиальной сети за маршрутизатором R2, чтобы трафик выходил наружу через R1:

/ip firewall natadd action=masquerade chain=srcnat out-interface-list=WAN src-address=192.168.1.0/24

Обратный маршрут до серой сети за маршрутизатором R2 указываем через OpenVPN-туннель:

/ip routeadd check-gateway=ping distance=1 dst-address=192.168.1.0/24 gateway=172.16.2.2

Маршрутизатор R2

  1. Первым делом прописываем маршруты от одного интерфейса LTE-модема до одного белого IP-адреса дата-центра. Запрещаем в настройках межсетевого экрана в цепочке output прохождение пакетов с другого интерфейса:

    /ip routeadd distance=1 dst-address= 198.51.100.10/32 gateway=lte1add distance=1 dst-address= 198.51.100.20/32 gateway=lte2/ip firewall filteradd action=drop chain=output dst-address= 198.51.100.10 out-interface=lte2add action=drop chain=output dst-address= 198.51.100.20 out-interface=lte1

  2. Приводим в соответствие с R1 дефолтный конфиг /ip ipsec profile:

    /ip ipsec profile set [ find default=yes ] dh-group=modp1024 enc-algorithm=3de

  3. Создаем /ppp profile:

    и два L2TP/IPsec-подключения к дата-центру для каждого из провайдеров:

    /ppp profile add change-tcp-mss=no name=profile01 use-compression=no use-encryption=no use-mpls=no use/interface l2tp-clientadd allow=mschap2 connect-to= 198.51.100.10 disabled=no ipsec-secret= ros7.elements.forever keepalive-timeout=30 name=l2tp_to_R1_over_ISP1 password=ros7.elements.forever    profile=profile01 use-ipsec=yes user=l2tp_R1-R2_ISP1add allow=mschap2 connect-to= 198.51.100.20 disabled=no ipsec-secret= ros7.elements.forever keepalive-timeout=30 name=l2tp_to_R1_over_ISP2 password=ros7.elements.forever    profile=profile01 use-ipsec=yes user=l2tp_R1-R2_ISP2

  4. Создаем EoIP-туннели по аналогии с R1, только меняем местами local и remote IP L2TP/IPsec-линков маршрутизатора R2. Bonding-интерфейс такой же, как на R1:

    /interface eoipadd keepalive=1s,5 local-address=172.16.0.2 mac-address=00:00:00:00:00:A2 name=eoip-tun1_over_l2tp_R1-R2_ISP1 remote-address=172.16.0.1 tunnel-id=1add keepalive=1s,5 local-address=172.16.0.6 mac-address=00:00:00:00:00:B2 name=eoip-tun2_over_l2tp_R1-R2_ISP2 remote-address=172.16.0.5 tunnel-id=2/interface bondingadd lacp-rate=1sec mii-interval=1ms mode=broadcast name=bonding1 slaves=eoip-tun1_over_l2tp_R1-R2_ISP1,eoip-tun2_over_l2tp_R1-R2_ISP2/ip address add address=172.16.1.2/30 interface=bonding1

  5. Также импортируем сертификаты, создаем профиль:

    Настраиваем OpenVPN-клиента на R2:

    /ppp profile add change-tcp-mss=no name=profile02 use-compression=no use-encryption=no use-ipv6=no use-mpls=no use-upnp=no/interface ovpn-clientadd certificate=client.crt_0 cipher=aes256 connect-to=172.16.1.1 mac-address=00:00:00:00:00:C2 name=ovpn_over_bonding1 password=ВАШ КРУТОЙ ПАРОЛЬ profile=profile02 use-peer-dns=no user="ovpn_over_bonding1 " verify-server-certificate=yes

  6. Туннели загорелись волшебной буквой R, а EoIP еще и RS. OpenVPN тоже завелся. Теперь можно направлять трафик с компьютера трансляций в наш слоеный бутерброд в OpenVPN-туннель. Для этого создаем правило /ip firewall mangle и прописываем сразу новую таблицу маршрутизации:

    /ip firewall mangleadd action=mark-routing chain=prerouting dst-address-list=google_sites dst-port=1935 new-routing-mark=pc_to_stream-youtube_over_R1 passthrough=yes protocol=tcp src-address=192.168.1.1

  7. Создаем маршрут через наш OpenVPN-туннель с данной таблицей маршрутизации:

    /ip routeadd check-gateway=ping distance=1 gateway=172.16.2.1 routing-mark=pc_to_stream-youtube_over_R1

И готово!

Траблшутинг

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

  • Утилиты RouterOS в разделе /tools очень полезны при траблшутинге. Еще неплохо работает связка /tools Packet Sniffer + Wireshark.

  • Не забудьте "поиграться с mtu", чтобы достичь лучшей производительности туннелей.

  • Качество сигнала никто не отменял. RSRP, RSRQ и SINR покажут, насколько все хорошо. При большом удалении от базовой станции и плохом сигнале помогут внешние направленные антенны.

  • Важно! Если провайдер фильтрует трафик и идет блокировка L2TP, то можно поднять другие туннели в качестве основы для EoIP, например: OpenVPN или SSTP.

  • Чтобы проверить все в деле, можно сымитировать сбой. Отключаем любой из LTE-интерфейсов или создаем потери искусственно: добавляем в межсетевой экран правило частичной блокировки пакетов и указываем при создании нового правила значение в поле random.

Что еще можно улучшить и оптимизировать

  • Не рекомендую заворачивать весь интернет-трафик, так как это вызовет повышенные накладные расходы (утилизация процессоров, каналов и др.). Лучше пользоваться маркировкой для гарантированной доставки действительно необходимого трафика, а все остальное отправлять на LTE-провайдеров. К примеру, я так делал с загрузкой видеофайлов на облачный диск.

  • QOS хорошая штука, особенно на каналах LTE, и особенно с VoIP. Не забываем про это, чтобы остальной трафик не забил и так не слишком широкий канал.

  • Можно усилить безопасность, если ограничить подключение извне к портам для L2TP и IPsec маршрутизатора R1. Указываем белый IP LTE-провайдера с помощью firewall и адресных листов. Хоть адрес и из NAT и на нем висит не один клиент, все равно будет лучше. Так как IP динамический, то нужно включить на MikroTik функцию ip cloud, чтобы DNS-сервера всегда знали актуальный IP, технология DDNS.

Конечно же, у схемы есть коммерческие аналоги с возможностями работы из коробки, например: peplink MAX HD4 LTE и тому подобное оборудование, агрегирующие соединения. Тут бизнес сам оценивает их стоимость для себя.

Оставляю ссылки на похожие темы:

Также тем, кому интересна эта тема, рекомендую покопать в сторону MPTCP (Multipath TCP).

Подробнее..
Категории: Diy или сделай сам , Системное администрирование , Сетевые технологии , Сетевое оборудование , Openvpn , Ipsec , Блог компании dataline , Bonding , L2tp/ipsec , Eoip , Mptcp

Настройка IPsec GRE туннель между FortiOS 6.4.5 и RouterOS 6.48.1

10.03.2021 14:15:34 | Автор: admin

Стояла задача объединить филиалы с головным офисом предприятия, где находилась серверная. Fortigate 60E организовывал доступ в интернет и выполнял роль межсетевого экрана в головном офисе, в филиалах выполняли роль доступа в интернет Микротик разных моделей. Также было необходимо настроить динамическую маршрутизацию OSPF и поднять IPsec VPN туннели с GRE. Порыскав на просторах интернета, нашел пару разрозненных статей о соединении Fortigate c микротик через IPsec VPN и GRE туннель. Решил объединить эту информацию в одной своей статье, чтобы в дальнейшем самому использовать как шпаргалку. О динамической маршрутизации OSPF напишу в следующей статье.

Итак, входные данные:

1.Головной офис предприятия HQ FortiOS 6.4.5:

  • Публичный IP X.X.X.X (сетевой интерфейс port1)

  • Внутренняя сеть 192.168.111.0/24 (сетевой интерфейс port2)

2.Филиал предприятия Branch Mikrotik RouterOS 6.48.1:

  • Публичный IP Y.Y.Y.Y сетевой интерфейс ether1

  • Внутренняя сеть 192.168.112.0/24 (сетевой интерфейс ether2)

На рис. схематично показано подключение главного офиса и филиала.

Опущу основный настройки Fortigate и mikrotik, эта информация есть в интернете, сразу приступим к настройкам IPsec и GRE. Начнем настройку с mikrotik . Начнем с GRE, заходим утилитой Winbox на mikrotik в меню Interfaces->GRE Tunnel->+(нажимаем плюс, чтобы добавить туннель), за тем : - Local Address Y.Y.Y.Y - Remote Address X.X.X.X Укажем параметр "keepalive", который определяет находится ли туннель в рабочем состоянии. Если параметр не включен, то даже, если второй маршрутизатор будет выключен интерфейс все равно будет показывать рабочее состояние, что не удобно для диагностики. Использовать будем значение 10 попыток по 10 секунд. т. е., если в течении 100 секунд не будет никаких сигналов с противоположной стороны туннель перейдет в нерабочее состояние. При этом он автоматически включится, если противоположная сторона попытается установить соединение. В отличии от настройки GRE без IPsec в этой конфигурации должна быть отключена опция "Allow Fast Path", а параметр "Local Address:" является обязательным потому что без него не получится создать автоматические настройки IPsec. Если указать параметр IPsec Secret, то автоматически создадутся необходимые настройки IPsec. Но их поменять будет уже не возможно, поэтому не задаю параметр IPsec Secret.

Назначим IP адрес GRE-туннелю. Зайдем IP->Addresses->+

Команды консоли :

/interface greadd name=gre-tunnel1 keepalive=10s,10 local-address=Y.Y.Y.Y remote-address=X.X.X.X allow-fast-path=no/ip addressadd address=10.10.10.2/30 interface= gre-tunnel1

Настраиваем IPsec . Начнем с phase-1, идентификация устройств между собой, по заранее определенному IP адресу и ключу , настройки в IP->IPsec->Profiles.

Создаем Peer для phase-1, в IP->IPsec->Peers. Указываем имя name Branch-HQ, адрес удаленного FortiGate HQ, локальный адрес и profile1, который соответствует phase-1.

Теперь определяем ключ IPsec phase-1.

Настройка параметров phase-2, он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Идем IP->IPsec->Proposals

И создаем политики IPsec , IP->IPsec->Policies->General. Указываем имя Peer Branch-HQ, мы его настраивали выше. Src. Address внешний адрес нашего mikrotik Y.Y.Y.Y, Dst. Address внешний адрес FortiGate HQ X.X.X.X, и указываем протокол GRE в параметре Protocol - 47.

На вкладке Action выбираем Proposal porposal1, который мы тоже настраивали выше.

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

 /ip ipsec profileadd dh-group=modp1536,modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=24h name=profile1/ip ipsec peeradd address=X.X.X.X local-address=Y.Y.Y.Y name=Branch-HQ profile=profile1/ip ipsec proposaladd auth-algorithms=sha256 enc-algorithms= aes-256-cbc lifetime=30m name=proposal1 pfs-group=modp1536/ip ipsec policyadd peer=Branch-HQ src-address= Y.Y.Y.Y dst-address= X.X.X.X protocol=47 proposal=proposal1/ip ipsec identityadd peer=Branch-HQ secret=#!@BRaNCH@!#

Прописываем правила в файерволе IP->Firewall->Filter Rules:

В терминале :

/ip firewall filteradd chain=input protocol=17 dst-port=500,4500 in-interface=ether1 action=accept

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

/ip routeadd dst-address=192.168.111.0/24 gateway=10.10.10.1

На этом настройка mikrotik окончена , перейдем к настройки FortiGate.

На FortiGate настроим IPsec phase-1 в командной строке:

config vpn ipsec phase1-interface edit HQA-Branch set peertype any set proposal aes256-sha256 set dpd on-idle set dhgrp 5 14 set auto-discovery-sender enable set remote-gw Y.Y.Y.Y set psksecret #!@BRaNCH@!# set dpd-retryinterval 5 nextend

Phase-2 , не забываем указать protocol 47 и указать transport-mode (транспортный режим) для туннеля GRE:

config vpn ipsec phase2-interface edit "HQA-Branch" set phase1name "HQA-Branch" set proposal aes256-sha256 set dhgrp 5 14 set auto-negotiate enable set encapsulation transport-mode set protocol 47 nextend

Настроим GRE tunnel:

config system gre-tunnel edit "HQ-Branch" set interface "HQA-Branch" set remote-gw Y.Y.Y.Y set local-gw X.X.X.X nextend

Настроим локальный IP адрес туннельного интерфейса и укажем IP удаленного интерфейса:

config system interface edit "HQ-Branch" set ip 10.10.10.1 255.255.255.255 set remote-ip 10.10.10.2 255.255.255.252 set interface "HQA-Branch" nextend

Трафик GRE, который должен быть защищен IPsec, создается самостоятельно, он не принимается на интерфейсе. Следовательно, не требуется политика форвардинга, чтобы разрешить трафику GRE входить или выходить из интерфейса IPsec. Однако по замыслу FortiOS для согласования IPsec требуется политика форвардинга. Поэтому для активации IPsec используется произвольная политика форвардинга (например, от самого интерфейса IPsec и обратно).

config firewall policy edit 2 set name "Enable IPsec" set srcintf "HQA-Branch" set dstintf "HQA-Branch" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" next

Разрешим трафик из локальной сети головного офиса port2 в туннель GRE и наоборот:

config firewall policy     edit 3        set name "GRE HQ->Branch"        set srcintf "port2"        set dstintf "HQ-Branch"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    next    edit 4        set name "GRE Branch->HQ"        set srcintf "HQ-Branch"        set dstintf "port2"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    nextend

После туннелирования GRE, пакеты GRE должны быть защищены IPsec. Следовательно, remote-gw gre-tunnel должен указывать на интерфейс IPsec. Настраиваем статический маршрут:

config router static edit 1 set dst Y.Y.Y.Y/30 set device "HQA-Branch" next

Создадим статический маршрут до локальной сети филиала

edit 2        set dst 192.168.112.0 255.255.255.0        set device "HQ-Branch"    nextend

И теперь поднялся IPsec и GRE , трафик из локальной сети головного офиса попадает в локальную сеть филиала и наоборот.

Использовал следующие статьи:

1.Fortinet

2.Wiki Микротика

Это мой второй труд , прошу сильно не пинать.

Подробнее..
Категории: It-инфраструктура , Системное администрирование , Удаленная работа , Сетевые технологии , Mikrotik , Vpn , Сетевое оборудование , Ipsec , Gre , Fortinet , Fortigate

IPSec туннель между Strongswan за NAT и VMWare NSX Edge

16.09.2020 18:22:11 | Автор: admin
В силу ряда причин, потребовалось организовать VPN-соединение между сетью в VMWare Cloud Director и отдельной машиной Ubuntu в облаке. Заметка не претендует на полноценное описание, это просто небольшое howto.

IPSec туннель между Strongswan за NAT и VMWare NSX Edge

В сети нашлась единственная статья 2015 года на эту тему Site to Site IPSEC VPN between NSX Edge and Linux strongSwan.

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

Поэтому, пришлось сесть и покопаться в документации.

За основу я взял давно используемый мной конфиг, позволяющий подключаться практически из любой ОС и просто добавил к нему кусок, позволяющий подключиться к NSX Edge.

Поскольку установка и полноценная настройка сервера Strongswan выходят за рамки заметки, позволю себе сослаться на неплохой материал на эту тему.

Итак, перейдём непосредственно к настройкам.

Схема соединения у нас будет выглядеть вот так:


со стороны VMWare внешний адрес 33.33.33.33 и внутренняя сеть 192.168.1.0/24со стороны Linux внешний адрес 22.22.22.22 и внутренняя сеть 10.10.10.0/24также понадобится настроить Let's encrypt сертификат для адреса vpn.linux.extPSK с обеих сторон: ChangeMeNow!

Настройка со стороны NSX Edge:

Текст 
Enabled: yesEnable perfect forward secrecy (PFS): yesName: VPN_strongswan (любое, по вашему выбору)Local Id: 33.33.33.33Local Endpoint: 33.33.33.33Local Subnets: 192.168.1.0/24Peer Id: vpn.linux.extPeer Endpoint: 22.22.22.22Peer Subnets: 10.10.10.0/24Encryption Algorithm: AES256Authentication: PSKPre-Shared Key: ChangeMeNow!Diffie-Hellman Group: 14 (2048 bit приемлемый компромисс между скоростью и безопасностью. Но если хотите, можете поставить больше)Digest Algorithm: SHA256IKE Option: IKEv2IKE Responder Only: noSession Type: Policy Based Session

Скриншоты


Настройка со стороны Strongswan:

ipsec.conf 
# /etc/ipsec.confconfig setupconn %defaultdpdaction=cleardpddelay=35sdpdtimeout=300sfragmentation=yesrekey=noike=aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-sha256-sha1-modp2048-modp4096-modp1024,aes256-aes128-sha256-sha1-modp2048-modp4096-modp1024,3des-sha1-modp1024!esp=aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp2048-modp4096-modp1024,aes128-aes256-sha1-sha256-modp2048-modp4096-modp1024,aes128-sha1-modp2048,aes128-sha1-modp1024,3des-sha1-modp1024,aes128-aes256-sha1-sha256,aes128-sha1,3des-sha1!left=%anyleftsubnet=10.10.10.0/24        leftcert=certificate.pemleftfirewall=yesleftsendcert=alwaysright=%anyrightsourceip=192.168.1.0/24rightdns=77.88.8.8,8.8.4.4eap_identity=%identity# IKEv2conn IPSec-IKEv2keyexchange=ikev2auto=add# BlackBerry, Windows, Androidconn IPSec-IKEv2-EAPalso="IPSec-IKEv2"rightauth=eap-mschapv2# macOS, iOSconn IKEv2-MSCHAPv2-Applealso="IPSec-IKEv2"rightauth=eap-mschapv2leftid=vpn.linux.ext# Android IPsec Hybrid RSAconn IKEv1-Xauthkeyexchange=ikev1rightauth=xauthauto=add# VMWare IPSec VPNconn linux-nsx-pskauthby=secretauto=startleftid=vpn.linux.extleft=10.10.10.10leftsubnet=10.10.10.0/24rightid=33.33.33.33right=33.33.33.33rightsubnet=192.168.1.0/24ikelifetime=28800keyexchange=ikev2lifebytes=0lifepackets=0lifetime=1h

ipsec.secret 
# /etc/ipsec.secrets: RSA privkey.pem# Create VPN users accounts# ВНИМАНИЕ! После логина сначала пробел, потом двоеточие.user1 : EAP "stongPass1"user2 : EAP "stongPass2"%any 33.33.33.33 : PSK "ChangeMeNow!"

после этого достаточно перечитать конфиг, запустить соединение и проверить, что оно установлено:

ipsec updateipsec rereadsecretsipsec up linux-nsx-pskipsec status

Надеюсь, эта небольшая заметка окажется полезной и сэкономит кому-нибудь пару часов.
Подробнее..
Категории: Системное администрирование , Vpn , Ipsec , Nsx edge

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru