Записки IT специалиста
С ростом значения интернета в нашей повседневной жизни все более востребованными становятся различные сетевые технологии. Если раньше VPN был преимущественно уделом крупных организаций, то сегодня он используется чуть ли не в каждой сети, действительно, сотрудники стали мобильными и удаленный доступ к ресурсам сети уже не блажь, а насущная необходимость. Настройка роутера Mikrotik как VPN-клиента вопрос, на первый взгляд, простой, но есть некоторые не очевидные моменты, которые мы разберем в данной статье.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
В прошлых материалах мы уже коротко рассматривали типы VPN и обращали внимание на неоднозначность используемой терминологии, традиционно термином VPN называют клиент-серверные соединения, где кроме туннельного протокола применяются вспомогательные технологии для установления соединения и контроля его состояния, аутентификации пользователя, согласования параметров подключения и т.д. и т.п. Одним из таких протоколов является PPP.
В рамках данной статьи мы будем рассматривать варианты настройки Mikrotik именно в качестве клиента для поддерживаемых типов VPN-серверов, оставив за кадром туннельные подключения (GRE, IP-IP, EoIP и т.д.). Для работы с этим типом соединений используется специальный раздел PPP, на закладке Interfaces которого можно добавить сетевой интерфейс для нужного типа VPN-клиента. Поддерживаются PPTP, L2TP, SSTP и OpenVPN подключения. Также в списке присутствуют устаревший PPP и PPPoE, который используется для организации доступа в интернет, в данном контексте эти протоколы интереса не представляют.
Также аналогичные действия можно выполнить и в разделе Interfaces, никакой разницы откуда вы будете добавлять сетевой интерфейс нет. Но не будем спешить и перейдем на закладку Profiles, где находятся профили используемые при коммутируемых подключениях. По умолчанию созданы два профиля: default и default-encryption, в которых содержатся некоторые настройки для подключения. Почему некоторые? Потому что большинство опций подключения задаются сервером и клиент должен применять именно их, иначе подключение будет невозможным. Поэтому если вы заглянете в эти профили, то увидите, что большинство настроек там не активно.
Единственным различием двух профилей является опция Use Encryption, которая в default-encryption установлена в положение yes и требует обязательного шифрования подключения. Данная опция игнорируется протоколами SSTP и OpenVPN, которые всегда используют шифрованные подключения.
Означает ли это, что если мы выберем профиль default, то ваше соединение не будет шифроваться? Нет, если сервер использует шифрование и не допускает небезопасных подключений, то ваше соединение также будет зашифровано. Но вот если сервер разрешает небезопасные подключения, то клиент вполне может подключиться без шифрования, таким образом можно осуществить атаку с подменой сервера, когда вы получите незашифрованное подключение и не будете знать об этом. Поэтому если вам явно требуется шифрование канала всегда выбирайте профиль default-encryption.
Мы не советуем менять настройки в стандартных профилях, если вам нужно явно задать иные настройки подключения, то создайте собственный профиль. Также учтите, что опция Use Compression игнорируется для OpenVPN соединений, которые в реализации от Mikrotik не могут использовать сжатие трафика.
PPTP-клиент
Пожалуй, это самый простой в настройке тип соединений. Несмотря на то, что используемое в PPTP шифрование не является надежным, этот протокол продолжает широко использоваться благодаря низким накладным расходам и высокой скорости работы, например, для доступа в интернет.
Для настройки PPTP клиента добавьте интерфейс типа PPTP Client и перейдите на закладку Dial Out, где расположены сетевые настройки.
Настроек немного, и они просты. В поле Connect To укажите FQDN или IP-адрес VPN-сервера, в поля User и Password — имя пользователя и пароль. В Profile выбирается в зависимости от необходимости шифрования нужный профиль. В самом низу рядом с опцией Allow (разрешить) указаны допустимые к использованию протоколы аутентификации, на сегодня безопасным считается только MS-CHAP v2 и следует использовать по возможности только его. Однако помните, что используемый протокол аутентификации должен поддерживаться сервером, в противном случае установить связь вы не сможете.
Опция Keepalive Timeout указывает время переподключения соединения в случае обрыва связи. Бытует мнение, что лучше делать это значение поменьше, мол быстрее будет переподключаться туннель. Но это не так, во-первых, при неполадках на сервере вы будете активно забивать канал и нагружать сервер служебным трафиком, а во-вторых, при кратковременных перебоях связи короткое время будет вызывать переподключение с обрывом всех соединений в канале, а большее значение позволит сохранить туннель. Особенно это актуально для мобильного интернета или беспроводных каналов.
Опция Add Default Route создаст маршрут по умолчанию через туннель, т.е. направит туда весь исходящий трафик, указывайте ее только в том случае, если данный туннель основной способ доступа в интернет.
Никаких иных особенностей и подводных камней здесь нет и если вы правильно указали настройки, то клиент должен будет без проблем подключиться к серверу.
L2TP-клиент
Говоря про L2TP, обычно подразумевают L2TP/IPsec, потому как без шифрования данный протокол в корпоративной среде не используется. Но есть и исключения, некоторые провайдеры, например, Билайн, используют чистый L2TP без шифрования. В этом случае настройки подключения будут выглядеть так:
Обратите внимание на используемый профиль — default, так как соединение не зашифрованное, с профилем default-encryption вы не сможете подключиться к серверу провайдера. Add Default Route ставим только если это основное соединение с интернет. Также имеет смысл использовать опцию Allow Fast Path, для разгрузки CPU, особенно на младших моделях, но учтите, что с данной опцией соединение может работать неустойчиво, в таком случае ее придется отключить.
Для работы с L2TP/IPsec настройки будут немного иные, во-первых, используем профиль default-encryption и включаем использование IPsec установкой флага Use IPsec, при этом становится активным поле IPsec Secret, куда вводим предварительный ключ.
Опция Allow Fast Path при использовании IPsec игнорируется и в ее установке нет никакого смысла, так же не забывайте про опцию Add Default Route, в большинстве корпоративных сценариев устанавливать ее не следует.
Вроде бы тоже ничего сложного в настройках L2TP/IPsec нет, но если вы попытаетесь подключиться к Windows Server, то у вас ничего не получится. В чем же дело? А дело в настройках IPsес, перейдем в IP — IPsec — Proposal и откроем настройку по умолчанию. Proposal или предложение IPsec содержит список алгоритмов защиты канала, которые устройство предлагает для установления соединения. Понятно, что для успешного установления канала поддерживаемые методы защиты должны совпадать.
В предложении IPsec по умолчанию обращаем внимание на опцию PFS Group, она отвечает за применение технологии совершенной прямой секретности (Perfect forward secrecy, PFS), которая предусматривает создание уникальных сессионных ключей по алгоритму Диффи-Хеллмана, что делает невозможным расшифровку перехваченного IPsec трафика даже при наличии долговременных ключей (в данном случае предварительного ключа).
Windows Server по умолчанию не поддерживает совершенную прямую секретность, поэтому PFS Group нужно выставить в состояние none, после чего соединение успешно установится.
Обратите внимание, что в данном случае мы изменили настройку по умолчанию, но в данном случае это оправдано. Настройки IPsec достаточно сложны и вряд-ли человек не имеющий опыта работы с данной технологией сможет все правильно настроить с первого раза. Но это изменение следует учитывать при создании других соединений, использующих IPsec и приводить настройки с обоих сторон к общему виду.
Хотя более правильным является создание своего предложения (Proposal) и политики (Police) для каждого соединения, но эта тема далеко выходит за рамки статьи.
SSTP-клиент
Мы не будем останавливаться на уже описанных нами опциях, которые общие для всех видов коммутируемых подключений, а сосредоточимся на новых, свойственных именно этому типу VPN. SSTP относится к отдельной подгруппе SSL VPN, которые используют трафик практически не отличимый от HTTPS, что серьезно затрудняет выявление и блокирование таких туннелей.
На что следует обратить внимание при настройке? Давайте сначала посмотрим на окно настроек:
Как видим, появилась опция Port, где мы можем указать порт подключения, по умолчанию это 443, но можно использовать и любой иной, если 443 порт занят, например, веб-сервером. Также SSTP может прекрасно работать через прокси, в этом случае вам потребуется указать адрес прокси-сервера и используемый им порт в опциях Proxy и Proxy Port.
Также вспоминаем, что SSTP всегда использует шифрование канала, поэтому оно будет работать вне зависимости от выбранного профиля, в данном случае default и default-encryption будут работать одинаково.
Теперь перейдем к специфичным для протокола настройкам, которые мы обвели зеленой рамкой. Поле Certificate используется для указания клиентского сертификата в том случае, если сервер использует аутентификацию по сертификатам, в этом случае его потребуется загрузить на устройство и импортировать в разделе System — Certificates. Во всех остальных случаях в поле должно стоять none.
TLS Version указывает на допустимые к использованию версии TLS, однако это определяется сервером, но следует стараться использовать только протокол TLS 1.2, что позволяет исключить атаки с понижением протокола.
Опция Verify Server Certificate не является обязательной, но позволяет проверить подлинность сервера, исключая атаки типа человек посередине, для этого потребуется импортировать на Mikrotik сертификат центра сертификации (СА) выдавшего сертификат серверу.
Опция Verify Server Address From Certificate позволяет убедиться, что IP-адрес подключения соответствует адресу для имени, указанного в сертификате. Также не является обязательной, но позволяет дополнительно убедиться, что подключаетесь вы именно к тому серверу.
Установка флага в поле PFS включает совершенную прямую секретность, но эта опция должна поддерживаться со стороны сервера.
OpenVPN-клиент
Реализация OpenVPN в Mikrotik вызывает много нареканий, так как сводит на нет все сильные стороны данной технологии и делает ощутимыми слабые. OVPN-клиент не поддерживает сжатие данных и работу по протоколу UDP, если первое не столь значимо на современных каналах, то OpenVPN поверх TCP имеет очень большие накладные расходы и вызывает как повышенную нагрузку на оборудование, так и плохую утилизацию канала. Поэтому от использования OpenVPN на Mikrotik по возможности следует отказаться.
Обычно комплект для подключения OpenVPN клиента составляют сертификат СA, сертификат и закрытый ключ клиента, конфигурационный файл. Нам понадобятся только сертификат и ключ клиента, а если мы хотим проверять подлинность сервера, то еще и сертификат CA, но он не является обязательным для настройки подключения.
Прежде всего загрузим сертификаты и ключи на Mikrotik, затем перейдем в System — Certificates и импортируем сертификат клиента. Он появится в списке сертификатов и напротив него будет буква T, что обозначает trusted, т.е. устройство доверяет этому сертификату. Затем импортируем ключ, здесь важно соблюдать именно эту последовательность, сначала сертификат, потом ключ.
После успешного импорта ключа флаги сменятся на KT, где буква K обозначает наличие закрытого ключа для сертификата. Затем аналогичным образом импортируем сертификат CA сервера, импорт ключа для данного сертификата не нужен. Закрытый ключ CA является самой большой тайной и должен хранится с соблюдением всех мер предосторожности и не при каких обстоятельствах не должен покидать узел СA (центра сертификации).
Теперь рассмотрим поближе окно настроек подключения, адрес подключения и порт не должны вызвать затруднений, а вот остальные опции нуждаются в пояснении, значимые мы выделили зеленой рамкой.
Но сначала коснемся опций User и Profile. Первая используется только в случае аутентификации на сервере по имени и паролю, большинство OpenVPN серверов такой тип аутентификации не используют и в этом поле вы можете написать все что угодно, просто оно должно быть заполнено. Профиль также не имеет значения, так как OpenVPN всегда шифрует канал, а опцию сжатия игнорирует.
Mode задает режим работы канала, в терминах OpenVPN ip — это tun (L3), а ethernet — это tap (L2), следует помнить, что режим работы определяется сервером. В поле Certificate укажите импортированный сертификат клиента. Опции Auth и Cipher указывают на используемые сервером криптографические алгоритмы для аутентификации и шифрования, если вы укажете отличные от указанных в конфигурации сервера — то соединение установить не удастся. Если алгоритм аутентификации явно не указан в конфигурации сервера, то по умолчанию используется SHA1.
При настройке OpenVPN клиента на Mikrotik следует помнить, что сервер должен поддерживать соединения по протоколу TCP, без сжатия и TLS-аутентификации, в противном случае подключиться к серверу не удастся.
Опция Verify Server Certificate позволяет проверить подлинность сертификата сервера, что защищает от атак типа человек посередине, но требует импорта сертификата CA сервера.
Маршрутизация
Если VPN соединение используется для доступа к корпоративной сети или предназначено для связи сетей, то вам потребуется указать маршруты для правильной пересылки пакетов. Так если мы хотим получить доступ к сети за VPN-севером, то нам потребуется создать маршрут к этой сети, указав в качестве шлюза интерфейс нашего VPN-клиента, например так:
В данном примере мы отправляем все пакеты к сети 192.168.200.0/24 через L2TP-подключение l2tp-out1. Если вы понимаете основы маршрутизации, то указание правильных маршрутов для вас не составит труда.
Отдельного внимания заслуживает опция Pref. Source, которая не является обязательной, но ее следует указывать, если роутер обслуживает несколько сетей, в ней указывается адрес, с которого роутер будет посылать пакеты по указанному маршруту. Без ее указания доступ роутера к ресурсам удаленных сетей может оказаться невозможным (как и удаленных сетей к нему), на работу клиентов в сетях это не влияет. В качестве значения следует указать адрес, принадлежащий той сети, к которой имеется маршрут с противоположной стороны (т.е. сети за сервером).
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера
IPsec туннель на Linux машине будем поднимать с помощью racoon. Не буду описывать подробности, есть хорошая статья у vvpoloskin.
Устанавливаем необходимые пакеты:
Настраиваем racoon, он условно будет выступать в роли ipsec сервера. Так как mikrotik в main режиме не может передавать дополнительный идентификатор клиента, а внешний ip адрес через который он коннектится к Linux динамический, использовать preshared key (авторизацию по паролю) не получится, так как пароль должен сопоставляться либо с ip адресом подключающегося хоста, либо с идентификатором.
Будем использовать авторизацию по RSA ключам.
Демон racoon использует ключи в формате RSA, а mikrotik — в формате PEM. Если генерировать ключи утилитой plainrsa-gen идущей вместе с racoon, то конвертировать публичный ключ для Mikrotika в формат PEM с ее помощью не получится — она конвертирует только в одну сторону: PEM в RSA. Сгенерированный plainrsa-gen ключ не смогли прочитать ни openssl, ни ssh-keygen, поэтому с их помощью также не получится выполнить конвертацию.
Мы сгенерируем PEM ключ с помощью openssl, а затем конвертируем его для racoon с помощью plainrsa-gen:
Полученные ключи положим в папку: /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 нужно сконвертировать
и положить в папку /etc/racoon/certs не забыв про владельца и права.
Возвращаемся в раздел «IP» — «IPsec»
| Вкладка «Profiles» Параметр |
Значение |
|---|---|
| Name | На ваше усмотрение (по умолчанию default) |
| Hash Algorithm | sha512 |
| Encryption Algorithm | aes-128 |
| DH-Group | modp2048 |
| Proposhal_check | claim |
| Lifetime | 1d 00:00:00 |
| NAT Traversal | true (ставим галочку) |
| DPD | 120 |
| DPD Maximum failure | 5 |
| Вкладка «Peers» Параметр |
Значение |
|---|---|
| Name | На ваше усмотрение (далее MyPeer) |
| Address | 1.1.1.1 (IP linux машины) |
| Local Address | 10.0.0.2 (IP WAN интерфейса mikrotik) |
| Profile | default |
| Exchange Mode | main |
| Passive | false |
| Send INITIAL_CONTACT | true |
| Вкладка «Proposal» Параметр |
Значение |
|---|---|
| Name | На ваше усмотрение (далее MyPeerProposal) |
| Auth. Algorithms | sha512 |
| Encr. Algorithms | aes-128-cbc |
| Lifetime | 08:00:00 |
| PFS Group | modp2048 |
| Вкладка «Identities» Параметр |
Значение |
|---|---|
| Peer | MyPeer |
| Atuh. Method | rsa key |
| Key | mikrotik.privet.key |
| Remote Key | server-name.pub.pem |
| Policy Tamplate Group | default |
| Notrack Chain | пусто |
| My ID Type | auto |
| Remote ID Type | auto |
| Match By | remote id |
| Mode Configuration | пусто |
| Generate Policy | no |
| Вкладка «Policies — General» Параметр |
Значение |
|---|---|
| Peer | MyPeer |
| Tunnel | true |
| Src. Address | 192.168.0.0/30 |
| Dest. Address | 192.168.0.0/30 |
| Protocol | 255 (all) |
| Template | false |
| Вкладка «Policies — Action» Параметр |
Значение |
|---|---|
| Action | encrypt |
| Level | requier |
| IPsec Protocols | esp |
| Proposal | MyPeerProposal |
Скорее всего у вас, как и у меня, на WAN интерфейсе настроен snat/masquerade, это правило надо скорректировать, чтобы исходящие пакеты ipsec уходили в наш туннель:
Переходим в раздел «IP» — «Firewall».
Вкладка «NAT», открываем наше правило snat/masquerade.
| Вкладка «Advanced» Параметр |
Значение |
|---|---|
| IPsec Policy | out: none |
Рестартуем демона racoon
Если при рестарте racoon не запускается, значит в конфиге имеется ошибка, в syslog racoon выводит информацию о номере строки, в которой обнаружена ошибка.
Демон racoon при загрузке ОС стартует раньше поднятия сетевых интерфейсов, а мы указали в секции listen опцию strict_address, необходимо добавить в файл systemd юнита racoon
/lib/systemd/system/racoon.service, в секцию [Unit], строку After=network.target.
Сейчас наши ipsec туннели должны подняться, смотрим вывод:
Если туннели не поднялись, смотрите syslog, либо journalctl -u racoon.
Теперь необходимо настроить L3 интерфейсы, чтобы можно было маршрутизировать трафик. Есть разные варианты, мы будем использовать IPIP, так как его mikrotik поддерживает, я бы использовал vti, но, к сожалению, в mikrotik его до сих пор не реализовали. От IPIP он отличается тем, что дополнительно может инкапсулировать multicast и ставить метки (fwmark) на пакеты, по которым можно их фильтровать в iptables и iproute2 (policy-based routing). Если нужна максимальная функциональность — тогда, например, GRE. Но не стоит забывать, что за дополнительную функциональность платим большим оверхедом.
Перевод неплохого обзора туннельных интерфейсов можно посмотреть тут.
На Linux:
Теперь можно добавить маршруты для сетей за mikrotik
Чтобы наш интерфейс и маршруты поднимались после перезагрузки, нужно описать интерфейс в /etc/network/interfaces и там же в post-up добавлять маршруты, либо прописать все в одном файле, например, /etc/ipip-ipsec0.conf и дергать его через post-up, не забудьте про владельца файла, права и сделать его исполняемым.
На Mikrotik:
Раздел «Interfaces», добавляем новый интерфейс «IP tunnel»:
| Вкаладка «IP tunnel» — «General» Параметр |
Значение |
|---|---|
| Name | На ваше усмотрение (далее IPIP-IPsec0) |
| MTU | 1480 (если не указывать, то mikrotik начинает резать mtu до 68) |
| Local Address | 192.168.0.2 |
| Remote Address | 192.168.0.1 |
| Ipsec Secret | Деактивируем поле (иначе будет создан новый Peer) |
| Keepalive | Деактивируем поле (иначе интерфейс будет постоянно выключаться, так как у mikrotika какой-то свой формат этих пакетов и с linux не работает) |
| DSCP | inherit |
| Dont Fragment | no |
| Clamp TCP MSS | true |
| Allow Fast Path | true |
Раздел «IP» — «Addresses», добавляем адрес:
| Параметр | Значение |
|---|---|
| Address | 192.168.0.2/30 |
| Interface | IPIP-IPsec0 |
Теперь можно добавлять маршруты в сети за linux машиной, при добавлении маршрута, gateway будет наш интерфейс IPIP-IPsec0.
PS
Так как наш сервер linux является транзитным, то на нем имеет смысл задать параметр Clamp TCP MSS для ipip интерфейсов:
создаем файл /etc/iptables.conf со следующим содержимым:
и в /etc/network/interfaces
post-up iptables-restore < /etc/iptables.conf
В сети за mikrotik у меня работает nginx (ip 10.10.10.1), делаем доступным его из интернета, добавим в /etc/iptables.conf:
Не забывайте добавить соответствующие разрешения в iptables, если у вас включены фильтры пакетов.
Настройка VPN средствами IPsec Mikrotik
Стандарт IPsec создавался для обеспечения безопасности незащищенного протокола IP. Достигается это путем добавления собственных заголовков в оригинальный пакет для его инкапсуляции, т.е. сокрытия оригинального содержимого.
Не смотря на появление более новых протоколов, позволяющих организовать защищенный канал связи через сеть интернет, IPsec остается довольно популярным так как обладает довольно высокой степенью безопасности и хорошей производительностью.
Чтобы правильно настроить VPN с помощью IPsec, необходимо понимать базовые принципы.
Принципы работы протокола IPsec и базовые термины
IPsec — это набор протоколов, которые можно разделить на следующие основные группы:
- Internet Key Exchange (IKE) — протоколы, которые генерируют и раздают ключи шифрования для AH и ESP;
- Authentication Header (AH) — протокол заголовка аутентификации, предназначен для проверки целостности передаваемого пакета данных (защита от изменения содержимого пакета или подмены исходного адреса);
- Encapsulating Security Payload (ESP) — защищенный протокол инкапсуляции данных, обеспечивает непосредственную защиту данных путем шифрования на общих ключах, а также имеет собственную схему аутентификации подобную AH;
IPsec может работать в двух режимах: транспортном и туннельном:
- В транспортном режиме, ESP-заголовок вставляется между IP-заголовком и полезными данными оригинального пакета, а в конец добавляется ESP-трейлер и ESP-аутентификация. Шифруются только полезные данные и ESP-трейлер. Транспортный режим может быть использован для защиты туннелей, организованных иным способом (например L2TP).
- В туннельном режиме, оригинальный ip-пакет инкапсулируется в новый и таким образом шифруется весь исходный пакет. Туннельный режим используется для создания VPN.
При создании туннеля создается связь, которая называется SA (Security Association).
Каждая связь SA создается для однонаправленного соединения. Так как данные необходимо передавать в двух направлениях, то SA создаются парами. Одна пара SA создается для протокола AH, другая для ESP. Созданные SA хранятся в базе данных узлов (роутеров Mikrotik), которые создают туннель.
Если на узле создалась SA — значит VPN туннель успешно установлен.
На каждом узле имеется база данных политики безопасности (Security Policy Database).
Политики содержат следующие настройки:
- алгоритмы шифрования/дешифрования;
- способы идентификация узла: pre-shared keys или RSA-сертификат;
- как часто повторять идентификацию узла и менять ключ шифрования;
- использовать режим туннеля или транспорта;
- контрольные суммы целостности данных;
- использовать AH, ESP или оба;
- опция PFS и выбор группы Deffie Hellman.
Установка соединения IPsec происходит в два этапа: Phase 1 и Phase 2.
Первоначальная аутентификация сторон и обмен общими секретными ключами происходит с помощью протокола IKE. Процесс работы протокола IKE состоит из двух этапов:
Phase 1
Узлы согласовывают алгоритмы для последующего обмена информацией и аутентифицируются. Происходит обмен общими ключами по алгоритму Deffie Hellman. В результате создается безопасный канал IKE SA.
Phase2
Генерируются ключи шифрования IPsec, согласовываются политики. В результате создается соединение IPsec SA
В новой версии протокола IKEv2 процесс происходит за одну фазу в несколько шагов.
Site-to-Site туннель: создание постоянного VPN IPsec
Site-to-site туннель позволяет создать постоянный защищенный канал VPN между двумя офисами через интернет. Каждый офис имеет свою локальную сеть и нуждается в доступе к локальной сети другого офиса.
Адреса 10.1.100.1 и 10.2.100.1 в реальности не относятся к публичным ip-адресам и не используются в сети интернет.
Нормальной работе IPsec туннеля могут препятствовать правила NAT и Fasttrack. Это необходимо учесть и создать правила обхода перед настройкой VPN или после.
Обход NAT и Fasttrack
Без обхода NAT и Fasttrack туннель IPsec не будет работать!
Правила трансляции в NAT (masquerade) меняют адрес источника и роутер не сможет зашифровать пакет с адресом источника отличающимся от заданного в политике IPsec. Это приведет к тому, что сетевой траффик не будет проходить через туннель и пакеты будут теряться.
Правило обхода NAT помогает решить эту проблему.
Правило должно находиться выше всех остальных правил в таблице NAT.
Если на роутере используется Fasttrack, то это тоже сломает работу IPsec так как пакеты будут обходить политики IPsec. Для решения этой проблемы добавьте разрешающие правила accept перед Fasttrack.
Нужно на обоих роутерах разрешить прохождение транзитного трафика в двух направлениях — из сети офиса 1 в сеть офиса 2 и в обратном направлении:
На картинке ниже пример правила для трафика из сети Офиса 1 в сеть Офиса 2. Правило для обратного направления трафика будет отличаться адресами Src. Address 192.168.2.0/24 и Dst. Address 192.168.1.0/24
Однако создание правил в таблице Filter сможет существенно повысить нагрузку на CPU в случаях, когда используется множество туннелей и передается значительное количество траффика. В такой ситуации лучше не использовать таблицу Filter для правил обхода, а создать их в IP/Firewall/RAW. Это позволит не отслеживать соединения и исключить обработку находящихся выше правил , что приведет к снижение нагрузки на CPU.
После добавление правил на обоих роутерах, в таблице RAW должны присутствовать следующие правила:
Настройка IPsec на роутере офиса №1:
1. Настройте Profile для фазы 1
Профили определяют набор параметров, которые будут использованы для согласования IKE в фазе 1.
dh-groupe — выбор группы Deffie Hellman
enc-algoritn — алгоритм шифрования
name — имя профиля
При выборе алгоритма шифрования следует учитывать влияние на производительность канала. Если скорость канала важна для вас — выбирайте алгоритмы, которые Mikrotik поддерживает аппаратно. На wiki Mikrotik есть таблица.
2. Настройте Proposal для фазы 2
Proposal или предложение — информация, которая будет отправлена сервисами IKE, чтобы установить соединения SA по определенным политикам.
auth-algorithms — алгоритм аутентификации;
enc-algorithms — алгоритм шифрования;
name — имя политики (указывайте такое же как в профиле, чтобы было понятно к какому профилю относится политика);
pfs-group (Perfect Foorward Security) — генерирует дополнительные сессионные ключи на основе ключей сторон и согласует их по алгоритму Деффи Хеллмана (даже если общий ключ будет перехвачен, то трафик им расшифровать не получится).
3. Добавьте Peer
Здесь указывается информация необходимая для установки соединения между демонами IKE двух узлов. Затем это соединение будет использовано для согласования ключей и алгоритмов для соединений SA.
address — публичный адрес удаленного роутера
name — любое понятное имя
profile — профиль используемый для соединения
Для работы IPsec должны быть доступны порты UDP/4500 (IPsec NAT traversal) и UDP/500 (IKE). Проверьте файрволл, чтобы не было правил, блокирующих трафик на эти порты.
4. Создайте Identity — секретная фраза для идентификации.
Выберите Peer и укажите секретный идентификатор Secret. Чем сложнее Secret тем лучше, поэтому для его создания лучше воспользоваться генератором пароля.
5. На завершающем этапе создайте Policy (Политику), которая контролирует сети/хосты защищенного канала.
src-address — адрес сети источника (офиса 1)
dst-address — адрес сети назначения (офиса 2)
src-port — порт источника (any — все порты)
dst-port — порт назначения
tunnel — туннельный режим
action — что делать с пакетами (encrypt — шифровать)
proposal — какое применять предложение
peer — с каким узлом устанавливать соединение
Конфигурация IPsec для роутера офиса №2:
Конфигурация второго узла идентична первому, с соответствующими ip-адресами. Последовательность настройки выполняйте в таком же порядке.
VPN IPSec (site-to-site) между виртуальными роутерами Mikrotik за NAT Traversal (NAT-T)¶
Рассмотрим настройку, VPN соединение «site-to-site» как показано ниже. Два удаленных виртуальных маршрутизатора Mikrotik подключены к публичной сети Интернет, через промежуточный сетевой узел — роутер провайдера. Таким образом оба роутера Mikrotik находятся за NAT-T. Статья содержит примеры конфигурации оборудования через консоль, а также через графический интерфейс управления (GUI) (winbox ).
Рабочие станции, а также существующая инфраструктура также находятся за NAT. Каждая сторона Site «A» и Site «B» имеет свою собственную приватную подсеть:
- 10.10.10.0/24 для Site «A»
- 10.5.4.0/24 для Site «B»
- Версия маршрутизаторов Mikrotik: RouterOS 6.41.2 stable (CHR).
- Версия WinBox: 3.18.
В зависимости от версии ОС роутера или программного обеспечения, дальнейшая настройка могут отличаться.
Для установления VPN-соединения необходимо обеспечить выполнения обязательных условий:
Сетевая доступность между маршрутизаторами:
- Protocol: UDP, port 500 (for IKE, to manage encryption keys).
- Protocol: UDP, port 4500 (for IPSEC NAT-Traversal mode).
- Protocol: ESP, value 50 (for IPSEC).
- Protocol: AH, value 51 (for IPSEC).
Правила фаерволов не должны блокировать сетевой трафик между маршрутизаторами и приватными подсетями.
Приватные подсети, которые будут соединяться средствами IPSec, должны быть разными, а также не включать в себя друг друга.
| Client vRouter | Floating IP | VPC-Network IP | Private Network IP |
| Site «A» Mikrotik #1 | 156.67.54.238/32 | 172.16.0.12/32 | 10.10.10.1/32 |
| Site «B» Mikrotik #2 | 156.67.54.143/32 | 172.16.0.15/32 | 10.5.4.11/32 |
В данном примере будет выполнена первоначальная настройка защищенного VPN соединения IPSec «site-to-site», тем самым соединим приватные сети 10.10.10.0/24 и 10.5.4.0/24, которые находятся за маршрутизаторами.
Конфигурация Site «A»
1-A. Выполняем настройку IPsec peer. На этом этапе необходимо настроить параметры:
- address (адрес удаленного пира — роутера),
- auth-method (метод аутентификации),
- secret (секретное слово),
- my-id (мой идетнитфикатор).
Остальные параметры оставляем по умолчанию, без изменений. Рассмотрим, как выполнить эту настроку из консоли:
Проверяем внесенные изменения:
Как видно из вывода команды «ip ipsec peer print», параметры применились корректно. Теперь рассмотрим как эти же настройки применить через графический интерфейс управления роутером:
2-A. Для следующих шагов важно, чтобы предложенные алгоритмы аутентификации и шифрования совпадали на обоих маршрутизаторах. В этом примере мы будем использовать настройки параметров «по умолчанию». Чтобы просмотреть и проверить настройки параметра «proposal» выполняем команду «ip ipsec proposal print»:
3-A. Задаем policy (полтитики) для IPSec:
Проверяем внесенные изменения в параметры «policy»:
Как видно из вывода команды «ip ipsec policy print», параметры применились корректно. Теперь рассмотрим как эти же настройки применить через графический интерфейс управления роутером:
После того как мы выполнили предыдущие 3 шага по настройке маршрутизатора на стороне «A», переходим к настройке роутера на стороне «B».
Конфигурация Site «B»
1-B. Настройка параметров «IPsec peer» для Site «B» практически идентична конфигурации Site «A», отличаются только два параметра: IP-адрес удаленного пира — «address» и свой идентификатор — «my-id».
Выполнить эту настроку из консоли:
Проверяем внесенные изменения:
Как видно из вывода команды «ip ipsec peer print», параметры применились корректно. Теперь рассмотрим как эти же настройки применить через графический интерфейс управления роутером:
2-B. Проверяем, что параметры «proposal» созданы по умолчанию и совпадают параметрами роутера на стороне «A»:
Рузультаты вывода команд «ip ipsec proposal print» совпадают на обоих роутерах, между которыми будет создан туннель.
3-B. Cоздадим политики IPsec на стороне «B»:
Проверяем внесенные изменения в параметры «policy»:
Как видно из вывода команды «ip ipsec policy print», параметры применились корректно. Теперь рассмотрим как эти же настройки применить через графический интерфейс управления роутером:
После того, как будут корректно выполнены шаги «1-A»-«3-A» и «1-B»-«3-B», туннель должен установиться и на обоих маршрутизаторах должны быть созданы две ассоциации безопасности .
Для проверки установления VPN-соединения на обоих маршрутизаторах необходимо поочередно выполнить команды «ip ipsec remote-peers print» и «ip ipsec installed-sa print».
Из результата вывода выполнения команды «ip ipsec remote-peers print» видно, что соединение установилось (STATE — established). При этом флаг «N» показывает, что удаленный пир находится за NAT.
Правила «обхода» NAT
На этом этапе, если отправить трафик через туннель IPsec, он не будет работать, пакеты будут потеряны. Это связано с тем, что оба маршрутизатора имеют правила NAT (маскарад), которые изменяют адрес источника перед шифрованием пакета. Маршрутизатор не может зашифровать пакет, поскольку адрес источника не совпадает с адресом, указанным в конфигурации политики. Для получения дополнительной информации см. Пример потока пакетов IPsec.