Mikrotik l2tp ipsec клиент

Содержание

Видеокурс по MikroTik

Вы можете изучить настройку MikroTik с помощью видеокурса "Настройка оборудования MikroTik" . Курс содержит все темы из официального учебного курса MTCNA + много дополнительного материала, который полезен на практике.

Схема сети

В головном офисе установлен маршрутизатор GW1. Он же будет настроен в качестве VPN-сервера. В этом же офисе работает сервер DC1, который является контроллером домена и параллельно выполняет функции DNS и WINS-сервера. К головному офису будет подключаться компьютер, который будет настроен как VPN-клиент.

Головной офис
IP-адрес внешней сети головного офиса: 10.1.100.0/24
IP-адрес внешнего интерфейса маршрутизатора GW1: 10.1.100.1/24

IP-адрес внутренней сети головного офиса: 192.168.15.0/24
IP-адрес внутреннего интерфейса маршрутизатора GW2: 192.168.15.1/24
IP-адрес сервера DC1: 192.168.15.10/24

Удаленный компьютер
IP-адрес удаленного компьютера: 10.1.200.1/24

VPN-канал
IP-адрес VPN-интерфейса маршрутизатора GW1: 172.16.30.101/32
Пулл адресов VPN-канала: 172.16.30.102 – 172.16.30.253

Настройка

Настройка маршрутизатора

Через графический интерфейс

Включить L2TP-сервер. Не смотря на то, что L2TP не несет в себе нормального шифрования, лучше оставить только аутентификацию "mschap2" как наиболее надежную.

Создать пул адресов для VPN-подключений:

Создать профиль для VPN подключений. Указать адрес сервера DC1, который является DNS и WINS сервером. Без указания DNS и WINS VPN-подключение произойдет, но не будет возможности обращаться к узлам по именам.

Добавить аккаунт пользователя:

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

Создать профиль IPSec для подключения клиента (адрес 0.0.0.0/0 т.к. удаленный адрес клиента неизвестен):

Через консоль

/interface l2tp-server server
set authentication=mschap2 enabled=yes

/ip pool
add name=vpn-pool ranges=172.16.30.102-172.16.30.253

/ppp profile
add name="L2TP client-to-site" change-tcp-mss=yes local-address=172.16.30.101 remote-address=vpn-pool dns-server=192.168.15.10 wins-server=192.168.15.10

/ppp secret
add name=user-laptop password=user-laptop-password profile="L2TP client-to-site" service=l2tp

/interface ethernet
set ether1-LAN1 arp=proxy-arp

/ip ipsec peer
add address=0.0.0.0/0 comment=client-to-site enc-algorithm=3des,aes-128,aes-256 exchange-mode=main-l2tp generate-policy=port-strict nat-traversal=yes secret=ipsec-password send-initial-contact=no auth-method=pre-shared-key

Настройка маршрутизации

Следует учесть

  • AES является единственным алгоритмом, который поддерживается модулем аппаратного шифрования, если такой установлен на маршрутизатор.
  • Если требуется подключение только по L2TP без IPsec, то достаточно пропустить последний пункт по настройке IPsec. При этом надо учесть, что встроенный VPN-клиент Windows не поддерживает подключение по L2TP без IPSec. Для того, чтобы такое подключение заработало необходимо править реестр операционной системы.

Проверка

Для того, что бы проверить VPN-соединение достаточно запустить ping с компьютера VPN-клиента на любой компьютер в сети за маршрутизатором GW1.

Долгое время не подходил к настройке VPN на Микротик, т.к. и нужды в реализации этой функции не было, и времени разбираться с настройкой – тоже. Но вот клюнул жареный петух и пришлось. Как выяснилось, сама по себе черновая настройка VPN-сервера посредством L2TP и шифрованием IPSec задача вполне себе тривиальная и решаемая за 10-15 минут.
Итак, начнем мы с определений.
Протокол L2TP – инструмент для обеспечения канала передачи данных, т.н. туннеля. В конечном итоге средство для создания VPN.
IPSec – набор средств для шифрования-дешифрования данных при их прохождении по туннелю.
При настройке мы по большей части будем пользоваться средой приложения Winbox, в нем работать несколько нагляднее, т.к. именно конфигурирование ВПНок подразумевает под собой огромное количество ключей в командах, которые будут хуже восприниматься в портянке текста.

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:  Блютуз адаптер для компьютера программа


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


