Linux ipsec mikrotik: Page not found

Содержание

IPSec между Debian и MikroTik

Коллеги с прошлой работы обратились за помощью. В одном удалённом офисе начались проблемы со связью, исправить которые провайдер не смог. В результате этот офис подключили к другому провайдеру. С предыдущим провайдером использовался DSL-модем, а компьютеры удалённого офиса подключались к центральному офису через индивидуальные подключения PPTP. Новый провайдер предоставляет услуги по Ethernet и поэтому DSL-модем нужно было заменить на что-то другое. В качестве замены они выбрали маршрутизатор MikroTik RB951G-2HnD, планируя заменить PPTP-подключения от каждого компьютера на общий туннель IPSec.

Не вдаваясь в детали, скажу что в центральном офисе установлен сервер под управлением Debian Squeeze, с которым и нужно было объединить MikroTik туннелем IPSec. На самом деле офис этот тоже не совсем центральный и имеется большой набор ресурсов, который доступен через каналы в вышестоящие локальные сети. Список используемых удалённым офисом ресурсов непостоянен, а потому стандартная настройка IPSec с шифрованием трафика между заранее известными сетями нам не подойдёт. В данном случае нужно считать, что за центральным офисом как бы находится сеть 0.0.0.0/0. В удалённом же офисе используется сеть 192.168.81.240/28.

Если изобразить это схематично, то получится такая схема:

[0.0.0.0/0] --- 192.168.81.1 debian 11.11.11.11 ==== 22.22.22.22 mikrotik 192.168.81.241 --- [192.168.81.240/28]

1. Хождение по мукам

Этот раздел можно безболезненно пропустить. Здесь я просто дал волю своей графомании и описал, какой ценой мне достался этот рецепт. Можете считать меня неудачником 🙂

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

В первый выходной я потратил на всё это безобразие около 9 часов и всё-таки поднял туннель, соединив внешний интерфейс маршрутизатора с внешним интерфейсом виртуальной машины под управлением Debian:

debian 11.11.11.11 === 11.11.11.12 mikrotik

Я, правда, так и не понял, чем настроенная конфигурация отличалась от той, которую я пытался настраивать первоначально. И так много времени ушло в этот раз скорее не на саму настройку, а на подготовительные работы — проброс VLAN, поиск нормально работающей системы для запуска виртуальных машин (воспользовался VirtualBox), её правильную настройку (нужно было собрать дополнительные модули для ядра Linux), скачивание и установку в виртуальную машину Debian Squeeze. Дополнительное время ушло на тупление с мостовым интерфейсом, который я настроить-настроил, а поднять забыл.

Ещё некоторое время было потрачено из-за моей невнимательности, когда IPSec стал требовать вдруг шифрования трафика и на локальном интерфейсе, в результате чего я потерял управление и мне пришлось сбрасывать MikroTik и настраивать его снова. Зато я узнал о существовании «безопасного режима» в RouterOS.

Наконец, после установки первоначального туннеля я потратил ещё некоторое время на шлифование конфигурации.

Во второй выходной я уже попытался воссоздать будущие условия работы маршрутизатора более точно. Сначала настроил такую схему, с дополнительной виртуалкой, которая изображала сеть провайдера и маршрутизировала трафик между Debian и MikroTik’ом:

debian 11.11.11.11 ==(провайдер)== 22.22.22.22 mikrotik

Далее я настроил ещё две виртуальные машины, каждая из которых изображала компьютер в офисе. Одна виртуальная машина изображала компьютер в центральном офисе, а вторая — в удалённом офисе. Получилась уже такая схема:

[192.168.80.113/24] --- 192.168.81.1 debian 11.11.11.11 ==(провайдер)== 22.22.22.22 mikrotik 192.168.81.241 --- [192.168.81.242/28]

Далее я потратил ещё некоторое время на тестирование настроек при включенном NAT на Debian. Дело в том, что NAT изменяет адрес отправителя (что ожидаемо — для этого он и предназначен). Из-за этого пакет с изменившимися IP-адресами отправителя и получателя может не попасть под правила IPSec и уйти не в удалённый офис через туннель IPSec, а уйти прямо в сеть провайдера безо всякого шифрования. Этот момент тоже нужно учитывать, чем я и занялся.

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

2. Настройка Debian

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

Перед настройкой укажу на особенность настраиваемого IPSec-туннеля. У этого туннеля нет IP-адресов конечных точек внутри туннеля. Фактически, IPSec хватает пакеты перед выходом из сетевого интерфейса, выполняет шифрование пакета и кладёт в IP-пакет, в котором указаны «белые» IP-адреса обеих сторон туннеля. Чтобы этот процесс не зациклился и пакеты не продолжали шифроваться и вкладываться снова и снова, IPSec’у чётко указываются правила, пакеты с какими IP-адресами необходимо подвергать обработке. Из-за такой особенности кажется весьма необычным, что пакеты с локальными IP-адресами маршрутизируются прямо через провайдерскую сеть. Очень важно понимать эту особенность, т.к. в противном случае при настройке IPSec можно натурально сойти с ума 🙂

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

# apt-get install ipsec-tools racoon

Прописываем настройки racoon в файле /etc/racoon/racoon.conf:

remote 22.22.22.22 {
        nat_traversal off;
        exchange_mode main;
        proposal {
                encryption_algorithm blowfish;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp6144;
        }
}

sainfo anonymous {
      pfs_group modp6144;
      lifetime time 1 hour;
      encryption_algorithm blowfish;
      authentication_algorithm hmac_sha1;
      compression_algorithm deflate;
}

При помощи утилиты pwgen из одноимённого пакета генерируем случайный будущий общий ключ:

$ pwgen 32

Помещаем ключ в файл /etc/racoon/psk.txt:

22.22.22.22 generated_psk_sequence

Настроим ipsec, отредактировав файл /etc/ipsec-tools.conf

flush;
spdflush;

spdadd 192.168.81.240/28 192.168.81.240/28 any -P out none;

spdadd 0.0.0.0/0 192.168.81.240/28 any -P out ipsec
        esp/tunnel/11.11.11.11-22.22.22.22/require;

spdadd 192.168.81.240/28 192.168.81.240/28 any -P in none;

spdadd 192.168.81.240/28 0.0.0.0/0 any -P in ipsec
        esp/tunnel/22.22.22.22-11.11.11.11/require;

Запустим настроенные демоны:

# /etc/init.d/setkey start
# /etc/init.d/racoon start

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

# ip route add to 192.168.81.240/28 via 11.11.11.11 src 11.11.11.11

Добавляем правила в пакетный фильтр для прохождения трафика IPSec:

# iptables -A INPUT -i eth0 -m udp -p udp -s 22.22.22.22 --dport 500 -j ACCEPT
# iptables -A INPUT -i eth0 -p ah -s 22.22.22.22 -j ACCEPT
# iptables -A INPUT -i eth0 -p esp -s 22.22.22.22 -j ACCEPT

Добавляем правила в пакетный фильтр для трафика из сети удалённого офиса к серверу Debian:

# iptables -A INPUT -i eth0 -s 192.168.81.240/28 -p tcp -m multiport --dport 25,53,80,110,143,3128 -j ACCEPT
# iptables -A INPUT -i eth0 -s 192.168.81.240/28 -p udp -m udp --dport 53 -j ACCEPT

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

# iptables -t nat -I POSTROUTING -o eth0 -d 192.168.81.240/28 -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 11.11.11.11

3. Настройка MikroTik

Внимание! Указанные ниже команды приведены для примера. Будьте внимательны и не копируйте их прямо в командную строку. Прежде чем выполнять любые примеры команд remove для начала проверьте при помощи команды print, что вы собрались удалить. Внимательно проверяйте IP-адреса и вообще — делайте что-то только если вы чётко представляете, зачем вы это делаете.

Добавляем новый адрес на локальном интерфейсе:

/ip address add interface=ether2-master-local address=192.168.81.241/28

Удаляем старый адрес 192.168.88.1, который был настроен на мостовом интерфейсе в конфигурации по умолчанию:

/ip address remove numbers=0

Переподключаемся на новый адрес, удаляем мостовой интерфейс:

/interface bridge remove numbers=0

Удаляем настройки DHCP-клиента на внешнем интерфейсе:

/ip dhcp-client remove numbers=0

Настраиваем новый внешний адрес:

/ip address add interface=ether1-gateway address=22.22.22.22/25

Настраиваем маршрут по умолчанию:

/ip route add gateway=22.22.22.1

Удаляем настройки NAT:

/ip firewal nat remove numbers=0

Удаляем правила пакетного фильтра:

/ip firewall filter remove numbers=0,1,2,3,4,5

Отключаем доступ к устройству по всем протоколам, кроме ssh:

/ip service disable numbers=0,1,2,5,6,7

Отключаем MAC-telnet (телнет с подключением по MAC-адресу, а не по IP-адресу):

/tool mac-server disable numbers=1,2,3,4,5,6

Теперь переходим к собственно настройке IPSec.

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

/ip ipsec proposal

set default auth-algorithms=sha1 \
enc-algorithms=blowfish \
lifetime=1h \
pfs-group=modp6144

Настраиваем политику, какой трафик шифровать:

/ip ipsec policy

add src-address=192.168.81.240/28 dst-address=192.168.81.240/28 \
sa-src-address=22.22.22.22 sa-dst-address=11.11.11.11 \
tunnel=no action=none

add src-address=192.168.81.240/28 dst-address=0.0.0.0/0 \
sa-src-address=22.22.22.22 sa-dst-address=11.11.11.11 \
tunnel=yes action=encrypt proposal=default

Настраиваем, с кем нужно установить соединение IPSec:

/ip ipsec peer

add address=11.11.11.11/32 local-address=22.22.22.22 port=500 \
auth-method=pre-shared-key secret="generated_psk_sequence" dh-group=modp6144 \
enc-algorithm=blowfish hash-algorithm=sha1 \
lifetime=1h nat-traversal=no

4. Использованные материалы

IPSEC между Mikrotik и Ubuntu (16/18/20) поверх IPIP туннеля.

В предыдущей статье рассмотрели IPIP туннель между микротиком и убунтой. Теперь добавим IPSEC между Mikrotik и Ubuntu на этот туннель с помощью пакета Stongswan.

Схему возьмём из предыдущей статьи, тут ничего принципиально не меняется:

IPSEC более мене стандартизирован, можно настраивать шифрование между различными устройствами.

ubuntu 16
ubuntu 18/20

Микротик

подготовка

Итак, IPIP туннель у нас уже есть. Правила фаервола в этой статье не рассматриваются, но для работы IPSEC требуется открытый порт 500, 4500 UDP, и протокол ipsec-esp, пример:
/ip firewall filter
add chain=input port=500,4500 protocol=udp comment=»Permit IPSec ports 500 and 4500″
add chain=input protocol=ipsec-esp comment=»Permit IPSec protocol ipsec-esp»
Можно настраивать IPSEC между Mikrotik и Ubuntu с помощью пароля, но это не мой метод. Поэтому сначала нам потребуются сертификаты:

сертификат микротика (пара открытый-закрытый сертификаты)
сертификат убунту (пара открытый-закрытый сертификаты)
CA (открытый сертификат)

Генерируемые сертификаты должны быть типа сервер(есть клиентские и серверные). Сгенерировать их можно по статьям на этом сайте (windows/linux). Я же использовал Cert Manager из pfsense.

Для микротика нужны будут сертификат микротика (пара открытый-закрытый серт-ключ), CA и ТОЛЬКО открытый серт ubuntu. Выделяем сгенерированные ранее файлы в файловом менеджере и перетаскиваем их в окно Winbox (для хардкорщиков можно scp использовать).

Затем переходим в раздел System — Certificates и нажимая кнопку Import добавляем нужные файлы. Открытый сертификат добавляется первым, ключ к нему, если нужен вторым.

После добавления файлов у нас должна получится примерно такая картинка:

T — означает что есть только открытый сертификат, KT — означает что у нас пара открытый сертификат и ключ к нему.
Для создания IPSEC между Mikrotik и Ubuntu потребуется пошагово заполнить разделы: Profiles, Peers, Identities, Proposals, Policies.

настройка

Итак, переходим в раздел IP — IPSEC, выбираем вкладку Profiles, жмём кнопку добавить, заполняем:

3des я убрал потому что это ненадёжный алгоритм. Вместо SHA1 выбрал SHA256 потому что сейчас это дефолтный алгоритм в Strongswan. DPD интервал уменьшил, что бы в случае падения туннеля шифрование быстрее поднималось. NAT-T нам не нужен — у нас нет НАТа на схеме.

Переходим на вкладку Peers и добавляем новый пир:

Address — внешний адрес убунту сервера. Local Address — локальный адрес микротика. Profile — имя профиля который мы добавили на предыдущем шаге.

Следующий шаг Identities:

Peer — то что мы заполняли выше. Auth Method — digital signature (мы используем сертификаты). Certificate — тут выбираем сертификат микротика (который KT). Remote Certificate — выбираем сертификат для Ubuntu. И последнее это Match By — certificate.

Peer does not exist

Suggestion use stronger pre-shared key or different authentication method

Эти надписи это какая-то недоработка винбокса, очевидно и пир у нас есть и метод авторизации более чем надёжный. Чтобы убрать предупреждение, сначала нажимаем Apply. Затем меняем Auth Method на pre shared key. Жмём ок, ок на предупреждении и ок ещё раз (три раза окей). Баг.

Переходим на вкладку Proposals, здесь всё как в Profiles (ну почти):

Последняя вкладка, Policies. Заполняем поля в двух вкладках: General и Action:

Src, Dst думаю итак понятно. Protocol — ip-encap, это тот самый IPIP туннель. Указываем протокол, что бы ничего другого кроме туннеля не шифровалось, например SSH доступ или ICMP пакеты. Proposal — выбираем то что заполняли на предыдущем этапе.

Это всё, переходим к Ubuntu.

Ubuntu

Версия Ubuntu не имеет значения, настройки идентичные

Для настройки IPSEC между Mikrotik и Ubuntu нам понадобится пакет Strongswan. Установка в две команды:

apt update
apt install strongswan

apt update

apt install strongswan

Для ubuntu нужны будут сертификат убунты (пара открытый-закрытый серт) и ТОЛЬКО открытый серт микротика. Тут так просто как с микротиком не выйдет, мышкой не перетащишь. Нужен SCP, в интернетах полно инструкций, надеюсь справитесь.

Копируем открытые сертификаты в папку /etc/ipsec.d/certs, закрытый ключ в /etc/ipsec.d/private. Что бы прописать закрытый ключ надо будет добавить в файл /etc/ipsec.secrets строчку с именем файла КЛЮЧА:

: RSA ubuntu-ipsec-test.key

Все настройки Strongswan хранятся в файле /etc/ipsec.conf, заполняем его примерно так:

config setup

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1

conn mikrotik
#ubuntu
left = 98.213.46.5
leftcert = ubuntu-ipsec-test.crt
leftprotoport = ipencap
#mikrotik
right = 145.16.220.86
rightcert = mikrotik-ipsec-test.crt
rightprotoport = ipencap
#general
type = transport
auto = add
#dpd
dpdaction = restart
dpddelay = 30s
dpdtimeout = 90s
#profile
ikelifetime = 1d
ike = aes128-sha256-modp1024
#proposals
lifetime = 30m
esp = aes128-sha256-modp1024

config setup

conn %default

ikelifetime=60m

keylife=20m

rekeymargin=3m

keyingtries=1

keyexchange=ikev1

conn mikrotik

#ubuntu

left = 98.213.46.5

leftcert = ubuntu-ipsec-test.crt

leftprotoport = ipencap

#mikrotik

right = 145.16.220.86

rightcert = mikrotik-ipsec-test.crt

rightprotoport = ipencap

#general

type = transport

auto = add

#dpd

dpdaction = restart

dpddelay = 30s

dpdtimeout = 90s

#profile

ikelifetime = 1d

ike = aes128-sha256-modp1024

#proposals

lifetime = 30m

esp = aes128-sha256-modp1024

