Настройка VPN L2TP IPSec на MikroTik

Многим может понадобиться настроить VPN для дома или офиса. В этой статье подробно рассмотрим настройку VPN L2TP IPSec. Сама по себе начальная настройка VPN-сервера посредством L2TP и шифрованием и шифрованием IPSec решается за 15 минут.

Итак, начнем мы с определений.
Протокол L2TP — это инструмент для создания канала передачи данных, или туннеля. В конечном счете это средство для создания VPN.
IPSec — это набор средств для шифрования данных при их прохождении по каналу (туннелю).
При настройке мы по большей части будем пользоваться средой приложения Winbox, в нем работать несколько удобнее, так как именно конфигурирование VPN подразумевает под собой огромное количество ключей в командах, которые будут хуже восприниматься в тексте статьи.

В примере мы возьмем Mikrotik RB2011UAS-2HnD с версией прошивки 6.42.6 (stable) от Jul/06/2018 11:56:50. Пул IP для локальной сети 192.168.88.0/24, WAN-интерфейс sfp1, локальный бридж назовем bridge.

Настройка туннеля L2TP

1. Создаем пул IP-адресов для наших будущих VPN-клиентов. IP > Pool

1 1 1

Name: vpn_pool — имя для нового диапазона IP.
Addresses: 192.168.87.0/24 — сам диапазон, также можно указать что-то вроде 192.168.87.10-192.168.87.25, без применения маски.
Next pool: none

2. Идем в PPP > Profiles и создаем профиль для создаваемого туннеля.

1 2 2

Нас интересуют несколько вкладок.

General:
Name: l2tp_test_profile — название профиля
Local address: vpn_pool (здесь можно указать и шлюз нашего роутера. У нас это. 192.168.88.1)
Remote address: vpn_pool — пул раздаваемых IP.
Change TCP MSS: yes

Protocols:
Тут всё оставляем по-умолчанию.
Use MPLS: default
Use compression: default
Use Encription: default

Limits:
Only one: default

3. Заходим в PPP Secrets, а в этом месте мы настраиваем будущих клиентов нашего VPN-сервера.

1 3 3

Name: vpn_test_user — имя пользователя при подключении к VPN
Password: тут уж сами решайте, это пароль для подключения. Рекомендую создать сложный пароль.
Service: l2tp
Profile: l2tp_test_profile

4. PPP > Interface и кликаем на кнопку L2TP Server. Тут мы и включим сервер.

1 4 4

Enabled — yes, это и включает L2TP-сервер
MTU / MRU — 1450, выставляем максимальный размер кадра (фрейма) информации. Без надобности не меняем.
Keepalive Timeout — 30, время в течение которого туннель считается живым и не требует подтверждения в виде проверочного фрейма.
Default profile — l2tp_test_profile, указываем созданный ранее профиль.
Authentication — mschap2, метод аутентификации, достаточно оставить только этот.
Use IPSec — yes, использовать ли шифрование? Конечно, указываем — да.
IPSec Secret: придумайте секретку (не путайте с паролем, так как секрет — это дополнительный параметр, указываемый на клиентской стороне).

Настройка шифрования данных, IPSec

Выше мы подняли L2TP-сервер и включили функцию IPSec, теперь давайте её настроим.
5. IP > IPSec > Groups

1 5 5

Может быть досадный баг при соединении к серверу с дефолтной группой политик. Создайте свою, в нашем случае это policy_group1.

6. IP > IPSec > Peers, настройка общения пиров IPSec, алгоритма шифрования.

1 6 6

Основные настройки.
Address: 0.0.0.0/0, адрес, оставляем такой.
Port: 500
Auth method: pre shared key, метод аутентификации.
Exchange mode: main l2tp, режим обмена ключами.
Passive: yes, ставим галочку, да.
Secret: да, это всё та же секретка для IPSec, та же, что в пункте 4.

1 7 7

Расширенные настройки.
Policy template group: policy_group1, тот самый шаблон, который мы создали взамен дефолтного.
Send Initial Contact: yes, здесь да.
NAT Traversal: yes, и здесь.
My ID Type: auto
Generate policy: port override
Lifitime: 1d 00:00:00
DPD Interval: 120
DPD Maximum failures: 5
Proposal check: obey

