Pfs group mikrotik что это

Записки 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

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Mikrotik + IPSec + Cisco. Часть 2. Тоннель на «сером» IP

В продолжение к посту.
В прошлый раз я рассматривал соединение, когда со стороны циски и микрота были реальные IP’ы.
Здесь рассмотрю пример «серого реальника», т.е серый IP, который провайдер маскирует у себя под внешний с безусловной переадресацией (binat).

Техническая задача: организовать ipip-тоннель между офисами, с шифрованием ipsec, при помощи Mikrotik RB450G и Cisco 2821.

Ньюансы

на циске внешний IP, а на микротике серый, который маскируется провайдером под внешний, с безусловной переадресацией (обращения к этому внешнику из интернета редиректятся на интерфейсный, серый «IP»).
Схема:

Исходные данные

Cisco 2821 (OS v12.4)
2. Mikrotik RB450G
3. Реальные внешние IP на обоих устройствах
4. Адрес циски: 77.77.77.226. Подсеть со стороны циски: 10.192.0.0/22
5. Адрес микротика: 99.99.99.2. Подсеть со стороны микротика: 192.168.100.0/24
6. Серый адрес микротика на внешнем интерфейсе: 172.16.99.2.

Предыстория

При подключении нового филиала обнаружил, что провайдер (единственный местный) вместо внешнего IP выдал мне «серый».
На моё законное возмущение, что по договору нам должны дать внешний адрес — провайдер ответил, что внешний для нас сделан средствами nat’а, и все обращения из интернета на этот внешник редиректятся на наш «серый» ip, и по другому они ничего сделать не могут.
На этом наш разговор окончился, и я стал настраивать тоннель. Тоннель не завёлся 🙂
Ситуация неоднозначная. С одной стороны вроде и внешник, который на деле выглядит «серым», но и NAT-T использовать смысла нет
Около часа я мучал микротик с циской, в результате получилась странная, но работоспособная конструкция (кстати попробовал её повторить на racoon под freebsd — не взлетело).

Что получилось в итоге

На циске создал тунель, в котором указал серый ip микротика в destination.

Все настройки (консольные и аналогичные графические) привожу ниже.

Cisco:

Микротик:

Этот же конфиг, глазами WinBox:
1. Интерфейсы-IP Tunnel. Добавить:

2. В разделе IP-IPSec-Proposals в дефолтном правиле ОБЯЗАТЕЛЬНО сменить SHA1 на MD5, т.к в рассматриваемом примере используется MD5.

3. IP-IPSec-Peers. Добавить:

4. IP-Routes. Добавить:

VPN IPSec/L2TP на Mikrotik за 5 минут

Иногда мне кажется, что создатели Mikrotik намеренно лишают себя прибыли, не создавая однозначных пошаговых руководств по настройке своих детищ. Почти 100% потребителей этих роутеров пытаются настроить VPN, использовать два или более WAN одновременно или в качестве резервных. Именно это ищут по всей сети (и часто вне рунета) счастливые владельцы этих замечательных устройств. Представьте, на сколько бы увеличилась армия владельцев, если бы для настройки этих функций было два-три визарда в веб-интерфейсе. А сейчас.. сейчас именно благодаря сложности настройки (и, соотв., меньшему количеству желающих купить) мы имеем недорогое, малокапризное для несложных задач устройство, которое надо заставить работать 24х7х365. Например, в качестве VPN-сервера. Поехали!

Протокол L2TP обеспечивает канал передачи данных, туннель.

IPSec обеспечивает защиту данных от просмотра.

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

Примечание 1: я не очень люблю текстовые команды с кучей ключей при настройке вещей, которые достаточно много где описаны, но описаны каждый раз с незаметными опечатками, где-то что-то не скопировалось при написании (или при копировании с другого сайта, что случается чаще всего) или просто съелось текстовым редактором CMS сайта. Настройка VPN как раз такой случай. Поэтому я специально каждый шаг прописал для GUI Mikrotik — Winbox, тем более что не так уж тут и много всего надо сделать.

Примечание 2: до версии 6.18 в прошивке есть баг, из-за которого всегда применяется default policy template, поэтому обновите прошивку до последней стабильной. Не обновляйте прошивку до самой последней, но нестабильной версии, если вы настраиваете VPN.

Итак, имеем роутер Mikrotik с прошивкой 6.30 (июль 2015) c LAN 192.168.88.0/24 (сеть по-умолчанию). WAN не важен, например, 1.2.3.4.

Настройка туннелирования (L2TP)

1. IP — Pool / Определям диапазон адресов VPN-пользователей

Name: vpn_pool
Addresses: 192.168.112.1-192.168.112.10
Next pool: none