Я думаю всё понятно итак, но остановлюсь на некоторых моментах:

conn — это имя подключения;
left это локальная сторона, наш Ubuntu сервер, мы указываем адрес, имя сертификата, протокол;
right — сторона микротика, аналогичные настройки;
type — тут два режима transport или tunnel. У нас уже есть IPIP туннель, поэтому нам нужен режим transport.
DPD, IKE, ESP итп мы просто заполняем также как заполняли их на микротике.

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

Для запуска IPSEC нам понадобится перечитать секреты:

и прочитать конфигурационный файл:

Затем запускаем подключение:

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

IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера

Linux: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0–91-generic x86_64)

Eth0 1.1.1.1/32 внешний IP
ipip-ipsec0 192.168.0.1/30 будет наш туннель

Miktoik: CCR 1009, RouterOS 6.46.5

Eth0 10.0.0.2/30 внутренний IP от провайдера. Внешний IP NAT провайдера динамический.
ipip-ipsec0 192.168.0.2/30 будет наш туннель

IPsec туннель на Linux машине будем поднимать с помощью racoon. Не буду описывать подробности, есть хорошая статья у vvpoloskin.

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

sudo install racoon ipsec-tools

Настраиваем racoon, он условно будет выступать в роли ipsec сервера. Так как mikrotik в main режиме не может передавать дополнительный идентификатор клиента, а внешний ip адрес через который он коннектится к Linux динамический, использовать preshared key (авторизацию по паролю) не получится, так как пароль должен сопоставляться либо с ip адресом подключающегося хоста, либо с идентификатором.

Будем использовать авторизацию по RSA ключам.

Демон racoon использует ключи в формате RSA, а miktork — в формате PEM. Если генерировать ключи утилитой plainrsa-gen идущей вместе с racoon, то конвертировать публичный ключ для Mikrotika в формат PEM с ее помощью не получится — она конвертирует только в одну сторону: PEM в RSA. Сгенерированный plainrsa-gen ключ не смогли прочитать ни openssl, ни ssh-keygen, поэтому с их помощью также не получится выполнить конвертацию.

Мы сгенерируем PEM ключ с помощью openssl, а затем конвертируем его для racoon с помощью plainrsa-gen:

#  Генерируем ключ
openssl genrsa -out server-name.pem 1024
# Извлекаем публичный ключ
openssl rsa -in server-name.pem -pubout > server-name.pub.pem
# Конвертируем
plainrsa-gen -i server-name.pem -f server-name.privet.key
plainrsa-gen -i server-name.pub.pem -f server-name.pub.key

Полученные ключи положим в папку: /etc/racoon/certs/server. Не забываем установить владельцем пользователя, от чьего имени запускается демон racoon (обычно root), права 600.

Настройку mikrotik опишу при подключении через WinBox.

Ключ server-name.pub.pem загрузим в mikrotik: Меню «Files» — «Upload».

Открываем раздел «IP» — «IP sec» — вкладка «Keys». Теперь генерируем ключи — кнопка «Generate Key», затем экспортируем публичный ключ mikrotika «Expor Pub. Key», скачать его можно из раздела «Files», правой кнопкой по файлу — «Download».

Импортируем публичный ключ racoon, «Import», в выпадающем списке поля «File name» ищем загруженный ранее нами server-name.pub.pem.

Публичный ключ mikrotik нужно сконвертировать

plainrsa-gen -i mikrotik.pub.pem -f mikrotik.pub.key

и положить в папку /etc/racoon/certs не забыв про владельца и права.

Конфиг racoon с комментариями: /etc/racoon/racoon.conf

log info; # Уровень логирования, при отладке используем Debug или Debug2.

listen {

    isakmp 1.1.1.1 [500]; # Адрес и порт, на котором будет слушать демон.
    isakmp_natt 1.1.1.1 [4500]; # Адрес и порт, на котором будет слушать демон для клиентов за NAT.
    strict_address; # Выполнять обязательную проверку привязки к указанным выше IP.
}

path certificate "/etc/racoon/certs"; # Путь до папки с сертификатами.

remote anonymous { # Секция, задающая параметры для работы демона с ISAKMP и согласования режимов с подключающимися хостами. Так как IP, с которого подключается Mikrotik, динамический, то используем anonymous, что разрешает подключение с любого адреса. Если IP у хостов статический, то можно указать конкретный адрес и порт.

    passive on; # Задает "серверный" режим работы демона, он не будет пытаться инициировать подключения.
    nat_traversal on; # Включает использование режима NAT-T для клиентов, если они за NAT. 
    exchange_mode main; # Режим обмена параметрами подключения, в данном случае ---согласование.
    my_identifier address 1.1.1.1; # Идентифицируем наш linux хост по его ip адресу.
    certificate_type plain_rsa "server/server-name.priv.key"; # Приватный ключ сервера.
    peers_certfile plain_rsa "mikrotik.pub.key"; # Публичный ключ Mikrotik.

    proposal_check claim; # Режим согласования параметров ISAKMP туннеля. Racoon будет использовать значения подключающегося хоста (инициатора) для срока действия сессии                   и длины ключа, если его срок действия сессии больше, или длина его ключа короче, чем у инициатора. Если срок действия сессии короче, чем у инициатора, racoon использует собственное значение срока действия сессии и будет отправлять сообщение RESPONDER-LIFETIME.
    proposal { # Параметры ISAKMP туннеля.

        encryption_algorithm aes; # Метод шифрования ISAKMP туннеля.
        hash_algorithm sha512; # Алгоритм хеширования, используемый для ISAKMP туннеля.
        authentication_method rsasig; # Режим аутентификации для ISAKMP туннеля - по RSA ключам.
        dh_group modp2048; # Длина ключа для алгоритма Диффи-Хеллмана при согласовании ISAKMP туннеля.
        lifetime time 86400 sec; Время действия сессии.
    }

    generate_policy on; # Автоматическое создание ESP туннелей из запроса, пришедшего от подключающегося хоста.
}

sainfo anonymous { # Параметры ESP туннелей, anonymous - указанные параметры будут использованы как параметры по умолчанию. Для разных клиентов, портов, протоколов можно              задавать разные параметры, сопоставление происходит по ip адресам, портам, протоколам.

    pfs_group modp2048; # Длина ключа для алгоритма Диффи-Хеллмана для ESP туннелей.
    lifetime time 28800 sec; # Срок действия ESP туннелей.
    encryption_algorithm aes; # Метод шифрования ESP туннелей.
    authentication_algorithm hmac_sha512; # Алгоритм хеширования, используемый для аутентификации ESP туннелей.
    compression_algorithm deflate; # Сжимать передаваемые данные, алгоритм сжатия предлагается только один.
}

Конфиг mikrotik

Возвращаемся в раздел «IP» — «IPsec»

Рестартуем демона racoon

sudo systemctl restart racoon

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

Демон racoon при загрузке ОС стартует раньше поднятия сетевых интерфейсов, а мы указали в секции listen опцию strict_address, необходимо добавить в файл systemd юнита racoon
/lib/systemd/system/racoon.service, в секцию [Unit], строку After=network.target.

Сейчас наши ipsec туннели должны подняться, смотрим вывод:

sudo ip xfrm policy

src 192.168.255.0/30 dst 192.168.255.0/30 
    dir out priority 2147483648 
    tmpl src 1.1.1.1 dst "IP NAT через который подключается mikrotik"
        proto esp reqid 0 mode tunnel
src 192.168.255.0/30 dst 192.168.255.0/30 
    dir fwd priority 2147483648 
    tmpl src "IP NAT через который подключается mikrotik" dst 1.1.1.1
        proto esp reqid 0 mode tunnel
src 192.168.255.0/30 dst 192.168.255.0/30 
    dir in priority 2147483648 
    tmpl src "IP NAT через который подключается mikrotik" dst 1.1.1.1
        proto esp reqid 0 mode tunnel

Если туннели не поднялись, смотрите syslog, либо journalctl -u racoon.

Теперь необходимо настроить L3 интерфейсы, чтобы можно было маршрутизировать трафик. Есть разные варианты, мы будем использовать IPIP, так как его mikrotik поддерживает, я бы использовал vti, но, к сожалению, в mikrotik его до сих пор не реализовали. От IPIP он отличается тем, что дополнительно может инкапсулировать multicast и ставить метки (fwmark) на пакеты, по которым можно их фильтровать в iptables и iproute2 (policy-based routing). Если нужна максимальная функциональность — тогда, например, GRE. Но не стоит забывать, что за дополнительную функциональность платим большим оверхедом.

Перевод неплохого обзора туннельных интерфейсов можно посмотреть тут.

На Linux:

# Создаем интерфейс
sudo ip tunnel add ipip-ipsec0 local 192.168.255.1 remote 192.168.255.2 mode ipip
# Активируем
sudo ip link set ipip-ipsec0 up
# Назначаем адрес
sudo ip addr add 192.168.255.1/30 dev ipip-ipsec0

Теперь можно добавить маршруты для сетей за mikrotik

sudo ip route add A.B.C.D/Prefix via 192.168.255.2

Чтобы наш интерфейс и маршруты поднимались после перезагрузки, нужно описать интерфейс в /etc/network/interfaces и там же в post-up добавлять маршруты, либо прописать все в одном файле, например, /etc/ipip-ipsec0.conf и дергать его через post-up, не забудьте про владельца файла, права и сделать его исполняемым.

Под катом пример файла

#!/bin/bash
ip tunnel add ipip-ipsec0 local 192.168.255.1 remote 192.168.255.2 mode ipip
ip link set ipip-ipsec0 up
ip addr add 192.168.255.1/30 dev ipip-ipsec0

ip route add A.B.C.D/Prefix via 192.168.255.2

На Mikrotik:

Раздел «Interfaces», добавляем новый интерфейс «IP tunnel»:

Раздел «IP» — «Addresses», добавляем адрес:

Теперь можно добавлять маршруты в сети за linux машиной, при добавлении маршрута, gateway будет наш интерфейс IPIP-IPsec0.

Так как наш сервер linux является транзитным, то на нем имеет смысл задать параметр Clamp TCP MSS для ipip интерфейсов:

создаем файл /etc/iptables.conf со следующим содержимым:

*mangle
-A POSTROUTING -o ipip+ -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT

и в /etc/network/interfaces
post-up iptables-restore

В сети за mikrotik у меня работает nginx (ip 10.10.10.1), делаем доступным его из интернета, добавим в /etc/iptables.conf:

*nat
-A PREROUTING -d 1.1.1.1/32 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 10.10.10.1
# Так же на linux работает OpenVPN сервер 172.16.0.1/24, для клиентов которые используют подключение к нему в качестве шлюза даем доступ в интернет
-A POSTROUTING -s 172.16.0.0/24 -o eth0 -j SNAT --to-source 1.1.1.1
COMMIT

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

Будьте здоровы!

IPSec: Туннель между Mikrotik и Openswan

Данная статья описывает способ организации шифрованного канала между двумя сетями, с одной стороны в качестве маршрутизатора выступает Mikrotik RouterBoard 750GL с другой Linux Debian 7.

Общая схема выглядит следующим образом:

192.168.0.0/24 — [Linux] eth0 x.x.x.x — Internet — [Mikrotik] y.y.y.y — 192.168.1.0/24

Для начала устанавливаем пакет openswan в Debian.

aptitude install openswan

aptitude install openswan

Конфигурационные файлы openswan /etc/ipsec.conf и /etc/ipsec.secrets

/etc/ipsec.secrets — содержит ключ шифрования между двумя точками

x.x.x.x y.y.y.y : PSK "secret_key"

x.x.x.x y.y.y.y : PSK «secret_key»

/etc/ipsec.conf — основной файл конфигурации

config setup
        interfaces="ipsec0=eth0" # Указываем транспортный интерфейс
        klipsdebug=none
        uniqueids=yes
 
conn %default # Общие параметры для всех подключений
        type=tunnel
        keyingtries=0
        disablearrivalcheck=no
        authby=secret
        esp=3des-sha1
        ike=3des-md5-modp1024
        keylife=8h
        keyexchange=ike
        left=x.x.x.x
        pfs=yes
 
conn mikrotik # Подключение к Mikrotik
        leftsubnet=192.168.0.0/24
        right=y.y.y.y
        rightsubnet=192.168.1.0/24
        auto=start

config setup
interfaces=»ipsec0=eth0″ # Указываем транспортный интерфейс
klipsdebug=none
uniqueids=yes

conn %default # Общие параметры для всех подключений
type=tunnel
keyingtries=0
disablearrivalcheck=no
authby=secret
esp=3des-sha1
ike=3des-md5-modp1024
keylife=8h
keyexchange=ike
left=x.x.x.x
pfs=yes

conn mikrotik # Подключение к Mikrotik
leftsubnet=192.168.0.0/24
right=y.y.y.y
rightsubnet=192.168.1.0/24
auto=start

Запуск openswan

Настройка Mikrotik состоит из двух шагов, настройка удаленного узла:

/ip ipsec peer
add address=x.x.x.x/32 enc-algorithm=3des hash-algorithm=md5 secret=secret_key

/ip ipsec peer
add address=x.x.x.x/32 enc-algorithm=3des hash-algorithm=md5 secret=secret_key

И настройка политики шифрования трафика:

/ip ipsec policy
add dst-address=192.168.0.0/24 sa-dst-address=x.x.x.x sa-src-address=y.y.y.y src-address=192.168.1.0/24 tunnel=yes

/ip ipsec policy
add dst-address=192.168.0.0/24 sa-dst-address=x.x.x.x sa-src-address=y.y.y.y src-address=192.168.1.0/24 tunnel=yes

Теперь все пакеты из 192.168.0.0/24 в 192.168.1.0/24 и обратно будут шифроваться.

Непростой IPSec с Linux | Admins.kz

Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях ~~стартапах~~ нет опыта организации таких схем, а из оборудования есть только VDS с Linuxом на борту. Более того, к моему удивлению, в рунете практически нет материалов с описанием инструментов траблшутинга под Linux. Попробуем устранить этот пробел и описать практическую часть настроек.

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

Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере 10.0.255.1 <-> 10.0.1.1), а сам сервис — между другими (192.168.255.1<-> 192.168.1.1). Такие схемы еще называются IPSec Network-Network.

Простой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком. Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:

Организовать транспорт (как будет происходить межсетевое взаимодействие).
Настроить сервис (запустить приложения непосредственно на серверах).

Итак, менеджер СуперСервис решил организовать подключение к какой-то крупной организации для решения бизнес-задачи. Он обратился к МегаТелеком, на что ему выслали технические условия по подключению. Одно из этих условий — организация IPSec. Это условие пришло в виде таблички excel, пример которой я представил ниже. На картинке я желтым выделил технически значимые параметры. Формат может отличаться, но суть остается той же.

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

Концепция IPSec

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

IPSec — набор техник и протоколов по организации защищенного соединения.

В отличии от прочих технологий туннелирования (GRE, PPP, L2TP, даже MPLS-TE) для IPSec не создается явных туннельных интерфейсов, через которые можно маршрутизировать трафик. Вместо этого в IPSec предусмотрена концепция так называемых Security Assotiations (SA). SA и есть туннель от одного сетевого устройства к другому. Но не стоит забывать, что SA — не сетевой интерфейс в нормальном понимании этого слова, классическая маршрутизация здесь не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Мы явно прописываем что-то типа аксес-листа (ACL) для пропуска трафика через определенную SA. Все эти вещи определены в так называемом фреймворке ISAKMP.

ISAKMP — описание процедур IPSec, в литературе называют его фреймворком. В нем описываются термины SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), необходимость установки вспомогательных туннелей… ISAKMP построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.
IKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.
Благодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.

Перед шифрованием трафика стороны должны договориться о параметрах (и ключах) этого шифрования. Для этого между обоими сторонами поднимается вспомогательный туннель (его еще называют ISAKMP туннель), который действует все время. Туннель этот двунаправленный, представляет из себя соединение по UDP (по умолчанию на порту 500). Для организации этого вспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.