1 8 8

Настройки шифрования.
Hash algorithm: sha1
Encryption Algorithm: 3des aes-128 aes-256
DH Group: modp 1024

7. IP > IPSec > Proposals, так называемы «Предложения».
Как бы объяснить этот момент? Скажем так, это то, какие варианты/опции подключения сможет предложить наш сервер подключающимся клиентам.

1 9 9

Никто не мешает создать другой сет предложений, но смысла я не вижу, пройдемся по дефолтному.
Name: default, в случае с сетапом по-умолчанию, имя останется неизменным, попытаетесь поменять — вылетит ошибка.
Auth algorithms: sha1, алгоритм аутентификации.
Enrc. algorithms: 3des, aes-256 cbc, aes-256 ctr, алгоритмы шифрования.
Life time: 00:30:00, время жизни. Как я это понимаю, время между сменами алгоритмов.
PFS Group: mod 1024

Нельзя не отметить, что пункты 6 и 7 частично повторяют друг друга. Вам не показалось. В пунктах 4 и 6 мы ведь тоже дублируем Secret. Зачем? То ли это баг, то ли фича, но при подключении различных клиентов (разные ОС) словно бы учитываются разные части конфига IPSec, так что не ленимся и настраиваем всё. Например, параметр PFS Group, который выставлен на 1024 в одном месте работает для Windows, в другом к примеру для iOS.

Дополнительная настройка Firewall

Чтобы всё работало как надо требуется настроить пару фильтрующих правил:

/ip firewall filter
add chain=input action=accept protocol=udp port=1701,500,4500
add chain=input action=accept protocol=ipsec-esp

Скорее всего у вас по дефолту для политики forward стоит действие drop — chain=forward action=drop, так что потребуется разрешить форвардиться с IP нашего VPN-пула в локальную сеть:

/ip firewall filter
add chain=forward action=accept src-address=192.168.87.0/24 in-interface=!sfp1 out-interface=bridge comment="allow vpn to lan" log=no log-prefix=""

Поздравляю, наш сервер настроен!

Примечание. Вы подняли туннель, узлы за VPN-сервером пингуются с клиентской железки и вроде бы всё должно быть хорошо и прекрасно, но… Если клиентская железка — это Микротик, то просто так хосты за ним ту сетку не увидят:

{192.168.30.0/24} <> L2TP Client <-tunnel-> L2TP Server <> {192.168.31.0/24}

То есть какой-нибудь компьютер с IP 192.168.30.28 не достучится до удаленного сервера/принтера с IP 192.168.31.11
Почему?
Идем в IP > Firewall > NAT:
1531986339 l2tp 08 10
Если правила настроены так, то всё заработает. Во всем виноват пресловутый маскарадинг. По-умолчанию masquerade настроен для физического WAN-интерфейса, которым может выступать sfp1/ether1/etc., но нам-то нужно, чтобы пользователи могли ходить в интернеты и через L2TP-подключение! Поэтому нужно создать следующее правило:
Chain=srcnat
Out. Interface=l2tp_client
Action=masquerade
Ну, теперь уж точно всё.

Особенности
Настройка маршрутизации.

Довольно очевидный момент, если у вас две разнесенные сетки, то пакетам нужно знать, что для них будет шлюзом. Настройка простая и логичная, вот у нас имеются две подсети — 192.168.30.0/24 и 192.168.31.0/24, которые очень хотят общаться друг с другом, но не могут. Идем в IP > Route и тыкаем на плюсик, чтобы создать новый маршрут. В качестве Dst.Address укажем сеть, в которую нам нужно отправлять трафик, а Gateway — это будет l2tp-интерфейс.

1 10 11

Попробуйте пингануть хост за одним роутером с хоста за другим. Вам это вряд ли удастся, так как отсутствует обратный маршрут для ICMP-пакетов, нужно создать похожий route на другом маршрутизаторе, но с указанием второй сети.
В общем создание masquerade в NAT будет недостаточно.