Расширенные настройки.
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


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

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

Никто не мешает создать другой сет предложений, но смысла я не вижу, пройдемся по дефолтному.
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.

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

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

Ура, наш сервер настроен!

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

То есть какой-нибудь ПК с IP 192.168.30.28 не достучится до удаленного сервера/принтера с IP 192.168.31.11
Почему?
Идем в IP > Firewall > NAT:

Если правила настроены так, то всё заработает. Во всем виноват пресловутый маскарадинг. По-умолчанию 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-интерфейс.

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

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

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

Читайте также:  Что означает кирпич на андроиде

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

Разного рода ошибки Firewall
И здесь речь не только о самом Микротике, но и о настройках брандмауэра/антивируса у хоста, шлюза клиента или прокси провайдера. Говоря о правилах firewall самого микротика, создать проблемы могут не только правила из цепочки input, но и из цепочки forward. Вы же, очевидно, настроили файрволл так, чтобы быть за ним как за каменной стеной? Ну, и о NAT тоже не стоит забывать. Дебажить всё это хозяйство поможет встроенный инструмент сниффинга трафика, а развернуть дамп можно в Wireshark.

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

Mikrotik, virtualization, Linux, servers, networks and more

In the previous post we have shown a Mikrotik router as a L2TP/IPSec server. In this scenario, we are using either Windows clients or mobile devices based on Android or Apple iOS operating systems. Here is a new scenario – we may have a need to use another Mikrotik device as the VPN client.

The most common scenario is that you want to connect a remote network with a main network. Using the L2TP/IPSec VPN connection, you will have in the same time the routable tunnel and the full power of IPSec encryption.

We can see the benefits from this combination. Using the routing tunnel means that we can assign the IP address to it and use it as any other network interface. In the other hand, the IPSec part will protect our tunnel with the strong encryption. Furthermore, we need to use a very simple IPSec policies as we are using the IPSec tunnel in the transport mode.

You can find the following tutorials related to the L2TP/IPSec VPN clients on my blog:

Our scenario

In today’s scenario, we will add two more devices in our virtual network.

These two Mikrotik devices will use the same mechanism as Windows clients in order to connect to the network. In the first step, both Mikrotik routers will establish the PPPoE connection. In the second step, they will use this link to establish the VPN connection to the Contoso router.

The setup procedure depends on the Mikrotik RouterOS version. Therefore, we will show here setup for the one RouterOS 6.36.3 device and one 5.26.

Mikrotik devices with RouterOS v6.x

On Mikrotik devices that runs RouterOS version 6.x, you can set the L2TP/IPSec VPN connection in a minute. Everything can be done in one window or with the single command line.

Click on the PPP menu item. The new window will open. Here are all PPP connection on the device. Click on the button [ + ] and you can see drop-down menu with all available PPP interfaces.

Choose the L2TP client option from the list. The new window will open. You should configure all those options printed in blue and framed in red.

We need to enter the IP address of the VPN server and the credentials for access. We also need to choose the authentication protocol. It’s strongly advised to use these protocols checked on the screenshot.

As the last part, we will check the box near the label Use IPSec and type the IPSec pre-shared key in the field named IPSec Secret.

Click on the button [ Apply ]. Mikrotik will create a new VPN connection, including the IPSec part. In a short while, Mikrotik will update the status of the connection.

Congratulations! You’ve just successfully made the VPN connection.

We can check the IPSec parameters. We will open IP > IPSec and choose the tab named Peers. We have dynamically defined peer with the address of the Contoso router.

Choose the Policies tab and check the dynamic policy for transport mode.

On the Contoso side, the L2TP user is connected.

In the same time, we have an active dynamic IPSec policy.