Собственно организация IPSecа делится на две фазы:

Создание вспомогательного туннеля ISAKMP
Создание туннеля пользовательских данных

Как я писал, в концепции IPSec (а уже правильнее говорить, в концепции ISAKMP) туннели называются SA.

Первая фаза (организация ISAKMP SA) может осуществляться в двух режимах:

main — стороны поочередно обмениваются параметрами согласования. Считается более безопасным, используется для постоянных каналов (наш случай).
aggressive — инициатор в одном сообщении отправляет все необходимые параметры согласования, используется при подключении удаленного пользователя для временной сессии (чтобы быстрее).

Надо понимать, что основные SA-туннели однонаправленные. Для двусторонней передачи данных по IPSec каналу должно быть два туннеля: источник (src) → получатель (dst) и наоборот.

Во всех способах шифрования в оригинальный IP-пакет добавляются дополнительные заголовки, происходит инкапсуляция. Существует два способа этой инкапсуляции — AH (Authentication Header) и ESP (Encapsulation Security Payload). AH только аутентифицирует пакет (подписывает цифровой подписью отправителя), ESP и аутентифицирует (подписывает), и шифрует. На сегодняшний день AH уже практически не используется, все упаковывают в ESP.

Шифровать и аутентифицировать исходный IP-пакет можно без учета IP-заголовка (транспортный режим) или вместе с ним (туннельный режим). Транспортный используется тогда, когда планируется организовать свои туннели по другим технологиям (не IPSec/ESP). Например, GRE, l2tp, ppp. Для целей подключения какого-то сервиса ко внутренней инфраструктуре большой организации практически не используется. Я использовал такой сценарий для объединения нескольких офисов в один VPN через IPSec-и. Нам же более интересен туннельный режим. Как видно из картинки, здесь добавляется один дополнительный IP-заголовок.

Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.

Обратите внимание, что заголовок ESP встает до транспортных TCP/UDP. Помните, в заголовке IP-пакета есть поле Protocol? На основе этого поля сетевое оборудование (да и конечные хосты) корректно обрабатывают IP-пакеты. Так вот для ESP свой номер — 50. Полный список протоколов для этого поля можно посмотреть на вики, бывает весьма полезно.

Отсутствие заголовка транспортного уровня (TCP/UDP/ICMP уже зашифрованы!) накладывает ограничение на технологии типа NAT. Вспомните, NAT с трансляцией портов (overload, PAT, MASQARADE, у него много имен) работает на основе портов транспортных протоколов. А в зашифрованном туннеле IPSec их нет! Для преодоления этой проблемы есть такая технология, как IPSec NAT-Traversal (NAT-T). В ходе первой фазы стороны согласовывают возможность использовать NAT-T. Если обе стороны поддерживают NAT-T (да еще и на одинаковых UDP-портах), тогда в итоговых туннелях для трафика добавляется заголовок UDP, с которым пакеты уже пройдут через маршрутизаторы с трансляцией сетевых адресов.

Сам по себе туннель не поднимется, нужно направить туда трафик. Как я писал выше, здесь не работают правила маршрутизации, надо писать политики Security Policy (SP).

Политики состоят из адреса источника, адреса назначения, направления (in, out, fwd) и параметров пользовательских туннелей (здесь как раз описываются ESP это будет или AH, туннельный вариант или транспортный). Это больше похоже на организацию правил для NATа. NATу тоже недостаточно записей таблицы маршрутизации. И там тоже указываются правила откуда, куда и как, а не куда и через что. И также неверным движением руки можно завалить всю связь на удаленном сервере.

Все манипуляции с IPSec добавляют заголовки служебной информации. Минимум они съедят еще 40 байт от исходного пакета. Таким образом, например, при стандартном MTU для PPPoE в 1380 байт соединений реальное MTU будет < 1340.

IPSec в Linux

Займемся практикой на примере DEB-дистрибутивов. Я буду рассматривать только случай с авторизацией на основе pre-shared-key (PSK), будем настраивать схему из начала статьи.

Сам по себе IPSec поддерживается ядром, но поддержка эта весьма ограничена. В действительности ядреные модули занимаются только тем, что связано с шифрованием и уже полученными (переданными в ядро) ключами — обработка пакетов. А чтобы передать туда параметры и правила, с которыми нужно обрабатывать трафик, требуется отдельное программное обеспечение. В качестве такого софта есть несколько решений:

KAME, перекочевавший из BSD
xSWAN (strongswan, freeswan, libreswan, etc)
shorewall

Мне показался самым простым (самым предсказуемым) вариант KAME, его и будем крутить дальше.


root@localhost: ~

Традиционно KAME состоял из двух компонент

Демона racoon для управления туннелем ISAKMP.
Утилиты setkey для управления SA-туннелей с данными.

Начнем с первого. Racoon отвечает за параметры авторизации туннелей в рамках IKE. Это демон, он настраивается одним конфигурационным файлом (/etc/racoon.conf), запускается обычным init-скриптом (/etc/init.d/racoon <start|stop|restart>).

root@localhost: ~# cat /etc/racoon.conf

root@localhost: ~# cat /etc/racoon/psk.txt

Как всегда, подробности в man 5 racoon.conf

Дальше займемся утилитой setkey. Она тоже запускается как демон (/etc/init.d/setkey <start|stop|restart>), но по факту она выполняет скрипт /etc/ipsec-tools.conf. Как я и говорил, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них. Это что-то вроде crypto-map на ASA. Самый простой вариант для нас — добавить просто SP. Тогда SA построится автоматически исходя из параметров второй фазы, указанной в настройках racoon.

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

root@localhost: ~# cat /etc/ipsec-tools.conf

На текущий момент утилиту setkey дублирует модуль iproute2.
В рамках него есть две команды управления записями SA и SP.

ip xfrm state
ip xfrm policy

Помимо управления этой же утилитой можно смотреть состояние организованных SA и применяемых к трафику SP. Подробнее в man 8 ip-xfrm.

Взгляните еще раз на изначальную табличку. Там указаны разные IP-адреса для IPSec и сервиса. По внутреннему IP-адресу идет фильтрация внутри инфраструктуры Мегателеком. Но у нас всего лишь одна виртуальная машина. На ней должен как-то появиться внутренний IP-адрес, и пакеты в туннель должны уходить именно с него. Есть несколько вариантов добиться этого сценария:
Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
Трансляция адресов (NAT/MASQARADE).
С моей точки зрения здесь подходит первый вариант.
Мы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth2 label eth2:1
и настроить маршрут до сервера Мегателеком с этого IP-адреса.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth2:1 src 192.168.1.1
Но если так сделать, ничего не заведется. Дело в том, что при добавлении маршрута в таком виде Linux-станция будет пытаться определить MAC-адрес получателя, делать она это будет через ARP… Компьютер будет слать запросы ARP Who has IP 192.168.255.1. Так как 192.168.255.1 нет в той же сети, где и 192.168.1.1 (маска /32!), ответа на ARP не будет. Зато при попытке соединения будет возвращаться с локального IP-адреса будет возвращаться No route to host. Чтобы это победить, нам надо задать статическую ARP-запись:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth2:1
Такой вот лайфхак. Кстати, такие манипуляции могут привести не совсем к коректной работе IP-стека Linux. В одном из случаев команды ip route не приводили к нужному результату, пришлось перезагружать сетевой стек.

Проверка работоспособности

Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до назначения.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
С небольшой задержкой должны быть ответы с обратной стороны (если конечно ICMP нигде не закрыт на участке).

Мы можем увидеть, поднялся ли ISAKMP-туннель

racoonctl show-sa isakmp

Также мы можем посмотреть туннели с пользовательскими данными

racoonctl show-sa esp

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

root@localhost: ~# tcpdump -i eth2 host 10.0.255.1

При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:
root@localhost: ~# tcpdump -i eth2 -w ipsec.pcap esp &
Запускаем ping, telnet, netcat…
root@localhost: ~# killall tcpdump root@localhost: ~# tcpdump -vr ipsec.pcap

Также в логах можно увидеть успешный статус установления соединения. В нем видно успешное установление обоих фаз IPSec.

root@localhost: ~# cat /var/log/daemon.log

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

P. S.: Просьба обо всех ошибках или неточностях в статье сообщать личным сообщением. Когда я подправлю статью, комментарии будут смотреться глупо.

Источник: https://habr.com/ru/post/425079/

на Ваш сайт.

Настройка VPN L2TP+IpSec между MikroTik и CentOS 8

Большая доля серверной инфраструктуры имеет облачное размещение в виде VPS и VDS серверов, одним из требованием к которой является организация удаленного доступа через защищенные каналы. Данным каналом будет выступать VPN туннель на базе L2TP+IpSec.

В прошлых инструкция рассматривались разные разновидности VPN серверов:

А данная конфигурация будет отличаться тем, что одним из звеньев VPN туннеля будет облачный VPS на CentOS 8.

Какие задачи может решить VPN туннель между MikroTik и VPS CentOS 8

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

Предоставления доступа к локальному серверу;
Маршрутизация трафика через удаленный сервер.

В данной инструкции будет рассмотрен второй вариант, когда локальный трафик будет маршрутизироваться через удаленный сервер. Размещение при этом не играет ни какой роли: США, Германия, Болгария, Россия, Япония. Схематически это будет выследить так:

Как настроить VPN L2TP+IpSec между MikroTik и VPS CentOS 8

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

1. Настройка VPN сервера L2TP на удаленном VPS сервере на CentOS 8

Подключение к удаленному серверу VPS будет производиться через SSH:

yum install nano mc -y

создание скрипта по установке и настройке VPN сервера L2TP+IpSec

Поддержи автора статьи, сделай клик по рекламе ↓↓↓

nano vpnsetup. -~]\+'; then
exiterr "VPN credentials must not contain non-ASCII characters."
fi