Проблема NAT
Точнее это даже не проблема, а следствие настройки. Создавая правило с действием masquerade для out-interface L2TP мы сталкиваемся с тем, что уходящие с него пакеты меняют свой родной src.address из пулов 192.168.30.0/24 и 192.168.31.0/24 на IP, который присвоен L2TP-соединению.
Допустим, L2TP соединениям присваиваются IP из пула 192.168.29.0/24, и вот поднятому виртуальному интерфейсу выдан IP 192.168.29.252. Пакеты по велению раут-таблицы лезут на него и теряют свои уникальные src.address 192.168.31.51…52…251…etc., они заменятся адресом интерфейса из VPN-пула. Здесь и возникает проблема. Устройство на другой стороне будет пытаться адресовать ответный трафик не оригинальному IP, а всё тому же адресу L2TP-интерфейса. Всему виной правило NAT превратившее всё многообразие хостов 192.168.31.0/24 в скромный 192.168.29.252:

[admin@MT1] > ip firewall nat
[admin@MT1] /ip firewall nat> add chain=srcnat out-interface=your_l2tp_connection action=masquerade

Вместо masquerade нужно использовать просто action=accept. В чем разница? Маскарад заменяет адрес отправителя на первый адрес out-interface, который в нашем случае является айпишником туннеля. А вот действие accept, говорит, что пакеты обрабатывать не нужно, как раз таки это является залогом правильной работы IPSec. Вот и всё, в итоге правило должно выглядеть так:

[admin@MT1] > ip firewall nat
[admin@MT1] /ip firewall nat> add chain=srcnat out-interface=your_l2tp_connection action=accept

Proxy ARP на локальном бридже
Вот настроили вы свой VPN, и прекрасно пингуете с хоста в сетке 192.168.30.0/24 шлюз 192.168.31.1, но больше ничего из удаленной сети вам недоступно. С чем это связано? С дефолтными настройками роутеров может не взлететь по причине неверной настройки параметра ARP на локальном бридже. Открываем раздел меню Bridge и выбираем мост, объединяющий локальные интерфейсы. В окне его настройки ищем строчку ARP и ставим параметр proxy-arp.

Баг с политикой default
Выше уже говорилось об этом, но стоит еще раз заострить внимание на данном моменте. Характерным признаком данной ошибки будут сообщения в логе Микротика «failed to pre-process ph2 packet», а клиент Windows при этом будет выдавать ошибку 789 запуска VPN-сессии, гласящую, что «попытка L2TP-подключения не удалась из-за ошибки, произошедшей на уровне безопасности».
Что делаем?
Идем в IP IPSec Groups и там создаем новую политику, которую после указываем в IP IPSec Peers вместо дефолтной в поле Policy Template Group.
Также вариантом лечения является данный фокус:

ip ipsec peer set 0 policy-template-group=*FFFFFFFF

Данный баг является рудиментом со старых билдов прошивки и проявляется не всегда.

Проблема при реконнекте VPN-сессии

Казалось бы, что страшного, ну отвалился туннель — поднимется же? Поднимется, конечно, но на стороне сервера каждый раз будет создаваться новый динамический интерфейс (с тем же самым названием, но не обманывайтесь). Ведет это к печальным последствиям — все правила и маршруты завязанные на l2tp-интерфейсе отваливаются, потому что он становится unreachable. А потом восстав из пепла новый интерфейс со старым названием чудесным образом во все эти правила и маршруты не попадает — всё приходится делать вручную.
А склады стоят и местные админы вам названивают. Что делать? Вариантов тут два. Либо настраивать OSPF на роутерах, чтобы все нужные нам маршруты вываливались на соседей автоматически при поднятии туннеля. Но это несколько более сложный вариант. Куда как проще запилить вместо динамического интерфейса постоянный созданный руками.
Для этого заходим на Микротик со стороны сервера и тыкаем в PPP. Далее жмем плюсик и выбирает L2TP Server Binding, после чего вбиваем туда данные из вкладки Secrets (оттуда нам потребуется имя пользователя). Ну, и название интерфейсу нужно будет дать.
Всё, это победа. Остается пройтись по правилам и маршрутам, чтобы подставить везде новый интерфейс.