Читайте также:  Как добавить времена года в симс 4

There is no difference between Mikrotik device and any other kind of the client in the process of connecting.

Mikrotik devices with RouterOS v5.26 and earlier

Our second Mikrotik device uses RouterOS v5.26. On all RouterOS versions up to 5.26, we can set the L2TP/IPSec connection, but we need to make a few more steps.

I will reveal the secret to you. We need to make the IPSec part manually. This is very similar with this scenario when one side is behind the NAT. But you will see.

The first step is the same. Open the PPP menu. We will see the PPP window, where we can choose the drop-down menu with the list of available PPP interfaces. We will again select the L2TP client.

The newly opened window looks familiar, as it’s a very similar to that in RouterOS v6. The difference is that we don’t have the IPSec section.

Fill all necessary fields and click on the button [ Apply ]. Mikrotik will create the new VPN interface and in the short while, we will see the connection status update.

Congratulations again! You’ve successfully made the L2TP tunnel. Alas, we have the tunnel without encryption.

However, the encryption isn’t the problem for us. We knew how to setup the IPSec tunnel. Therefore, we will configure it in a minute. In addition, don’t forget to write down all necessary parameters. The best way is to fill one document about your IPSec configuration.

We need to define the IPSec peer. The biggest change here is that the mode of IPSec operation is main l2tp.

The next step is the IPSec policy. We need to make it manually, too. This is the transport mode. Therefore, the source address will be the same as the SA source address.

On the Action tab we must enter the same IPs as on the General tab. In addition, we need to leave the checkbox Tunnel unchecked.

Please, pay attention that you will use the Default proposal here. You should check it’s settings, as there can be differences between older and newer settings. The newer versions by default use the SHA1 authentication algorithm, while older versions use 3DES.

We will switch to the Installed SAs tab and we can see that tunnel is established.

We will check again the Contoso side. Our new router is connected using IPSec protocol.

The main difference is that this tunnel is not limited only to the port 1701 UDP, used for the L2TP tunneling. If you like, you can specify the port number on the General tab on the client router. Then our IPSec tunnel will protect only the L2TP traffic.

We can also see the SAs for this connection on the Installed SAs tab. We left the default IPSec proposal settings on the client side and the encryption algorithm is ancient 3DES.

A few words on the network ports

In the end of this article, we will make a short analysis of the network ports used for these network connections. Therefore, we will open IP > Firewall and select the Connections tab.

Every client connection consists of three connections – three connections make one tunnel.

I will not going too deep in the explanation of the TCP/IP protocols. In short, TCP/IP is a suite of the protocols. Every protocol has its number. Two well-known protocols, TCP and IP, have numbers 6 and 17 respectively.

We need the UDP protocol for the L2TP tunnel. This connection will use the port 1701 for communication. Furthermore, both sides use the same port number.

Then we need the UDP protocol and port 500 to establish the first IPSec phase. This is the second communication channel. Again, both sides use the same port number. Alternatively, if the IPSec traffic passing through the NAT device, we can see the UDP port 4500.

And the third channel of communication is between devices exchanging the IPSec traffic. In our case, those devices are routers themselves. Unrelated to the IPSec tunnel mode, this third channel will use one of two specific protocols.

The IPSec tunnel can use either the ESP protocol (number 50) or AH protocol (number 51). In most cases we will use the ESP protocols, as we can encrypt the payload.

On our screenshot, we can see that a L2TP channel, an IPSec phase I channel and an IPSec ESP channel together form a single L2TP/IPSec connection.

When you have a problem to establish a L2TP/IPSec connection, the first step is to check again the VPN settings and the second to check the Firewall settings. Check that these ports and protocols are allowed to input into the device. In case that they are not explicitly enabled in the firewall rules, your router will block them.

We have a theme for another article – Mikrotik Firewall.

(Edit 26.09.2018.) Now when you see how easy it is to setup this connection, you should consider replacing those old PPTP VPNs and replacing it with a modern and stronger L2TP/IPSec VPN tunnel.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock detector