case "$VPN_IPSEC_PSK $VPN_USER $VPN_PASSWORD" in
*[\\\"\']*)
exiterr "VPN credentials must not contain these special characters: \\ \" '"
;;
esac

bigecho "VPN setup in progress... Please be patient."

# Create and change to working dir
mkdir -p /opt/src
cd /opt/src || exit 1

bigecho "Installing packages required for setup..."

yum -y install wget bind-utils openssl tar \
iptables iproute gawk grep sed net-tools || exiterr2

bigecho "Trying to auto discover IP of this server..."

cat <<'EOF'
In case the script hangs here for more than a few minutes,
press Ctrl-C to abort. Then edit it and manually enter IP.
EOF

# In case auto IP discovery fails, enter server's public IP here.
PUBLIC_IP=${VPN_PUBLIC_IP:-''}

[ -z "$PUBLIC_IP" ] && PUBLIC_IP=$(dig @resolver1.opendns.com -t A -4 myip.opendns.com +short)

check_ip "$PUBLIC_IP" || PUBLIC_IP=$(wget -t 3 -T 15 -qO- http://ipv4.icanhazip.com)
check_ip "$PUBLIC_IP" || exiterr "Cannot detect this server's public IP. Edit the script and manually enter it."

bigecho "Adding the EPEL repository..."

epel_url="https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E '%{rhel}').noarch.rpm"
yum -y install epel-release || yum -y install "$epel_url" || exiterr2

bigecho "Installing packages required for the VPN..."

REPO1='--enablerepo=epel'
REPO2='--enablerepo=*server-optional*'
REPO3='--enablerepo=*releases-optional*'
REPO4='--enablerepo=[Pp]ower[Tt]ools'

yum -y install nss-devel nspr-devel pkgconfig pam-devel \
libcap-ng-devel libselinux-devel curl-devel nss-tools \
flex bison gcc make ppp || exiterr2

yum "$REPO1" -y install xl2tpd || exiterr2

if grep -qs "release 6" /etc/redhat-release; then
yum -y remove libevent-devel
yum "$REPO2" "$REPO3" -y install libevent2-devel fipscheck-devel || exiterr2
elif grep -qs "release 7" /etc/redhat-release; then
yum -y install systemd-devel iptables-services || exiterr2
yum "$REPO2" "$REPO3" -y install libevent-devel fipscheck-devel || exiterr2
else
if [ -f /usr/sbin/subscription-manager ]; then
subscription-manager repos --enable "codeready-builder-for-rhel-8-*-rpms"
yum -y install systemd-devel iptables-services libevent-devel fipscheck-devel || exiterr2
else
yum "$REPO4" -y install systemd-devel iptables-services libevent-devel fipscheck-devel || exiterr2
fi
fi

bigecho "Installing Fail2Ban to protect SSH.processor /proc/cpuinfo)
[ -z "$NPROCS" ] && NPROCS=1
make "-j$((NPROCS+1))" -s base && make -s install-base

cd /opt/src || exit 1
/bin/rm -rf "/opt/src/libreswan-$SWAN_VER"
if ! /usr/local/sbin/ipsec --version 2>/dev/null | grep -qF "$SWAN_VER"; then
exiterr "Libreswan $SWAN_VER failed to build."
fi

bigecho "Creating VPN configuration..."

L2TP_NET=${VPN_L2TP_NET:-'192.168.41.0/24'}
L2TP_LOCAL=${VPN_L2TP_LOCAL:-'192.168.41.1'}
L2TP_POOL=${VPN_L2TP_POOL:-'192.168.41.10-192.168.41.250'}
XAUTH_NET=${VPN_XAUTH_NET:-'192.168.43.0/24'}
XAUTH_POOL=${VPN_XAUTH_POOL:-'192.168.43.10-192.168.43.250'}
DNS_SRV1=${VPN_DNS_SRV1:-'8.8.8.8'}
DNS_SRV2=${VPN_DNS_SRV2:-'8.8.4.4'}
DNS_SRVS="\"$DNS_SRV1 $DNS_SRV2\""
[ -n "$VPN_DNS_SRV1" ] && [ -z "$VPN_DNS_SRV2" ] && DNS_SRVS="$DNS_SRV1"

# Create IPsec config
conf_bk "/etc/ipsec.conf"
cat > /etc/ipsec.conf <<EOF
version 2.0

config setup
virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!$L2TP_NET,%v4:!$XAUTH_NET
protostack=netkey
interfaces=%defaultroute
uniqueids=no

conn shared
left=%defaultroute
leftid=$PUBLIC_IP
right=%any
encapsulation=yes
authby=secret
pfs=no
rekey=no
keyingtries=5
dpddelay=30
dpdtimeout=120
dpdaction=clear
ikev2=never
ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1,aes256-sha2;modp1024,aes128-sha1;modp1024
phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes256-sha2_512,aes128-sha2,aes256-sha2
sha2-truncbug=no

conn l2tp-psk
auto=add
leftprotoport=17/1701
rightprotoport=17/%any
type=transport
phase2=esp
also=shared

conn xauth-psk
auto=add
leftsubnet=0.0.0.0/0
rightaddresspool=$XAUTH_POOL
modecfgdns=$DNS_SRVS
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=file
ike-frag=yes
cisco-unity=yes
also=shared
EOF

# Specify IPsec PSK
conf_bk "/etc/ipsec.secrets"
cat > /etc/ipsec.secrets <<EOF
%any %any : PSK "$VPN_IPSEC_PSK"
EOF

# Create xl2tpd config
conf_bk "/etc/xl2tpd/xl2tpd.conf"
cat > /etc/xl2tpd/xl2tpd.conf <<EOF
[global]
port = 1701

[lns default]
ip range = $L2TP_POOL
local ip = $L2TP_LOCAL
require chap = yes
refuse pap = yes
require authentication = yes
name = l2tpd
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
EOF

# Set xl2tpd options
conf_bk "/etc/ppp/options.xl2tpd"
cat > /etc/ppp/options.xl2tpd <<EOF
+mschap-v2
ipcp-accept-local
ipcp-accept-remote
noccp
auth
mtu 1280
mru 1280
proxyarp
lcp-echo-failure 4
lcp-echo-interval 30
connect-delay 5000
ms-dns $DNS_SRV1
EOF

if [ -z "$VPN_DNS_SRV1" ] || [ -n "$VPN_DNS_SRV2" ]; then
cat >> /etc/ppp/options.xl2tpd <<EOF
ms-dns $DNS_SRV2
EOF
fi

# Create VPN credentials
conf_bk "/etc/ppp/chap-secrets"
cat > /etc/ppp/chap-secrets <<EOF
"$VPN_USER" l2tpd "$VPN_PASSWORD" *
EOF

conf_bk "/etc/ipsec.d/passwd"
VPN_PASSWORD_ENC=$(openssl passwd -1 "$VPN_PASSWORD")
cat > /etc/ipsec.d/passwd <<EOF
$VPN_USER:$VPN_PASSWORD_ENC:xauth-psk
EOF

bigecho "Updating sysctl settings..."

if ! grep -qs "hwdsl2 VPN script" /etc/sysctl.conf; then
conf_bk "/etc/sysctl.conf"
if [ "$(getconf LONG_BIT)" = "64" ]; then
SHM_MAX=68719476736
SHM_ALL=4294967296
else
SHM_MAX=4294967295
SHM_ALL=268435456
fi
cat >> /etc/sysctl.conf <<EOF

# Added by hwdsl2 VPN script
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = $SHM_MAX
kernel.shmall = $SHM_ALL

net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.$NET_IFACE.send_redirects = 0
net.ipv4.conf.$NET_IFACE.rp_filter = 0

net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
EOF
fi

bigecho "Updating IPTables rules..."

# Check if rules need updating
ipt_flag=0
IPT_FILE="/etc/sysconfig/iptables"
if ! grep -qs "hwdsl2 VPN script" "$IPT_FILE" \
|| ! iptables -t nat -C POSTROUTING -s "$L2TP_NET" -o "$NET_IFACE" -j MASQUERADE 2>/dev/null \
|| ! iptables -t nat -C POSTROUTING -s "$XAUTH_NET" -o "$NET_IFACE" -m policy --dir out --pol none -j MASQUERADE 2>/dev/null; then
ipt_flag=1
fi

# Add IPTables rules for VPN
if [ "$ipt_flag" = "1" ]; then
service fail2ban stop >/dev/null 2>&1
iptables-save > "$IPT_FILE.old-$SYS_DT"
iptables -I INPUT 1 -p udp --dport 1701 -m policy --dir in --pol none -j DROP
iptables -I INPUT 2 -m conntrack --ctstate INVALID -j DROP
iptables -I INPUT 3 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I INPUT 4 -p udp -m multiport --dports 500,4500 -j ACCEPT
iptables -I INPUT 5 -p udp --dport 1701 -m policy --dir in --pol ipsec -j ACCEPT
iptables -I INPUT 6 -p udp --dport 1701 -j DROP
iptables -I FORWARD 1 -m conntrack --ctstate INVALID -j DROP
iptables -I FORWARD 2 -i "$NET_IFACE" -o ppp+ -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 3 -i ppp+ -o "$NET_IFACE" -j ACCEPT
iptables -I FORWARD 4 -i ppp+ -o ppp+ -s "$L2TP_NET" -d "$L2TP_NET" -j ACCEPT
iptables -I FORWARD 5 -i "$NET_IFACE" -d "$XAUTH_NET" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 6 -s "$XAUTH_NET" -o "$NET_IFACE" -j ACCEPT
# Uncomment if you wish to disallow traffic between VPN clients themselves
# iptables -I FORWARD 2 -i ppp+ -o ppp+ -s "$L2TP_NET" -d "$L2TP_NET" -j DROP
# iptables -I FORWARD 3 -s "$XAUTH_NET" -d "$XAUTH_NET" -j DROP
iptables -A FORWARD -j DROP
iptables -t nat -I POSTROUTING -s "$XAUTH_NET" -o "$NET_IFACE" -m policy --dir out --pol none -j MASQUERADE
iptables -t nat -I POSTROUTING -s "$L2TP_NET" -o "$NET_IFACE" -j MASQUERADE
echo "# Modified by hwdsl2 VPN script" > "$IPT_FILE"
iptables-save >> "$IPT_FILE"
fi

bigecho "Creating basic Fail2Ban rules./#/' /usr/lib/systemd/system/xl2tpd.service
systemctl daemon-reload
fi
fi

# Restart services
mkdir -p /run/pluto
modprobe -q pppol2tp
service fail2ban restart 2>/dev/null
service ipsec restart 2>/dev/null
service xl2tpd restart 2>/dev/null

cat <<EOF

================================================

IPsec VPN server is now ready for use!

Connect to your new VPN with these details:

Server IP: $PUBLIC_IP
IPsec PSK: $VPN_IPSEC_PSK
Username: $VPN_USER
Password: $VPN_PASSWORD

Write these down. You'll need them to connect!

Important notes: https://git.io/vpnnotes
Setup VPN clients: https://git.io/vpnclients
IKEv2 guide: https://git.io/ikev2

================================================

EOF

}

## Defer setup until we have the complete script
vpnsetup "[email protected]"

exit 0

Если потребует изменить параметры сетевой адресации, нужно обратить внимание на этот раздел

L2TP_NET=${VPN_L2TP_NET:-'192.168.41.0/24'}
L2TP_LOCAL=${VPN_L2TP_LOCAL:-'192.168.41.1'}
L2TP_POOL=${VPN_L2TP_POOL:-'192.168.41.10-192.168.41.250'}

выполнение скрипта

sh vpnsetup.sh

По окончанию работы скрипт выводит параметры, которые нужно использовать на MikroTik L2TP клиенте:

Server IP: 18.13.12.14
IPsec PSK: YsH8f7ke3r6i6TBB5pZu
Username: vpnuser
Password: 2FG2i3aTHm3b7soo

Для работы интернета локальной сети за MikroTik-ом, нужно поправить IPTABLES

nano /etc/sysconfig/iptables

-A POSTROUTING -s 192.168.10.0/24 -o ens3 -j MASQUERADE
-A FORWARD -s 192.168.10.0/24 -d 192.168.10.0/24 -i ppp+ -o ppp+ -j ACCEPT

systemctl restart iptables

Файл xl2tpd.conf содержит настройки VPN сервера:

nano /etc/xl2tpd/xl2tpd.conf

[global]
port = 1701

[lns default]
ip range = 192.168.41.10-192.168.41.250
local ip = 192.168.41.1
require chap = yes
refuse pap = yes
require authentication = yes
name = l2tpd
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

добавить маршрут в сеть за MikroTik. Это правило будет отрабатывать каждый раз, когда туннель будет подниматься

nano /etc/ppp/ip-up

ip route add 192.168.10.0/24 via 192.168.41.10

где

192.168.10.0/24 – сеть за MikroTik

192.168.41.10 – адрес MikroTik на стороне CentOS 8.

2. Настройка L2TP клиента на MikroTik

Со стороны MikroTik нужно затронуть два раздела: PPP клиент и маршрутизацию.

Добавление L2TP клиента

Настройка находится в PPP→Interface

/ppp profile
/interface l2tp-client
add comment=VPS-CentOS connect-to=18.13.12.14 disabled=no ipsec-secret=\
YsH8f7ke3r6i6TBB5pZu name=l2tp-out1 password=2FG2i3aTHm3b7soo profile=\
default use-ipsec=yes user=vpnuser

Успешное соединение, сопровождается статусом “R”

Добавить статический маршрут. Весь интернет трафик будет заворачиваться в VPN туннель через CentOS VPS

Настройка находится в IP→Routes

/ip route
add distance=1 gateway=192.168.41.1

А у прежнего интернет маршрута, необходимо понизить Distance до 2

/ip route
add distance=2 gateway=94.2.XX.YY

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

Поддержи автора статьи, сделай клик по рекламе ↓↓↓

Есть вопросы или предложения по настройке VPN типа L2TP+IpSec между MikroTik и CentOS? Активно предлагай свой вариант настройки! Оставить комментарий →

l2tp/ipsec на Centos — Asterisk IP-телефония

При
использовании OpenVPN между сервером на Centos и роутером MikroTik SOHO сегмента можно столкнуться с
проблемой, когда процессор на роутере загружен на 100%, а скорость передачи
данных не превышает 7-8 мегабит. Это связано с тем, что OpenVPN на микротике очень требовательный к
ресурсам процессора. На слабых устройствах не рекомендуется применять этот вид
туннелей.

При
использовании L2TP можно добиться на порядок большей
производительности. Трафик через L2TP туннель сам по себе передается в нешифрованном виде. Для
шифрования трафика используют связку с IPSEC.

IPSEC — это набор протоколов применяющихся для проверки подлинности,
целостности и шифрования данных.

Для
настройки IPSEC на операционных системах Linux можно использовать три пакета: «racoon, strongswan, libreswan».

В нашем
случае мы будем делать тунель на сервере с операционной системой Centos7 с помощью пакета «racoon».

Если у вас
еще не установлен репозиторий Epel-release установите его следуюзей командой:

# yum install epel-release

Установка репозитория

Raccoon входит в состав пакета «ipsec-tools». Установим его:

# yum install ipsec-tools

Установка пакетов, для работы с ipsec

Приступим к
настройке racoon. Конфигурационный файл находится: «/etc/racoon/racoon.conf»

Конфигурационный файл racoon.conf

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

sainfo anonymous
{
        #pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}

remote anonymous
{
        exchange_mode    main,aggressive,base;
        doi              ipsec_doi;
        passive          on;
        proposal_check   obey;
        support_proxy    on;
        nat_traversal    on;
        ike_frag         on;
        dpd_delay        20;
        proposal
        {
                encryption_algorithm  aes;
                hash_algorithm        sha1;
                authentication_method pre_shared_key;
                dh_group              modp1024;
        }
        proposal
        {
                encryption_algorithm  3des;
                hash_algorithm        sha1;
                authentication_method pre_shared_key;
                dh_group              modp1024;
        }
}

Те
строчки, которые начинаются с символа «#» считаются комментариями и не влияют
на конфигурационный файл.

Далее
идет секция «sainfo». В этой секции описываются
правила «ассоциации безопасности» второй фазы. Тут указываются параметры IKE.

IKE это протокол используемый для защищенного согласования и доставки идентификационного материала для «ассоциации безопасности».

Sainfo anonymous – применять это правило для всех подключений.
lifetime time — этот параметр задает срок жизни ассоциации безопасности (через какое время менять ключи).
encryption_algorithm – определяются алгоритмы шифрования.
authentication_algorithm – определяются алгоритмы хэша при проверке подлинности.
compression_algorithm – алгоритм сжатия.

Далее
идет раздел «remote anonymous». Блок настроек, применяемый к соединению с удаленным хостом (Параметры для IKE первой фазы). Если указан «anonymous», настройки применяются к любому хосту. Также можно
указать конкретный ip либо подсеть.

exchange_mode — определяет режим проверки подлинности для фазы 1.
doi — область интерпретации защиты ip (Domain of Interpretation, являющийся базой данных, хранящей сведения об алгоритмах).
Passive – когда пассивный режим включен, он будет ожидать, пока удаленный узел не установит соединение IKE. Включенный пассивный режим также указывает на то, что узел является ответчиком. Отключенный пассивный режим является инициатором соединения.
proposal_check – проверка ресурса фазы 2. В нашем случае принимать все, что отправлено инициатором.
support_proxy – поддержка прокси.
nat_traversal – параметр для решения проблемы NAT.
ike_frag – IKE фрагментация на принимающей стороне. Применяется в случае плохого фаервола, имеющего проблемы с фрагментацией UDP.
dpd_delay – проверка соединения. В нашем случае раз в 20 секунд.

После
этого идет вложенный блок «proposal». Это
метод аутентификации (шифрование клиентов).

encryption_algorithm – алгоритм шифрования для фазы 1.
hash_algorithm – хэш алгоритм для фазы 1.
authentication_method – Метод аутентификации (в нашем случае используется ключ.)
dh_group – группа для Диффи-Хельмана.

После
внесения конфигурационных данных необходимо указать ключ IPSEC. Ключ прописывается в файле «/etc/raccoon/psk.txt»

Указание ключа IPSEC

Далее
необходимо создать скрипт с настройками IPSEC политик. Пропишем в файле «/etc/rc.d/init.d/raccoon.init»

Настройка политики IPSEC

Spdflush b
flush очищают от записей базы данных SPD и SAD.

SPD – политики безопасности (Security Policy Database). SAD – безопасные ассоциации (Security Associations Database)

spdadd 0.0.0.0/0[l2tp] 0.0.0.0/0 any -P out ipsec esp/transport//require; — первый адрес это src адрес отправителя. Второй адрес – dst (адрес получателя).

Any – доверить любой протокол программе.

-P – исходящие пакеты будут подвергаться обработке IPSEC.

esp/transport//require; — на транспортном уровне всегда требовать SA (Security Association).

Последняя
строчка делает тоже, что и предыдущая, но для входящих пакетов.

Далее
задаем права на файл:

# chmod 755 /etc/rc.d/init.d/raccoon.init

Для
того, чтобы правила применялись после перезагрузки, добавим строчку
«/etc/rc.d/init.d/racoon.init» в файл /etc/rc/local.

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

Установим
пакет xl2tpd:

# yum install –y xl2tpd

В
конфигурационом файле «/etc/xl2tpd/xl2tpd.conf» необходимо внести следующие настройки:

Конфигурационный файл l2tp

В
секции «[global]» описываются глобальные настройки.

Ipsec saref – когда этот параметр имеет значение «yes», пакеты полученные для xl2tpd должны иметь дополнительные поля (refme и refhim). Это позволяет работать с клиентами за NAT.
force userspace= yes – это параметр значительно улучшает производительность.
[lns default] – Имя нашего сервера
Ip range – пул ip из которого клиенты будут получать ip адрес.
Local ip – ip адрес сервера
Refuse pap — требовать или отказывать удалённому peer’у (VPN-клиенту) в PPP-аутентификации по протоколу PAP.
Require authentication — требовать или отказывать удалённому VPN-клиенту в PPP-аутентификации.
Name — имя узла, которое xl2tpd будет отправлять VPN-клиенту в процессе согласования подключения с удалённым пиром.
Ppp debug – включить режим отладки
Pppoptfile – файл логов
Length bit — если значение установлено в «yes», то будет использован бит длины, указывающий полезную нагрузку (payload) l2tp-пакета.

Теперь
настроим протокол PPP для установления соединения.

Открываем
файл «/etc/ppp/options.xl2tpd» и вносим следующие правки:

Конфигурационный файл PPP

Ipcp-accept-local — при указании этой опции pppd будет принимать локальный IP-адрес предложенный партнёром, даже если IP-адрес был явно указан с помощью опции.
ipcp-accept-remote — при указании этой опции pppd будет принимать удалённый IP-адрес предложенный партнёром, даже если IP-адрес был явно указан с помощью опции.
Ms-dns – прописывает у клиента dns
Noccp – отключить протокол управления сжатием.
Name — при аутентификации pppd будет использовать пароль из той строки в файле паролей, у которой во втором поле указано имя.
Persist – не завершать работу сразу после разрыва соединения.
Auth – Требовать от партнера подтвердить свою подлинность перед разрешением отправки и приема пакетов.
Crtscts — Указывает, что pppd должен настроить последовательный порт для использования аппаратного управления потоком.
Mtu – размер пакета
Mru — максимальный размер данных, передаваемых в пакете протокола PPP, не включая заголовок пакета.
Nodefaultroute – не устанавливать маршрут по умолчанию.
Debug — режим отладки
lock — указывает, что pppd должен создать для последовательного устройства файл блокировки в стиле UUCP, чтобы удостовериться в эксклюзивном доступе. По умолчанию pppd не создаёт файл блокировки.
Proxyarp – добавляет arp запись.
require-mschap-v2 требовать у партнёра аутентификации с помощью MS-CHAPv2.
Logfile – файл журналирования.

Далее
необходимо отредактировать файл с пользователями «/etc/ppp/chap-secrets»:

настройка пользователей.

Первый
параметр это логин клиента. Второй параметр любой сервер. Третий – пароль
пользователя. Четвертый «*» подключение с любого ip адреса.

После
конфигурирования запускаем все службы:

# service racoon start
#chkconfig racoon on
#service xl2tpd start
#chkconfig xl2tpd on

Проверяем,
поднялся ли тунель:

Работа тунеля

IPsec VPN Mikrotik для Linux

После написания статьи Mikrotik IPsec VPN я получил несколько вопросов о том, как Mikrotik будет работать с устройством Linux для создания IPsec VPN. Я заметил, что вопросы были больше ориентированы на решение для копирования / вставки, поэтому я покажу одно, что оно работает. Если вам нужны более подробные сведения о том, почему такое решение, пожалуйста, дайте мне знать.
Также не забудьте настроить решение по своему усмотрению.

Я начну с той же топологии, что и в предыдущем посте, только с правой стороны, теперь это устройство Linux.

Пожалуйста, рассмотрите минимальное количество портов, которые должны быть открыты на вашем брандмауэре из моей предыдущей статьи. Только не забудьте открыть эти порты и на устройстве Linux.

Сначала настроим Mikrotik.

Предложение IPsec

CLI

 ipsec предложение добавить имя = MyProposal auth-алгоритмы = sha1 enc-алгоритмы = aes-256-cbc pfs-group = none

GUI

IP> IPsec> Предложения

 Имя: MyProposal
Авт.Алгоритм: sha1
Encr. Алгоритм: aes-256 cbc
Группа PFS: нет

Политика IPsec

CLI

 ipsec policy add src-address = 192.168.0.0 / 24 dst-address = 172.30.0.0 / 24 protocol = all action = encrypt level = require ipsec -tocols = esp tunnel = yes sa-src-address = 11.11.11.11 sa -dst-address = 22.22.22.22 предложение = MyProposal

GUI

IP> IPsec> Политики

 АДРЕС SRC: 192.168.0.0/24
АДРЕС НА летнее время: 172.30.0.0 / 24
Протокол: все
Действие: зашифровать
Уровень: требуется
Протоколы IPsec: esp
Туннель: проверить
SA SRC: 11.11.11.11
Летнее время (SA): 22.22.22.22
Предложение: MyProposal

Узел IPsec

CLI

 ipsec peer add address = 22.22.22.22 port = 500 auth-method = pre-shared-key secret = my_preshared_key exchange-mode = main send-initial-contact = yes nat-traversal = yes offer-check = соблюдать алгоритм хеширования = sha1 enc-algorithm = 3des, aes-128 dh-group = modp1024 generate-policy = no

GUI

IP> IPsec> Одноранговые узлы

 Адрес: 22.22.22.22
Порт: 500
Авт. Метод: предварительный общий ключ
Пассивный: не проверено
Секрет: my_preshared_key
Группа шаблонов политики: по умолчанию
Режим обмена: основной
Отправить первоначальный контакт: отмечено
NAT Traversal: проверено
Мой ID: Авто - пусто
Проверка предложения: подчиняться
Алгоритм хеширования: sha1
Алгоритм шифрования: 3des aes-128
Группа DH: modp1024
Создать политику: нет

Теперь о Linux. Я использую Ubuntu, но я не собираюсь здесь пропагандировать ту или иную разновидность. Итак, просто используйте любое устройство с Linux или попробуйте такие решения, как Amazon AWS.Установите Openswan (скомпилируйте его из исходного кода или установите через вашу систему пакетов Linux).

Главный файл Openswan — ipsec.conf. Для меня этот файл находится в / etc, но я предполагаю, что он может находиться в другом месте.

В приведенном выше примере файл ipsec.conf выглядит так:

 версия 2.0

# базовая конфигурация
настройка конфигурации
        nat_traversal = да
        oe = выкл
        protostack = netkey
        force_keepalive = да
        keep_alive = 60
        # nhelpers = 0

# Добавьте сюда подключения
соединение mikrotik-to-linux
        authby = секрет
        auto = start
        тип = туннель
        слева = 22.22.22.22
        leftid = 22.22.22.22
        leftsourceip = 172.30.0.1
        leftsubnet = 172.30.0.0 / 24
        справа = 11.11.11.11
        rightubnet = 192.168.0.0 / 24
        правый = 11.11.11.11
        pfs = нет
        forceencaps = да
        ike = aes256-sha1; modp1024
        phase2 = esp
        phase2alg = aes256-sha1

Вам необходимо связать ключевое слово «left» с «local», а «right» — с «remote», и вам будет легче читать конфигурацию выше.

Также в папке / etc у меня есть еще один файл с именем ipsec.секреты, у которых есть общий секретный ключ:

 22.22.22.22 11.11.11.11: PSK "my_preshared_key"

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

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

Связанные

Mikrotik Linux GRE / IPSec, strongswan · GitHub

Mikrotik <-> Linux GRE / IPSec, strongswan · GitHub

Мгновенно делитесь кодом, заметками и фрагментами.

Mikrotik <-> Linux GRE / IPSec, strongswan

Настройка конфигурации
	charondebug = «ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2»

	конн% по умолчанию
	# keyexchange = ikev2

	конн микротик-1
	# Попробуйте подключиться при запуске демона
	авто = начало

	# Аутентификация по PSK (см. Ipsec.секрет)
	authby = секрет

	# Отключить сжатие
	компресс = нет

	# Настройки повторного набора
	closeaction = clear
	dpddelay = 30 с
	dpdtimeout = 150 с
	dpdaction = перезапуск

	# Настройки аутентификации ESP (этап 2)
	esp = aes128-sha1-modp2048, aes256-sha1-modp2048

	# UDP перенаправляет
	forceencaps = нет

	# Настройки аутентификации IKE и связки ключей (фаза 1)
	ike = aes128-sha1-modp2048, aes256-sha1-modp2048
	ikelifetime = 86400 с
	попыток ввода =% навсегда
	время жизни = 3600 с

	# Internet Key Exchange (IKE) версия
	# По умолчанию: Харон — ikev2, Плутон: ikev1
	keyexchange = ikev1

	# тип соединения
	тип = транспорт

	# Peers
	слева = remote_ip
	справа = local_ip

	# Тип протокола.Может не работать в числовом формате, тогда необходимо установить gre
	leftprotoport = 47
	правый порт = 47

Вы не можете выполнить это действие в настоящее время.

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

IPSec Tunnel: Mikrotik — pfSense

Введение

Недавно я начал работать с устройством на базе ОС Mikrotik router для использования в малом бизнесе.Я подумал, что это идеальное время, чтобы опробовать некоторые кроссплатформенные конфигурации между Mikrotik и pfSense, которые очень популярны в среде любителей и малого бизнеса.

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

Туннель, показанный в этой конфигурации, является только туннелем IPv4, но трафик IPv6 можно добавить с небольшими изменениями. Аутентификация Mutal PSK используется для упрощения настройки.

Эта конфигурация не проверялась на предмет максимальной безопасности и не тестировалась на производительность.

Требования

Эта конфигурация основана на следующих системах:

pfSense версия 2.4.4
Mikrotik версия 6.46.6

Системы должны иметь возможность связываться друг с другом через интерфейс WAN и иметь уникальные диапазоны IP-адресов LAN.Вам также необходимо будет добавить правило в pfSense для принятия соединения ISAKMP через порт 500. Для большей безопасности вы можете создать это правило, чтобы разрешить только одноранговый IP / хост.

Настройка фазы 1 — pfSense

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

Перейдите к VPN -> IPSec -> Tunnel . Затем нажмите кнопку Добавить P1 , чтобы начать добавление новой записи фазы 1.Затем начните заполнять Общая информация , как показано.

Версия обмена ключами: IKEv2
Интернет-протокол: IPv4
Интерфейс: WAN (или другой, если применимо)
Удаленный шлюз: IP или имя хоста маршрутизатора Mikrotik (я использовал имя хоста)

Затем введите следующее для предложения Phase 1 (аутентификация)

Метод аутентификации: Mutual PSK
Мой идентификатор: Мой IP-адрес
Идентификатор узла: Одноранговый IP-адрес
Pre-Shared Key: Нажмите кнопку Generate new Pre-Shared Key , чтобы создать ключ для этого туннеля

Затем создайте / обновите предложение Phase 1 (алгоритм шифрования) .Вы должны быть в состоянии обойтись единственной правильной записью здесь.

Алгоритм: AES
Длина ключа: 128 бит (я уверен, что вы можете увеличить в соответствии с вашими требованиями)
Хеш: SHA256
Группа DH: 14 (2048 бит)

Последний этап фазы 1 — просмотреть дополнительные параметры. Значения по умолчанию должны быть в порядке. Затем нажмите Сохранить .

Настройка фазы 1 — Mikrotik

Конфигурация маршрутизатора Mikrotik отображается через веб-интерфейс, работающий на 80-м порту устройства.Войдите в свой маршрутизатор и перейдите по адресу IP -> IPSec . Необходимо будет создать или изменить несколько конфигураций.

Во-первых, мы можем настроить однорангового узла, перейдя по адресу IP -> IPSec -> Peers и нажав Добавить новый . Затем введите:

Имя: это может быть имя хоста или другое имя, которое вы хотите использовать
Адрес: это может быть IP-адрес или имя хоста
Порт и локальный адрес можно оставить по умолчанию
Профиль можно оставить по умолчанию
Exchange mode: IKE2
Passive: Disabled
Send INITIAL_CONTACT: Enabled

Затем нам нужно обновить профиль по умолчанию, чтобы он соответствовал нашим настройкам pfSense.Перейдите к IP -> IPSec -> Профили и нажмите по умолчанию и измените настройки следующим образом. Когда вы закончите, нажмите ОК . Не упомянутые настройки могут оставаться по умолчанию.

Алгоритмы хеширования: SHA256
Алгоритм шифрования: aes-128
Группа DH: modp2048

Наконец, перейдите к IP -> IPSec -> Identities и нажмите Добавить новый , чтобы создать личность для этого туннеля.

Включено: Проверено
Одноранговый узел: Одноранговый узел, созданный вами ранее
Auth. Метод: предварительный общий ключ
Секрет: ключ, сгенерированный в pfSense
Тип моего идентификатора: авто
Тип удаленного идентификатора: авто
Сопоставление по: удаленному идентификатору

Проверка фазы 1

Этап проверки 1 покажет нам, что устройства подключены друг к другу, и никакие правила брандмауэра не блокируют установление сеанса.

В pfSense перейдите в Status -> IPSec и найдите сеанс IPSec Установлен .

В Mikrotik вы можете проверить сессию фазы 1 под IP -> IPSec -> Active Peers . Вы должны увидеть увеличение времени безотказной работы настроенного сеанса.

Настройка фазы 2 — pfSense

На этапе 2 мы сообщаем межсетевому экрану, как определять, какие пакеты нужно зашифровать и отправить удаленному узлу. Он также содержит конфигурацию алгоритмов шифрования для использования при передаче. Чтобы начать добавлять запись фазы 2, перейдите в VPN -> IPSec -> Tunnels .Найдите запись фазы 1, которую вы только что создали, и щелкните + Показать записи фазы 2 . Пока не должно быть. Затем нажмите кнопку Добавить P2 .

Заполните общую информацию следующим образом:

Режим: туннельный IPv4
Локальная сеть: Подсеть LAN (наиболее вероятно)
Удаленная сеть: заполните подсеть LAN за Mikrotik, к которой вы хотите подключиться через pfSense

Затем заполните предложение фазы 2 (SA / Обмен ключами) следующим образом:

Протокол: ESP
Алгоритмы шифрования
- AES128-GCM — 128 бит
- AES192-GCM — Авто
- AES256-GCM — Авто
Алгоритмы хеширования
Группа ключей

Когда вы закончите, нажмите Сохранить .

Настройка фазы 2 — Mikrotik

Сначала нам нужно настроить предложение Mikrotik Phase 2, чтобы оно соответствовало pfSense. Перейдите к IP -> IPSec -> Proposals и щелкните по предложению по умолчанию, чтобы отредактировать его.

Алгоритмы аутентификации:
Encr. Алгоритмы
- aes-192 ctr
- aes-128 gcm
- aes-256 gcm
Группа PFS: modp2048

Последним шагом на этапе 2 на Mikrotik является создание политики.Перейдите к IP -> IPSec -> Политики и нажмите Добавить новый . Заполните настройки следующим образом:

Включено: Проверено
Одноранговое соединение: Созданный вами одноранговый узел
Туннель: Проверено (Если вы не установите этот флажок, вы можете потерять удаленное управление, будьте осторожны)
Src Address: Подсеть и маска локальной подсети для туннеля
Dst. Адрес: подсеть и маска удаленной подсети для туннеля
Протокол: 255 (все)
Действие: зашифровать
Уровень: требуется
Протоколы IPSec: esp
Предложение: по умолчанию

Тестирование конфигурации

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

Для тестирования с Mikrotik перейдите в Tools -> Ping и настройте ping для шлюза LAN в системе pfSense. В моем случае LAN на дальнем конце — 192.168.1.1. Я смог протестировать это, используя интерфейс моста Mikrotik в качестве исходного интерфейса.

Для тестирования с помощью pfSense это та же идея, перейдите на Диагностика -> Ping и используйте LAN в качестве адреса источника.

Статистика доступна на обеих платформах. В pfSense перейдите в Status -> IPSec , в Mikrotik посмотрите в разделе IP -> IPSec -> Active Peers .

Заключение

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

Связанные

Настройка выделенного VPN-устройства Mikrotik L2TP IPsec

Руководство Mikrotik L2TP IPSec VPN — От начала до конца Устройство

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

Первые шаги

Обновление операционной системы маршрутизатора

Система> Пакеты> Проверить наличие обновлений> Текущее> Загрузить и установить

Отключить звуковые сигналы при загрузке

Система> Маршрутизатор> Настройки> Тихая книга: отмечено> ОК

После перезагрузки обновите прошивку маршрутизатора

Система> Маршрутизатор> Обновление
Система> Перезагрузка> ОК

Теперь сбросьте настройки маршрутизатора до значений по умолчанию

Система> Сброс конфигурации> ОК

Отключить DHCP-сервер

IP> DHCP-сервер> Выбрать> X (Отключить)

Установить личность

Система> Идентификация> COMPANY-VPN

Добавьте статический IP-адрес к мосту.

IP> Адреса> + (Добавить)> IP / маска подсети (например, 192.168.100.1/24)

Добавить ETh3 к мосту

Мост> порт> + (Добавить)> ether2-master> мост

Создайте два правила NAT (если они еще не установлены), NAT для доступа в Интернет из локальной сети и NAT для доступа к локальной сети от клиентов VPN.

IP> Межсетевой экран> NAT> + (Добавить)> Цепочка: srcnat> Выходной интерфейс: Ether1 (порт WAN)> Действие: Masquerade
IP> Межсетевой экран> NAT> + (Добавить)> Цепочка: srcnat> Out.Интерфейс: мост (LAN-мост)> Действие: Masquerade

Отключить неиспользуемые службы

По умолчанию Mikrotik поставляется со всеми включенными сервисами

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

IP> Службы> Отключить все, кроме Winbox (TCP 8291)
IP> Брандмауэр> Сервисные порты> Отключить ВСЕ
Инструменты> RoMon> Отключено
IP> Настройки> RP-Filter = strict (предотвращает подмену IP)

Настроить пароль

Измените пароль Mikrotik для администрирования устройства

Система> Пароль> Выбрать новый пароль

Отключить обнаружение Winbox при фильтрации WAN / обратного пути

IP> Соседи> Интерфейсы обнаружения> Ether1: отключено

Подсеть VPN

Если вам нужно подключить, скажем, 10+ человек через VPN, возможно, вы не захотите использовать IP-адреса в стандартном диапазоне LAN, поглощая IP-адреса с вашего DHCP-сервера, и в этом случае вам следует создать отдельную подсеть для пользователей VPN, который может связываться с внутренней локальной сетью.

Для этого нужно изменить четыре вещи:

Создайте мост — его не нужно связывать с каким-либо интерфейсом по портам.
1. Мост> + (Добавить)> Имя: vpn-bridge.
Назначьте IP-адрес VPN-мосту.
1. IP> Адреса> + (Добавить)> 192.168.200.1/24
Создайте правило NAT, если оно еще не установлено — это позволяет клиентам VPN взаимодействовать с сетью.
1. IP> Межсетевой экран> NAT> + (Добавить)> Out-Interface: bridge-vpn> Action: Masquerade.
Включение DHCP-сервера на мосту VPN
1. IP> DHCP-сервер> Отредактируйте запись DHCP> Интерфейс: vpn-bridge.
2. IP> DHCP-сервер> Сети
  1. Сеть: 192.168.200.0/24 — Ваш VPN-мост LAN
  2. Шлюз: 192.168.200.1 — IP-адрес вашего VPN-моста в локальной сети
  3. DNS-серверы: IP-адрес контроллера домена / DNS-сервера + 192.168.200.1 (VPN-мост)
  4. Домен: ваше полное доменное имя (company.local и т. Д.).
  5. IP> Пул> Настройте диапазон IP-адресов в соответствии с DHCP-сервером.
    1. Например, 192.168.200.100-192.168.200.200

Создание учетных записей пользователей

PPP> Секреты> + (Добавить)
- Имя: имя пользователя
- Пароль: пароль
- Сервис: любой
- Профиль: по умолчанию

Политика VPN

PPP> Профили> Изменить «по умолчанию»
- Общие
  - Местный адрес: IP Mikrotik
  - Удаленный адрес: default-dhcp (IP-пул)
  - Мост: vpn-bridge
  - DNS-серверы: IP-адреса DNS-серверов в здании, обычно это контроллер домена.
- Limits — Rate-Limit — Необязательно — если вы хотите ограничить скорость для каждого клиента.
  - XXM / YYM, где XX — загрузка, а YY — загрузка в Мбит / с. (10 м / 5 м)

L2TP VPN Минимальные правила межсетевого экрана без правил

IP> Брандмауэр> Удалить все возможные правила.

Вставьте все правила ниже в новый терминал

Правила VPN

/ ip firewall filter add chain = input action = accept comment = ”VPN L2TP UDP” in-interface = ether1 protocol = udp dst-port = 500,1701,4500
/ ip firewall filter add chain = input action = accept comment = «VPN L2TP ESP» протокол = ipsec-esp
/ ip firewall filter add chain = input action = accept comment = «VPN L2TP AH» протокол = ipsec-ah

Правила безопасности общедоступного маршрутизатора

/ ip firewall filter add action = drop chain = input comment = «Отбросить узлы из черного списка в маршрутизатор» in-interface = ether1 src-address-list = BlackList
/ ip firewall filter add action = drop chain = forward comment = «Удалить узлы из черного списка через маршрутизатор» in-interface = ether1 src-address-list = BlackList
/ ip firewall filter add chain = input comment = «Accept Established / Related Input» состояние соединения = установлено, связано
/ ip firewall filter add chain = forward comment = «Accept Established / Related Forward» состояние соединения = установлено, связано
/ ip firewall filter add action = add-src-to-address-list address-list = BlackList address-list-timeout = 1d chain = input comment = «Обнаружить сканеры портов» dst-port = 21-23,53,88,135 -139,389,445,1433,3306,3389,5900,6667 in-interface = протокол ether1 = tcp
/ ip firewall filter add action = add-src-to-address-list address-list = BlackList address-list-timeout = 1d chain = input comment = «Обнаруживать запросы UDP WAN DNS для предотвращения DDoS» dst-port = 53 in -interface = протокол ether1 = udp
/ ip firewall filter add action = accept chain = input comment = «Accept ICMP / Ping» protocol = icmp
/ ip firewall filter add action = drop chain = input comment = «Drop Input» in-interface = ether1

Включение сервера L2TP

IP> IPsec> Одноранговые узлы
- Новый (+)
  - Адрес: 0.0.0.0 / 0 (для разрешения попытки подключения любого IP-адреса в Интернете)
  - Метод аутентификации: предварительный общий ключ
  - Режим обмена: основной l2tp
  - Секрет: «SharedSecret» (должен соответствовать PSK из PPP> L2TP-сервер)
- Вкладка «Дополнительно»
  - Группа шаблонов политики: по умолчанию
  - Отправить начальный контакт: включен
  - Обход NAT: включен
  - Тип моего удостоверения личности: авто
  - Создать политику: строгий порт
  - Проверка предложения: подчиняться
- Вкладка шифрования
  - Алгоритм хеширования: sha1, sha256
  - Алгоритм шифрования: Проверить: aes-128, aes-192, aes-256
  - Группа DH: Проверить: modp1024
IP> IPsec> Предложения: по умолчанию
- - Алгоритмы аутентификации: sha1, sha256
  - Алгоритмы Encr: aes-128 cbc, aes-192 cbc, aes-256 cbc
  - Группа PFS: modp1024

Разрешить VPN для локальной маршрутизации

Интерфейс> ether2 (порт LAN)> ARP> Изменить с «Включено» на «Proxy-Arp»

PPP> Интерфейс> Сервер L2TP
- Включено: Да
- Использовать IPsec: Да
- Профиль по умолчанию: изменить с «Шифрование по умолчанию» на «По умолчанию»
- Аутентификация: ТОЛЬКО MSCHAP2
- Секрет IPsec: «SharedSecret» (соответствует тому, что было в одноранговом узле IPsec)

Теперь вы можете подключиться из клиента Windows или Mac.

Примечание о поиске в DNS

Если вы попытаетесь выполнить широковещательную рассылку NETBIOS, например: «ping server01», время ожидания истечет.

Широковещательная передача

NETBIOS не работает через VPN, но работает с полными доменными именами.

Например, server01 не разрешится.

Server01.domain.local разрешит

Если вам нужно подключиться к внутреннему терминальному серверу, но вы не хотите использовать IP-адрес в качестве имени хоста, вы должны создать запись A на внутреннем DNS-сервере для сопоставления, это также поможет внутренним клиентам разрешать проблемы напрямую.Например. remote.company.com на своем DNS-сервере.

Новая кнопка терминала, копирование / вставка

# Настройте перезагрузку устройства каждый месяц в 4 утра, не повредит 🙂

/ системный планировщик добавить интервал = 30d name = «Перезагрузить маршрутизатор ежемесячно» on-event = «/ system reboot» start-date = jan / 01/1970 start-time = 4: 00: 00

# Установить часовой пояс

/ установка системных часов time-zone-name = America / Los_Angeles

# Установить серверы времени

/ system ntp client set enabled = yes primary-ntp = 216.239.35.0 вторичный-ntp = 216.239.35.4 server-dns-names = time1.google.com, time2.google.com

Несколько клиентов — проблема с IP-адресом одного источника

Это проблема ЛЮБОГО устройства L2TP VPN, а не только устройства Mikrotik. Протокол L2TP всегда инициировал соединения на одном и том же порте UDP1701. Внутри заголовка переносится идентификатор, обычно включающий исходный IP-адрес подключающегося клиента. Если у вас подключен один компьютер, никаких проблем. Если у вас есть второй компьютер в той же сети (например,грамм. два ноутбука в отеле, пытающиеся подключиться к VPN), самое последнее соединение запустит предыдущее, предварительно установленное соединение.

В качестве примечания, в протоколе L2TP VPN есть необязательный параметр, который с помощью параметра «Строгий порт» позволяет клиентам выбирать другой порт UDP после установления соединения, вместо того, чтобы быть жестко запрограммированным на UDP1701. На практике он работает на Mac / Linux и не работает на клиентах Windows. У меня было 5 устройств OSX, подключенных с одного и того же исходного IP без проблем.У меня было 1x Windows и 5x OSX-устройств, которые подключались без проблем. В тот момент, когда у вас будет вторая попытка подключения L2TP-клиента Windows, предыдущее подключение будет разорвано.

Что делать, если у вас много клиентов Windows, использующих один и тот же исходный IP-адрес? — используйте разные исходные IP-адреса (точка доступа сотового телефона) или настройте VPN-сервер IKEv2, а не L2TP-сервер VPN. В настоящее время я пишу подробное руководство по IKEv2 Mikrotik VPN.

Система> Регистрация
- Новый (+)
- Создайте три темы: l2tp, ppp и ipsec
- Действие: Память
- Отсюда вы сможете просмотреть журналы в разделе «Журнал» и погуглить свое решение, где что-то может нуждаться в корректировке.

Для Windows 10, убедитесь, что вы ввели предварительный ключ дважды — один раз при создании VPN-соединения, а затем при редактировании соединения после того, как Windows установила его — он не сохраняется автоматически.

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

Ошибка Mikrotik из-за того, что клиент не сохранил предварительный общий ключ. Журнал: «нет конфигурации однорангового узла», или «не удалось получить действительное предложение», или «не удалось выполнить предварительную обработку ph2»

Убедитесь, что вы настроили режим «туннелировать все» в дополнительных настройках в Системных настройках> Сеть при добавлении соединения L2TP IPSec.Без туннеля all вы сможете пинговать только шлюз (192.168.200.1), а не другие устройства в сети.

WireGuard — VPN для реального использования

В моем последнем посте я написал о своем пути замены домашнего маршрутизатора на Raspberry Pi 4. Одна из причин заключалась в том, чтобы увеличить пропускную способность моего VPN, и я рассматривал WireGuard с тех пор, как я впервые услышал, что самому Линусу Торвальдсу он очень понравился.

Могу я еще раз заявить о своей любви к нему и надеяться, что он скоро будет объединен? Может быть, код не идеален, но я бегло просмотрел его, и по сравнению с ужасами OpenVPN и IPSec, это произведение искусства.- Линус Торвальдс

Однако я не знал, как работает WireGuard, насколько сложно его настроить и подходит ли он мне. У меня этот проект был в моем списке TODO как минимум полгода; Изначально я планировал использовать другое оборудование, так как RPi 4 даже не был анонсирован. Положительным моментом нынешнего кризиса COVID-19 является то, что он снизил мою рабочую нагрузку, и я могу посвятить некоторое время побочным проектам и экспериментам. Поскольку WireGuard казался многообещающим для использования в других проектах, я решил разобраться во внутреннем устройстве, прочитав его статью.

Линус ужасно рассказывает о таких решениях, как OpenVPN и IPSec, и я не могу с этим согласиться. Раньше я использовал обе VPN. Что касается IPsec, я даже читал некоторые RFC. В Alcatel-Lucent я работал над функцией под названием ePDG, которая позволяет операторам сотовой связи передавать данные с вашего мобильного телефона на мобильный шлюз в центре обработки данных через Интернет; может быть, вы слышали о передаче голоса по Wi-Fi. В этой технологии IPsec защищает туннель между вашим телефоном и вашим оператором связи.

Прежде чем я объясню, как работает WireGuard, и расскажу, что мне в нем нравится, давайте сначала проанализируем существующие решения.

IPsec

IPsec является стандартом де-факто в отрасли. После того, как вы настроите туннель, производительность будет довольно хорошей. Конструкция и строительные блоки IPsec полностью открыты, и их можно свободно читать с помощью набора RFC. Написанный в основном академическими кругами, он имеет идеальное разделение уровней — например, обмен ключами (IKEv2) отделен от защищенной передачи данных (ESP). Как недостаток, установка всех этих блоков по своей сути сложна. В Linux такие решения, как strongSwan, немного упрощают задачу, но я бы не сказал, что это просто.

Примечание (18.10.2020): В приведенном ниже обсуждении некоторые читатели упомянули, что я не полностью понимаю протокол IKE или IPsec. Я считаю, что достаточно хорошо понимаю основы протокола. Тем не менее, я не занимался профессиональной деятельностью в сетевой индустрии несколько лет. Я допускаю, что некоторые из вещей, которые я здесь упоминаю, могут быть устаревшими или неправильными. Однако я по-прежнему настаиваю на том, что IPsec — слишком сложный протокол. Спасибо читателям за исправления.

Что мне нравится в IPsec, так это то, что полезная нагрузка ESP может быть упакована непосредственно после IP-части пакета.Это связано с тем, что ESP зарегистрирован как один из разрешенных протоколов, которые вы можете установить в поле «Следующий заголовок» IP-заголовка. Если вы настроите VPN таким образом, вы снизите накладные расходы. Однако в сегодняшнем мире с NAT данные IPsec в основном инкапсулируются внутри полезной нагрузки UDP.

IPsec может работать в двух режимах — «сайт-сайт», когда вы соединяете две локальные сети, или в режиме RoadWarrior, который используется, когда вы хотите подключиться к вашему устройству в корпоративной сети. RoadWarrior не позволяет (насколько я могу судить) соединять локальные сети; Думаю, такого сценария никто не предполагал.Таким образом, вы вынуждены использовать чистый режим site-to-site, который имеет много недостатков.

Межсайтовый IPsec Плюсы и минусы

✔️ Достойная производительность VPN
✔️ Меньше накладных расходов на пакеты в чистом режиме ESP
❌ Трудно настроить
❌ Конфигурация статична на обоих концах, с жестко заданными IP-адресами, межсетевым экраном правила, маршруты и другие настройки
❌ Оба конца туннеля требуют общедоступного статического IP-адреса
Для обоих концов требуются исключения брандмауэра для определенных протоколов и номеров портов
❌ IPsec не позволяет изменять определенные порты; они «зашиты» внутри стандарта RFC
❌ Трудно отладить

В моем случае у меня не было статических IP-адресов, но, по крайней мере, они были общедоступными.Один конец туннеля находился в Братиславе, другой конец был через всю страну в Хминянах, и я использовал маршрутизаторы Mikrotik на обоих концах. Смена динамического IP была проблемой. Если вы используете VPN, например OpenVPN, вы можете указать доменное имя вместо IP-адреса вашего однорангового узла. Таким образом, вы можете использовать динамические службы DNS, которые сразу же интегрированы во многие потребительские маршрутизаторы. Однако IPsec не ожидает такого сценария, и вам нужно все настроить. Я закончил тем, что написал немного сложный скрипт, который обновлял конфигурации интерфейса, правила брандмауэра и многие другие причуды.Вы все еще можете найти его в моем репозитории на GitHub. Эта установка работала, и производительность была в порядке. Но однажды я сменил провайдера, у меня больше не было общедоступного IP-адреса, и мне пришлось искать другое решение, которое могло бы снова соединить два конца. Я остановился на OpenVPN, который также поддерживался в Mikrotik RouterOS.

Обновление 23.08.2020: Mikrotik выпустила новую бета-версию Router OS. Среди новых функций — поддержка WireGuard. Это не займет много времени, и вы сможете использовать WireGuard в стабильных версиях системы.Настройка VPN с помощью инструмента WinBox должна быть еще более простой.

OpenVPN

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

Плюсы и минусы

✔️ Он может объединять две локальные сети, даже если у одного клиента есть частный IP-адрес
✔️ Поддерживает транспорт по TCP и UDP
✔️ Клиент может получить доступ к серверу через запись домена DNS
✔️ Сервер может необязательно объявлять другие маршруты, такие как его сеть LAN
✔ client Клиент может иметь статический IP-адрес внутри OpenVPN.Полезно, когда вы хотите создать статический маршрут к локальной сети клиента
❌ Сложно настроить; однако проще, чем IPsec
❌ Клиент не может объявлять свои маршруты. Серверу необходимо создать статический маршрут вне конфигурации OpenVPN
❌ Трудно отладить
❌ Плохая производительность, пропускная способность намного ниже, чем на IPsec
❌ Уязвимости в системе безопасности и кодовая база, которую трудно проверить исследователями

Mikrotik использует специальную реализацию OpenVPN, которая работает только через TCP.Люди годами безуспешно просят поддержки UDP. OpenVPN через TCP менее эффективен, поскольку протокол TCP всегда запрашивает подтверждение того, что пакет прибыл. Вдобавок к этому OpenVPN поддерживает сеанс. Со временем, когда я перешел с RouterOS на OpenWrt, переключение этого VPN на использование UDP было одним из первых пунктов в моем списке.

Хотя OpenVPN лучше работает по UDP, его производительность все равно остается слабой. Одна из основных причин заключается в том, что в Linux он реализован как клиент пользовательского пространства. Когда OpenVPN генерирует пакет, он копируется несколько раз, пока не покинет аппаратный интерфейс NIC.Кроме того, OpenVPN не работает эффективно с многоядерными процессорами.

Настроить OpenVPN проще, чем настроить IPsec. Однако это все еще довольно сложно. Людям необходимо знать, как генерировать ключи OpenSSL, желательно с помощью сценариев easy-rsa, поставляемых с OpenVPN. Безопасность OpenVPN также вызывает беспокойство. В прошлом исследователи обнаружили множество уязвимостей внутри библиотеки OpenSSL, а также в основной библиотеке OpenVPN. Кодовая база обширна, что затрудняет аудит и поиск ошибок.

WireGuard

Здесь я должен упомянуть, что IPsec и OpenVPN — довольно старые протоколы. Со временем люди находили подводные камни в своих проектах, но исправить основные недостатки дизайна непросто, а иногда и невозможно. Авторы WireGuard были хорошо осведомлены о проблемах IPsec и OpenVPN, обнаруживаемых в реальных сценариях, и написали протокол для их решения.

WireGuard® — это чрезвычайно простой, но быстрый и современный VPN, в котором используется самая современная криптография.Он нацелен на то, чтобы быть быстрее, проще, компактнее и полезнее, чем IPsec, избегая при этом огромной головной боли. Он намерен быть значительно более производительным, чем OpenVPN.
— Веб-страница WireGuard

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

Плюсы и минусы

✔️ Кодовая база проста; драйвер ядра имеет, по словам его авторов, менее 4000 строк кода
✔️ Благодаря своей простоте он легко поддается проверке на наличие уязвимостей безопасности
✔️ Простота настройки и использования
✔️ Поддерживает роуминг клиентов без потери возможности подключения к VPN
✔️ Использует современную криптографию
✔️ Хорошо работает на мощных серверах и встроенных маршрутизаторах
✔️ Очень высокая производительность, сравнимая с IPsec
✔️ Поддерживает контейнеры Linux, чтобы предоставить им доступ к VPN только через пространство имен Wireguard
✔️ Доступно на многих платформах, включая Android и iOS.WireGuard активно переносится на старые ядра Linux, чтобы расширить поддержку еще больше
❌ Драйвер ядра пока доступен только для Linux. На других платформах используется клиент пользовательского пространства, написанный на Go. Однако, по словам авторов, он по-прежнему достаточно эффективен.

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

✔️ Драйвер ядра Linux не использует Crypto API. Вместо этого WireGuard повторно реализует некоторые функции напрямую, чтобы избежать выделения динамической памяти.
✔️ WireGuard поддерживает конфигурации с чистой статически выделенной памятью
✔️ Криптографические ключи легко генерируются с помощью прилагаемого инструмента wg
✔️ Неявный скрытый режим.По умолчанию одноранговые узлы WireGuard отправляют пакеты только при необходимости, а служба WireGuard не отвечает на случайные запросы без правильно заполненных заголовков. Поэтому, если случайный сетевой сканер отправляет запрос на порт, который прослушивает WireGuard, он не получает ответа и не знает, что там работает VPN. Клиенты за NAT могут поддерживать VPN в установленном состоянии, используя необязательный параметр keepalive; по умолчанию это без поддержки активности
✔️ Поскольку WireGuard в Linux работает внутри ядра, а не в пользовательском пространстве, внутренние пакеты не копируются несколько раз, пока они не выйдут из аппаратной сетевой карты
✔️ В отличие от OpenVPN, WireGuard эффективно использует все ядра процессора
✔️ Уровень обмена ключами и транспортный уровень не разделены (в отличие от IPsec), чтобы упростить реализацию и ремонтопригодность для сетевых инженеров
✔️ В Linux авторы WireGuard частично интегрировали его конфигурацию в стандартные инструменты Linux, такие как ip .Для остальной функциональности они предоставляют утилиту wg , и со временем они планируют интегрировать всю эту функциональность в стандартные инструменты и полностью избавиться от этого инструмента wg

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

Все являются одноранговыми узлами

В WireGuard нет отношений клиент-сервер.WireGuard вводит понятие одноранговых узлов, которые являются взаимосвязанными клиентами, и по определению не существует вышестоящих или подчиненных одноранговых узлов.

Для установления соединения необходимо обеспечить следующее:

На каждом узле создайте интерфейс WireGuard и назначьте ему IP-адрес с помощью инструмента ip . Это адрес внутри сети VPN, навсегда привязанный к одноранговому узлу
На каждом одноранговом узле сгенерируйте закрытый ключ с помощью инструмента wg и назначьте его интерфейсу WireGuard
Получите открытый ключ, снова с помощью инструмента wg , и добавьте его ко всем другим сверстникам, с которыми вы хотите общаться.WireGuard не указывает, как обмениваться ключами. Я открыл сеанс SSH на каждом устройстве и скопировал их вручную.
При желании я могу сообщить каждому одноранговому узлу, как связаться с другими одноранговыми узлами, указав общедоступный IP-адрес (или домен) и порт. Не всем коллегам нужно знать, как связаться с другими, если другие знают, как с ними связаться; вы увидите позже.

Создание однорангового ключа

Создание пар открытого / закрытого ключей выполняется просто. Убедитесь, что у вас установлены инструменты WireGuard. Процедура зависит от вашей системы.Сначала вы создаете закрытый ключ:

Копировать

2CKqTfzJBQgg4Vefi38IpBkzPUYUdJdneyZCf4bkBsm0 =

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

Копировать

2pKIHvamNAEpnh21czVMDDv / GD0ivVwp8Jwhp0qUH7UU =

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

Давайте рассмотрим несколько сценариев, и, надеюсь, вы лучше поймете, как это работает.

Сценарий № 1: VPN типа «сеть-сеть», в которой оба одноранговых узла имеют общедоступный IP-адрес.

В этом первом сценарии мы соединяем два маршрутизатора между собой.

Peer A:

Сеть LAN: 10.0.0.0/24
IP VPN: 192.168.1.1/32
Public: IP 46.43.215.66 (или домен peerone.example.org)
Порт WireGuard: 1194 ( используйте любой порт, который вам нужен, если он не заблокирован вашим интернет-провайдером)

Peer B:

Сеть LAN: 10.0.1.0 / 24
VPN IP: 192.168.1.2/32
Public IP: 12.35.181.48 (или домен peertwo.example.org)
Порт WireGuard: 1194

Сценарий № 1: VPN

типа «сеть-сеть» Сначала создайте интерфейс WireGuard на каждом одноранговом узле:

Узел A:

Узел B:

Затем назначьте IP-адрес интерфейсу. Он служит одноранговым IP-адресом внутри вашей VPN и никогда не меняется (если, конечно, вы этого не сделаете).

Peer A:

Peer B:

Затем сгенерируйте ключи, как описано выше, и назначьте их одноранговым узлам.

Peer А:

Копировать

1peer

2peer A

3iFtTfEwI / + Bc0M2olXuytEVPU4TXhCDVGezFt7H8ylg =

4peer

5AqyBazhsen / jzTJ0MzyyU16wOYovBPZ + DIu6x4rSh4Y =

8peer

Peer Б:

Копировать

1peer Б

2peer Б

3uPBLlBHptZahFKaX9mSFmIgSNjAEd1kwB + MSAE + QVE0 =

4peer Б

5i8nniZCkTISUfaLMQ + FV0Sewvq0f68UrkLkeV0a4BnA =

8peer Б

и включить интерфейс на обоих wg0 91 192 peers:

Peer A:

Peer B:

На этом этапе интерфейс WireGuard настроен, но одноранговые узлы не знают друг друга.Давай исправим это.

Peer A:

Peer B:

Теперь VPN настроена, и одноранговые узлы должны иметь возможность связываться друг с другом.

Параметр peer - это открытый ключ однорангового узла, с которого вы хотите установить связь.

Параметр allowed-ips перечисляет все сети, которые предоставляет другой одноранговый узел. В нашем примере он перечисляет IP-адрес, назначенный интерфейсу WireGuard, и IP-адрес локальной сети, подключенной к одноранговому узлу. У вас есть полный контроль над тем, какие сети вы уведомляете другим, но, как минимум, вы должны указать там IP-адрес однорангового узла.

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

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

Открытый ключ однорангового узла	Разрешенные исходные IP-адреса
i8nniZCkTISUfaLMQ + FV0Sa10rvq0f2168.1.2 / 32,10.0.1.0 / 24

Эта таблица сопоставляет открытый ключ однорангового узла с соответствующими IP-адресами. Представьте, что одноранговый узел A хочет отправить пакет устройству за локальной сетью однорангового узла B (IP: 10.0.1.10). WireGuard просматривает эту таблицу и находит соответствующий открытый ключ (т. Е. Маршрут существует). Затем WireGuard шифрует пакет открытым ключом, связанным с целевым IP-адресом, и отправляет пакет конечной точке однорангового узла B. На другой стороне VPN одноранговый узел B получает пакет через порт 1194 WireGuard.Затем он пытается расшифровать пакет с помощью соответствующего закрытого ключа. Если одноранговый узел B успешен, он обрабатывает пакет. В противном случае WireGuard отбрасывает пакет.

Открытый ключ однорангового узла Разрешенные исходные IP-адреса

AqyBazhsen / jzTJ0MzyyU16wOYovBPZ + DIu6x4rSh4Y =

192.168.1.1/32 9013.0.0/

192.168.1.1/32 9010.0.0/ 1.0 хочет отправить ответ одноранговому узлу A, он помещает IP однорангового узла A в качестве адреса назначения.Затем партнер B просматривает таблицу, чтобы найти соответствующий открытый ключ для адреса назначения. В случае успеха он шифрует пакет соответствующим открытым ключом однорангового узла A и отправляет пакет, который обрабатывается на одноранговом экземпляре WireGuard.

Сценарий № 2: Два одноранговых узла за NAT и один одноранговый узел с общедоступным IP-адресом

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

Одноранговый узел A:

Сеть LAN: 10.0.0.0/24
IP-адрес VPN: 192.168.1.1/32
За NAT (без общедоступного IP-адреса)

Узел B:

Сеть LAN: 10.0.1.0 / 24
IP-адрес VPN: 192.168.1.2/32
За NAT (без общедоступного IP-адреса)

Одноранговый узел C:

Сеть LAN: 10.0.2.0/24
IP-адрес VPN: 192.168.1.3/32
Общедоступный IP: 12.35.181.48
Порт WireGuard: 1194

Сценарий № 2: VPN типа «сеть-сеть» с одноранговыми узлами за NAT

В этом примере одноранговые узлы A и B находятся за NAT.У них нет возможности общаться напрямую. Однако они могут отправлять трафик через одноранговый узел C, который доступен для них обоих. У нас все еще есть партнеры, которые «равны» в терминологии WireGuard; однако, установив конфигурацию для отправки данных от однорангового узла A к одноранговому узлу B через одноранговый узел C (и наоборот), мы фактически создали архитектуру клиент-сервер. Одноранговые узлы A и B являются клиентами, и весь их трафик проходит через одноранговый узел C. Оба клиента A и B определили конечную точку для однорангового узла C. Я не буду помещать здесь полную конфигурацию, поскольку я подробно объяснил это в первом сценарии.Но позвольте мне показать хотя бы конфигурацию для однорангового узла A.

Копировать

2peer A

3peer A

6peer A

7peer A

8iFtTfEwI / + Bc4gt0M2000

10AqyBazhsen / jzTJ0MzyyU16wOYovBPZ + DIu6x4rSh4Y =

13peer A

16peer A

если одноранговый узел A хочет отправить пакет в LAN 10.0.1.0 / 24 на узле B, он просматривает таблицу, сопоставляет маршрут с открытым ключом для узла C и отправляет пакет. Узел C имеет соединение с узлом B и пересылает пакет. Чтобы убедиться, что все одноранговые узлы доступны в любое время, нам нужно установить необязательный параметр persistent-keepalive . Сеанс NAT обычно завершается довольно быстро, и поскольку WireGuard по умолчанию отправляет данные только тогда, когда есть что отправить, соединение между одноранговым узлом A и одноранговым узлом C, а также между одноранговым узлом B и одноранговым узлом C закрывается.Он восстанавливается, когда одноранговый узел A отправляет данные одноранговому узлу C, а одноранговый узел B должен сделать то же самое. Чтобы сеанс NAT оставался активным для обоих одноранговых узлов, мы можем установить keepalive на одноранговых узлах A и B, которые отправляют пакет одноранговому узлу C один раз в 25 секунд (это рекомендуемое значение, достаточно безопасное, чтобы избежать закрытия сеанса). Следовательно, одноранговый узел C может связываться с обоими одноранговыми узлами в любое время и при необходимости пересылать данные.

Давайте изменим последнюю строку, в которой мы добавляем информацию об узле C на узле A. Обратите внимание на значение keepalive , установленное на 25 секунд:

Сценарий № 3: клиенты RoadWarrior получают доступ к корпоративной VPN

Следующий сценарий довольно типичен.Сотрудник хочет получить доступ к корпоративной сети VPN со своего корпоративного ноутбука и телефона, чтобы прочитать некоторые документы.

Сценарий № 3: клиенты RoadWarrior получают доступ к корпоративной VPN

В этом случае и портативный компьютер, и телефон находятся за NAT. Их местоположение может измениться в любой момент, как и их сетевые IP-адреса. «Клиентские» партнеры не имеют общих сетей и хотят общаться только с «сервером». persistent-keepalive не нужен, потому что серверу компании не нужно подключаться к устройству сотрудника.Обычно сотрудник подключается к WireGuard VPN только тогда, когда он хочет передать какие-то данные, а после этого отключается. Даже если клиентское приложение подключено и сеанс NAT завершается, во время следующей передачи данных создается новый сеанс NAT, и сервер компании отмечает обновленные IP-адрес и порт. Все работает как положено.

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

Поддержка приложений

WireGuard поддерживается на многих платформах. Вне Linux вы можете использовать его приложение, написанное на Go. Многие инструменты, такие как systemd-networkd или NetworkManager , добавили встроенную поддержку, что делает использование WireGuard еще проще. В моем случае я установил WireGuard на роутере OpenWrt. В их графическом интерфейсе под названием LuCI есть пакет для WireGuard; вы можете создавать интерфейс, а также добавлять одноранговые узлы из веб-интерфейса маршрутизатора. И до тех пор, пока вы понимаете терминологию, настроить ее очень просто.

WireGuard в веб-интерфейсе LuCI

Пропускная способность

Я использую WireGuard уже более двух недель. У меня нет точных данных о пропускной способности, потому что из-за ситуации с COVID-19 Интернет сильно загружен, и моя скорость меняется в течение дня. Тем не менее, я провел несколько быстрых тестов в нерабочее время, и результаты были впечатляющими.

Моя скорость загрузки Интернета на узле в Чминянах близка к 100 Мбит / с. Удаленный конец имеет оптоволоконный кабель с гораздо более высокими скоростями загрузки и выгрузки.Когда я пытался скопировать видео с моего удаленного сервера, я получал пропускную способность в диапазоне 70–80 Мбит / с. Я проверил загрузку ЦП на RPi, но все еще оставался запас.

Это приблизительные данные только для иллюстрации. Если вам нужен хотя бы какой-то тест, посмотрите статью, в которой авторы WireGuard сравнивают WireGuard, IPsec и OpenVPN. Разница между OpenVPN и WireGuard огромна.

Заключение

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

Mikrotik RouterOS 6.38 IKEv2 Strongswan RSA Auth howto - Paranoids Blog

Привет,

a) настройка часов вашего маршрутизатора

 / system ntp client set primary-ntp = 192.168,223,2
/ установка системных часов time-zone-name = Europe / Vienna

б) генерировать сертификаты

 / certificate add common-name = "paranoids.at Корневой ЦС" name = ca