Лучше для клиентов vpn использовать отдельную адресацию. Так проще отделять одних от других. И вообще, бест практис.

2. PPP — Profiles / Профиль для нашего конкретного туннеля

General:
Name: l2tp_profile
Local address: vpn_pool (а можно указать 192.168.88.1, сами смотрите, как вам больше нравится)
Remote address: vpn_pool
Change TCP MSS: yes

Protocols:
all to default:
Use MPLS: default
Use compression: default
Use Encription: default

Limits:
Only one: default

3. PPP — Secrets / Готовим пользователя VPN

Name: vpn_user1
Password: bla-bla-bla
Service: l2tp
Profile: l2tp_profile

4. PPP — Interface — клик на L2TP Server / Включаем сервер L2TP

Enabled — yes
MTU / MRU — 1450
Keepalive Timeout — 30
Default profile — l2tp_profile
Authentication — mschap2
Use IPSec — yes
IPSec Secret: tumba-yumba-setebryaki (это не пароль пользователя, а предварительный ключ, который надо будет указывать на клиентах в дополнение к логину/паролю)

Настройка шифрования данных в «туннеле» (IPSec)

На предыдущем этапе мы создали туннель для передачи данных и включили IPSec. В этом разделе мы настроим параметры IPSec.

5. IP — IPSec — Groups

Т.к. велика вероятность появления ошибки соединения с сервером из-за дефолтной группы, просто удалим и тут же создадим ее. Например, с именем «policy_group1». Также можно просто удалить эту группу, но через веб-интерфейс будут показываться ошибки.

6. IP — IPSec — Peers

Address: 0.0.0.0/0
Port: 500
Auth method: pre shared key
Passive: yes (set)
Secret: tumba-yumba-setebryaki (это не пароль пользователя!)

Policy template group: policy_group1
Exchange mode: main l2tp
Send Initial Contact: yes (set)
NAT Traversal: yes (set)
My id: auto
Proposal check: obey
Hash algorithm: sha1
Encryption Algorithm: 3des aes-128 aes-256

DH Group: modp 1024
Generate policy: port override
Lifitime: 1d 00:00:00
DPD Interval: 120
DPD Maximum failures: 5

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 похожи, а если еще добавить, что один и тот же Secret мы добавляли и пункте 4 и пункте 6, то возникает вопрос: почему одни и те же опции повторно настраиваются? Ответ у меня такой: чисто из практики вышло, что Windows 7 требовал одного, а iPhone — другого. Как так работает, не знаю. Но факт чисто из практики. Например, изменяю в Proposal PFS Group на 2048 — Windows нормально коннектиться, а iPhone перестает. Делаю наоборот (в proposal ставлю 1024, а в ip-ipsec-peers ставлю 2048) — iPhone коннектиться, а Windows — нет 🙂 Т.е. при подключении разных клиентов используются разные части конфигов. Бред? Может быть, это следствие постепенных изменений в конфигурацию VPN сервера, не могу сказать, т.к. может иметь место даже влияние старых прошивок, конфигов и др. Я не исключаю, что что-то здесь избыточно, но что именно, не знаю.

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 (последнее правило для forward «chain=forward action=drop»), вам может быть необходимым разрешить forward с ip-адресов vpn_pool в локальную сеть:

add chain=forward action=accept src-address=192.168.112.0/24 in-interface=!ether1 out-interface=bridge-local comment=»allow vpn to lan» log=no log-prefix=»»

Вот теперь с сервером все.

Подключение удаленного клиента

Пробуем подключить Windows 7:

Панель управленияСеть и ИнтернетЦентр управления сетями и общим доступом:
Настройка нового подключения или сети
Подключение к рабочему месту
Создать новое подключение
Использовать мое подключение к интернету (VPN)
Интернет-адрес: ip или имя роутера в сети
Пользователь и пароль из PPP->Secrets. В нашем случае это vpn_user1 и его пароль.

Если не выходит, или просто надо настроить созданное подключение:

Тип VPN: L2TP IPSec VPN

Дополнительные параметры: для проверки подлинности использовать предварительный ключ. В нашем случае это «tumba-yumba-setebryaki» (IP — IPSec — Peers):

Здесь же, в группе «Проверка подлинности», оставляем только CHAP v2:

Жмем ОК и пытаемся подключиться. Должно получиться. Если нет, загляните на страницу ошибок при настройке VPN.

Update 1: часто люди интересуются, как несколько (больше одного) клиентов из одной локальной сети (за nat) могут подключаться к одному удаленному vpn-серверу микротик. Не знаю, как в L2TP/IPSec связке это обеспечить. Можно назвать это багом реализации. Я не нашел простого объяснения и решения проблемы.