/ знак сертификата ca ca-crl-host = 192.168.223.106
/ certificate add common-name = test.paranoids.at subject-alt-name = IP: test.paranoids.at key-usage = tls-server name = server1
/ знак сертификата server1 ca = ca
/ сертификат добавить [email protected] key-usage = tls-client name = client1
/ сертификат подписать client1 ca = ca

c) настройте свой сервер

 / экспортный компактный
# янв / 06/2017 12:21:49 от RouterOS 6.38
#
/ ip ipsec предложение
установить [найти по умолчанию = да] auth-алгоритмы = sha256 Enc-алгоритмы = aes-256-cbc pfs-group = modp2048
/ IP-пул
добавить имя = пул1 диапазоны = 192.168.33.0 / 27
/ ip ipsec режим-конфигурация
добавить пул адресов = пул1 длина префикса адреса = 32 имя = тест
/айпи адрес
добавить адрес = 192.168.99.1 / 24 интерфейс = сеть ether2 = 192.168.99.0
/ ip dhcp-клиент
добавить dhcp-options = hostname, clientid disabled = no interface = ether1
/ ip dns static
добавить адрес = 192.168.223.106 имя = тест
/ ip ipsec одноранговый
добавить адрес = 0.0.0.0 / 0 auth-method = rsa-signature certificate = server1 dh-group = modp2048 enc-algorithm = aes-256 exchange-mode = ike2 generate-policy = port-strict hash-algorithm = sha256 \
mode-config = тестовый пассив = да
/ ip политика ipsec
установить 0 dst-адрес = 192.168.33.0 / 27 src-address = 0.0.0.0 / 0

г) экспортные клиентские сертификаты

 / сертификат экспорт-сертификат ca
/ сертификат экспорт-сертификат client1 экспорт-пароль = 1234567890

e) импортировать клиентские сертификаты в strongswan (важно окончание файла)

 администратор scp @ 192.168.223.106: /cert_export_client1.crt.
 scp [email protected]: /cert_export_client1.key.
 scp [email protected]: /cert_export_client1.key.

 мв cert_export_ca.crt /etc/ipsec.d/cacerts/cert_export_ca.pem
 mv cert_export_client1.crt /etc/ipsec.d/certs/cert_export_client1.pem
 mv cert_export_client1.key /etc/ipsec.d/private/cert_export_client1.pem

f) правильно настроить strongswan

/etc/ipsec.conf

 conn test
 keyexchange = ikev2
 ike = aes256-sha256-modp2048
 esp = aes256-sha256-modp2048
 ikelifetime = 24 часа
 срок службы = 30 м
 dpddelay = 120 с
 left =% defaultroute
 leftsourceip =% config
 leftcert = cert_export_client1.pem
 [email protected]
 leftfirewall = да
 справа = 192.168.223.106
 rightubnet = 192.168.99.0 / 24
 rightid = "CN = test.paranoids.at"
 auto = добавить

/etc/ipsec.secrets

: RSA cert_export_client1.pem "1234567890"

г) запустите свой vpn

: ~ # systemctl перезапуск strongswan
: ~ # Тест ipsec up

Ресурсы:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples
http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Ikev2_Server_Setup

Подсказка:
Для strongswan под Debian Jessie вы должны удалить парольную фразу из закрытого ключа!
Для Android установите Server-Identity: CN = test.paranoids.at!

Удачи!

IPsec туннель: GRE, Linux и Mikrotik

улица Вальдова

12.11.2016

Введение

Следуйте инструкциям, которые нужно добавить, чтобы включить этот туннель, расположенный на IPsecu mezi Linuxem (Debian) и Mikrotikem. Подобнч нвод в Интернету ходн, ненаэль узелену варианту ткайц се прв уведен комбинаце с Микротикем в ситуац, когда на одном из разных каналов существует в подсети.

Допуск jsem si pi spojovn rznch lokalit vystail s OpenVPN. Если вы хотите, чтобы это был надежный фунгуйc VPN, ктер м ирокоу подпору напрзнми зазэнми операнми систмы. Jene v podn Mikrotiku je trochu pot v tom, e subporuje auttentizaci pouze SHA1 (MD5 nepotm) a maximln penosov rychlost con na 30-40Mbitech (CloudCore board). Тато рыхлость рокы бохат стаила и нарело сам по себе ограниченность интернетов конъективности. IPsec на том доводе, небодкй HW подпое ифровн у нктерч платы роутера требует рыхлости мези dvma body 470-480Мбит - к хешовой функции SHA256 + ifrovn AES-256-CBC.

Упозорнн

Проблематика IPsecu je pomrn obshl a v rmci tohoto nvodu jsou nkter vci zmrn zjednodueny nebo zamleny. Остатн клэм е IPsec туннель розжет, теории си кад мне настудовать см 🙂

Факта

Mikrotik m подпору IPsec в закладке, в Linuxu вы используете strongSwan 5.2.1 - в Debianu яко стейнойменн балл. S verz 4.x uveden nvod nefunguje.
IPsec m dv provozn fze *, jejich spn probhnut je klem k фунгуйсму ифровн.Dleit je, aby na obou stranch tunelu byly nastaveny stejn параметры:
- Reim - туннель
- Hashovac Funkce - SHA256 **
- алгоритм ifrovac - AES-256-CBC **
- скупина Диффи-Хеллмана - modp4096 ***
- Autentizace - RSA для ключей 4096 бит
Обь страны тунелу по млы мт веейн IP адрес. Покуд з няхо дводу нельз, зэ запнутм волбы NAT-traversal donutit IPsec к тому, абы акцептовал jednu stranu tunelu za NATem.Druh vak veejnou IP mt mus. IPsec комуникация на порте UDP 500 и протоколы 50 и 51. Запустить NAT-T, используя UDP 4500. На firewallech допорууйи нечат поволено ве уведен.
Dle je nutn mt sprvn nastaven Политика. Политика Je vlastn pravidlo, kter k jdru, jak pakety se budou tunelem odeslat.
IPsec тоти невытв св сов рожран, эль джен пов дру: покуд найде пакет, ктер дде од А к Б, так ми хо дэй, й хо заифруй а полу на другой страной тунелу. Druh strana pak tento paket rozifruje a ped jdru, aby si ho
doruilo kam potebuje.Pro lep pedstavu jsou ZDE diagramy popisujc tok paket.

* Fze slou k autentizaci, vyjednn parameter pro ifrovn kanlu a vmnu kl. Parametry pro fzi 1 a ifrovn kanlu mohou bt rzn (jak v Linuxu, tak v Mikrotiku se nastavuj na dvou mstech), avak pro vt blbuvzornost doporuuji ve stejn.

** Nkter Routerboardy имеет жесткую подпору SHA1, SHA256 и AES-CBC. или ифровн дейфровн
Je pot rychl bez zte CPU.

*** Velikost DH (и надежность hashovac funkce) м zsadn vliv na dobu spojen ipsec tunelu.Linux - это Mikrotik, который использует ифровак, чтобы доцела trv. Pi pouit определенч параметр je to jet snesitelnch 6-15 секунд. В ppad DH mod8192 нужно делать это на 20-40 секунд после включения routerboardu.

Prakticky

На левом сервере Linux и в нанометровом коде наинсталлирован SW strongSwan. Na stran prav je Mikrotik.
Jak Linux, tak Mikrotik jsou pipojeny do Internetu a na svch rozhranch maj veejn IP address, zde pro pklad 1.1.1.1 a 2.2.2.2.
На Linuxu я вытвоено манекен rozhran dmIPSec s IP 172.30.255.1/30, na Mikrotiku brigde brIPsec
bez pipojench fyzickch rozhran s IP 172.30.255.2/30. Смысл манекена и бригады в том, е на обоу странч е потеба мт настеноу няку IP адрес, эль нен потеба, абы была доступн на физикм рожран.
Za normlnch okolnost komunikace mezi 172.30.255.1 a 172.30.255.2 фунговат неме, небо jsou na obou strojch ve stejnm subnetu (/ 30) a nen mezi nimi pouiteln cesta (brigde, aj.).
Vzjemn komunikace mezi 172.30.255.1 a 172.30.255.2 je vak mon dky:
- Вытвоенму туннель IPsec с вейейнми IP-адресами 1.1.1.1 и 2.2.2.2.
- Политика Nastavenmu, kdy jdro OS вымуч пакет vyhovujc podmnce tunelu a pole ho na druhou stranu. V tomto ppad je на стране Linuxu
  podmnka 172.30.255.1/32=>172.30.255.2/32 на странице Mikrotiku opan 172.30.255.2/32=>172.30.255.1/32.
Vytvoen bezpen komunikace mezi IP adresami 172.30.255.1 и 172.30.255.2 je zkladem zzen GRE tunelu. Горшок PES GRE Tunel
me tct veker dal komunikace z rznch st a je mon li libovoln smrovat. GRE туннель м здройов гвоздика адреса таких,
e vyhov policy IPsecu a tud jsou ifrovny a peneny k druhmu zazen. GRE туннель витв нов сов рожран greClient1 a jsou mu tedy pidleny jin IP
адрес 172.30.255.129/30 а 172.30.255.130/30. Тыо адреса йсу так брнами про смровн.

Co se te adres 172.30.255.x, tak smysl dlen do / 30 je ten, e se jedn o service IP a snahou je minimalizovat monost
колизе с IP адресами провознч подст.

Адрес pro IPsec:

	Подсеть	Linux	Микротик
Клиент1	172.30.255.0/30	172.30.255.1	172.30.255.2
Клиент2	172.30.255.4/30	172.30.255.5	172.30.255.6
Клиент3	172.30.255.8 / 30	172.30.255.9	172.30.255.10

Адрес pro GRE:

	Подсеть	Linux	Микротик
Клиент1	172.30.255.128/30	172.30.255.129	172.30.255.130
Клиент2	172.30.255.132 / 30	172.30.255.133	172.30.255.134
Клиент3	172.30.255.136/30	172.30.255.137	172.30.255.138

Tmto systmem lze do jednoho C-ka (172.30.255.0/24) umstit 32 IPsec a GRE Tunel.

Linux

Используйте доступ к Debian, используя SSH и pstup jako root.Instalace strongSwanu:

apt-get install strongswan openssl

StrongSwan m nsledujc конфигурация soubory:

/etc/ipsec.conf
/etc/ipsec.secrets
/etc/ipsec.d/

Витвоен ОГА кл

# Vytvoreni privatniho klice
openssl genrsa -out LINUX_private.pem 4096

# Vytvoreni verejneho klice
openssl rsa -in LINUX_private.pem -pubout> LINUX_public.pem

Soubor LINUX_private.pem nakoprujeme do adrese /etc/ipsec.d/private/
Soubor LINUX_public.pem nakoprujeme do adrese /etc/ipsec.d/certs/
Soubor LINUX_public.pem vykoprujeme ven z Linuxu, budeme ho importovat do Mikrotiku.

Msto openssl lze vyuty pkaz ipsec pki --get a --pub. Vce v dokumentaci k strongSwanu.

Наставен сильный, Свану

Обсах сообра / etc / ipsec.конф :

# Spolecne nastaveni pro vsechna pripojeni
conn% по умолчанию
        тип = туннель
        esp = aes256-sha256-modp4096!
        ike = aes256-sha256-modp4096!
        ikelifetime = 12 ч.
        keylife = 1 час
        rekeymargin = 9м
        keyingtries =% навсегда
        keyexchange = ikev1
        authby = pubkey
        left = 1.1.1.1
        leftsigkey = LINUX_public.pem

# Spojeni na Mikrotik1
conn klient1
        право = 2.2.2.2
        праваigkey = CLIENT1_public.pem
        leftsubnet = 172.30.255.1 / 32
        rightsubnet = 172.30.255.2 / 32
        auto = start

Soubor obsahuje sekci spolenou pro vechna spojen % default a sekce pro jednotliv peery. Ve spolen sekci je uveden typ tunelu,
ifrovn hashovac funkce, zpsob autentizace, veejn IP-адрес Linuxu и jeho veejn kl. Ссылка на kl soukrom je v souboru
ne. В клиентск секци е веэйн IP адрес Микротику, нзев соубору с вейнм клем (десять се мус тепрве додать) полис.Klientsk sekce se
пак мне копировать для поту клиент. Soubory s kli se hledaj v /etc/ipsec.d/certs/ .

Obsah souboru /etc/ipsec.secret :

# Jmeno souboru s privatnim klicem pro vsechna odchozi autentizacni spojeni
# Pozor: dvojtecka na zacatku radku je spravne
: RSA LINUX_private.pem

Собрание с ключом, принадлежащее v / etc / ipsec.д / частный / .

ул. Наставена

# Витвоен пустышка рожран
IP ссылка добавить имя dmIPsec тип фиктивного
ip link установить dev dmIPsec вверх

# Придани ИП делать пустышки рожрани - klient1
ip адрес добавить 172.30.255.1/30 dev dmIPsec

# Вытворени и спустени GRE tunelu - klient1
IP-туннель добавить режим greClient1 gre local 172.30.255.1 удаленный 172.30.255.2
ip link set dev greClient1 вверх
IP-адрес добавить 172.30.255.129/30 dev greClient1

Share :

Linux ipsec mikrotik: Page not found – WWW.LUSHNIKOV.NET

IPSec между Debian и MikroTik

IPSEC между Mikrotik и Ubuntu (16/18/20) поверх IPIP туннеля.

Микротик

подготовка

настройка

Ubuntu

IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера

IPSec: Туннель между Mikrotik и Openswan

Непростой IPSec с Linux | Admins.kz

Концепция IPSec

IPSec в Linux

Проверка работоспособности

Настройка VPN L2TP+IpSec между MikroTik и CentOS 8

Какие задачи может решить VPN туннель между MikroTik и VPS CentOS 8

Как настроить VPN L2TP+IpSec между MikroTik и VPS CentOS 8

1. Настройка VPN сервера L2TP на удаленном VPS сервере на CentOS 8

2. Настройка L2TP клиента на MikroTik

l2tp/ipsec на Centos — Asterisk IP-телефония

IPsec VPN Mikrotik для Linux

Mikrotik Linux GRE / IPSec, strongswan · GitHub

IPSec Tunnel: Mikrotik — pfSense

Введение

Требования

Настройка фазы 1 — pfSense

Настройка фазы 1 — Mikrotik

Проверка фазы 1

Настройка фазы 2 — pfSense

Настройка фазы 2 — Mikrotik

Тестирование конфигурации

Заключение

Настройка выделенного VPN-устройства Mikrotik L2TP IPsec

Руководство Mikrotik L2TP IPSec VPN — От начала до конца Устройство

Первые шаги

Отключить неиспользуемые службы

Настроить пароль

Отключить обнаружение Winbox при фильтрации WAN / обратного пути

Подсеть VPN

Создание учетных записей пользователей

Политика VPN

L2TP VPN Минимальные правила межсетевого экрана без правил

Включение сервера L2TP

Разрешить VPN для локальной маршрутизации

Примечание о поиске в DNS

Несколько клиентов — проблема с IP-адресом одного источника

WireGuard — VPN для реального использования

IPsec

Межсайтовый IPsec Плюсы и минусы

OpenVPN

Плюсы и минусы

WireGuard

Плюсы и минусы

Все являются одноранговыми узлами

Создание однорангового ключа

Сценарий № 1: VPN типа «сеть-сеть», в которой оба одноранговых узла имеют общедоступный IP-адрес.

Сценарий № 2: Два одноранговых узла за NAT и один одноранговый узел с общедоступным IP-адресом

Сценарий № 3: клиенты RoadWarrior получают доступ к корпоративной VPN

Поддержка приложений

Пропускная способность

Заключение

Mikrotik RouterOS 6.38 IKEv2 Strongswan RSA Auth howto - Paranoids Blog

IPsec туннель: GRE, Linux и Mikrotik

Введение

Упозорнн

Факта

Prakticky

Linux

Витвоен ОГА кл

Наставен сильный, Свану

ул. Наставена

Добавить комментарий Отменить ответ