Данная статья является результатом нескольких лет изучения, тестирования и внедрения VPN на оборудовании MikroTik на основе чистого IPsec IKEv2 между несколькими сетями с динамической маршрутизацией. Используя данный метод можно выстроить связную структуру сети с достаточным количеством степеней свободы и масштабирования. Опционально возможно использование агрегации каналов, что позволяет добиться быстрого переключения в случает падения канала и относительно высокой доступности.
Ниже будет представлено большое количество информации, разбитое на блоки в порядке внедрения.
Общая схема и технические подсети
Сертификаты
IPsec-туннели
EoIP-туннели
OSPF и фильтры
Общая схема и технические подсети
Все действия данной статьи производятся в ROS v6.49.2. Подразумевается, что первоначальная настройка оборудования произведена.
Технически общая схема выглядит следующим образом: роутер R2 (инициатор) устанавливает IPsec IKEv2 туннель c роутером R1 (ответчик) с использованием сертификатов, поверх него устанавливается EoIP-туннель с 30 маской для работы протокола динамической маршрутизации OSPF. Почему именно EoIP - будет объяснено ниже. Статический IP-адрес должен быть только у R1. За сертификаты также отвечает R1.
Прежде чем приступать к конфигурированию, необходимо определиться с техническими подсетями для IPsec- и EoIP-туннелей. Вы можете использовать любые частные адреса, но есть одна хитрость: последний октет IP-адреса концов туннелей совпадают у инициатора и ответчика соответственно. Вот что я имею ввиду:
Роутер | IPsec | EoIP |
172.16.0.0/30 | ||
R1 | 10.0.0.1 | 172.16.0.1/30 |
R2 | 10.0.0.2 | 172.16.0.2/30 |
172.16.0.3/30 |
Можно использовать классические 192.168.ХХ.ХХ. Это повлияет только на фильтрацию OSPF. Когда с планированием будет окончено, можно приступать к следующему пункту.
Сертификаты
MikroTik очень расслабленно относится к использованию сертификатов, отсутствие необходимых OID'ов для него не проблема. Как это влияет на конечный результат - предположить сложно, поэтому делать будем изначально хорошо и по RFC5280.
Немного теории о полях Key Usage
Для начала необходимо определиться с полями Key Usage выпускаемых сертификатов:
Key Usage | Значение (Оригинал) | Значение (Перевод) |
Digital signature | Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity. | Используется, когда открытый ключ используется с механизмом цифровой подписи для поддержки служб безопасности, отличных от неотрекаемости, подписания сертификата или подписания CRL. Цифровая подпись часто используется для аутентификации объекта и аутентификации источника данных с сохранением целостности. |
Non-repudiation - он же Content commitment | Use when the public key is used to verify digital signatures used to provide a non-repudiation service. Non-repudiation protects against the signing entity falsely denying some action (excluding certificate or CRL signing). | Используется, когда открытый ключ применяется для проверки цифровых подписей, используемых для предоставления услуги без отказа. Неотрекаемость защищает от того, что подписывающий субъект ложно отвергнет какое-либо действие (исключая подписание сертификата или CRL). |
Key encipherment | Use when a certificate will be used with a protocol that encrypts keys. An example is S/MIME enveloping, where a fast (symmetric) key is encrypted with the public key from the certificate. SSL protocol also performs key encipherment. | Используется, когда сертификат будет применяться с протоколом, который шифрует ключи. Примером может служить обертывание S/MIME отправление, где быстрый (симметричный) ключ шифруется открытым ключом из сертификата. Протокол SSL также выполняет шифрование ключей. |
Data encipherment | Use when the public key is used for encrypting user data, other than cryptographic keys. | Используется, когда открытый ключ используется для шифрования пользовательских данных, кроме криптографических ключей. |
Key agreement | Use when the sender and receiver of the public key need to derive the key without using encryption. This key can then can be used to encrypt messages between the sender and receiver. Key agreement is typically used with Diffie-Hellman ciphers. | Используется, когда отправителю и получателю открытого ключа необходимо получить ключ без использования шифрования. Затем этот ключ можно использовать для шифрования сообщений между отправителем и получателем. Согласование ключей обычно используется с шифрами Диффи-Хеллмана. |
Certificate signing - он же key cert. sign | Use when the subject public key is used to verify a signature on certificates. This extension can be used only in CA certificates. | Используется, когда открытый ключ субъекта используется для проверки подписи на сертификатах. Это расширение можно использовать только в сертификатах CA. |
CRL sign | Use when the subject public key is to verify a signature on revocation information, such as a CRL. | Используется, когда открытый ключ субъекта предназначен для проверки информации об отзыве, такой как CRL. |
Encipher only | Use only when key agreement is also enabled. This enables the public key to be used only for enciphering data while performing key agreement. | Используется только тогда, когда также включено согласование ключей. Это позволяет использовать открытый ключ только для шифрования данных при согласовании ключей. |
Decipher only | Use only when key agreement is also enabled. This enables the public key to be used only for deciphering data while performing key agreement. | Используется только тогда, когда также включено согласование ключей. Это позволяет использовать открытый ключ только для расшифровки данных при согласовании ключей. |
Остальные параметры относятся в так называемым Extended Key Usage. Ниже дано описание этих ключей.
Дополнительная информация
Расширенное использование ключа дополнительно уточняет расширения использования ключа. Расширенный ключ является критическим или некритическим. Если расширение критично, сертификат должен использоваться только для указанной цели или целей. Если сертификат используется для другой цели, это нарушает политику ЦС.
Если расширение не является критическим, оно указывает на предполагаемую цель или цели ключа и может использоваться для поиска правильного ключа / сертификата объекта, имеющего несколько ключей / сертификатов. В этом случае расширение является только информационным полем и не означает, что CA ограничивает использование ключа указанной целью. Тем не менее, приложения, использующие сертификаты, могут потребовать указания конкретной цели, чтобы сертификат был приемлемым.
Если сертификат содержит как критическое поле использования ключа, так и поле критического расширенного использования ключа, оба поля должны обрабатываться независимо, а сертификат должен использоваться только для цели, совместимой с обоими полями. Если в обоих полях нет цели, сертификат нельзя использовать ни в каких целях.
Extended Key Usage | Применимо для Key Usage |
dvcs (Data Validation and Certification Server RFC3029) | Digital signature, non-repudiation, Certificate signing, CRL sign |
server gated crypto | нет данных |
ocsp sign | Digital signature and/or non-repudiation. |
Timestamp | Digital signature and/or non-repudiation. |
IPsec user | Digital signature and/or key encipherment or key agreement |
IPsec tunnel | Digital signature and/or key encipherment or key agreement |
IPsec end system (host or router) | Digital signature and/or key encipherment or key agreement |
Email protect | Digital signature, non-repudiation, and/or (key encipherment or key agreement) |
Sign (downloadable) executable code - он же Code sign | Digital signature |
TLS client | Digital signature and/or key agreement |
TLS server |
|
Перед выполнением всех операций и в дальнейшем необходимо актуальное время на обоих роутерах R1 и R2.
/system ntp client set server-dns-names=ru.pool.ntp.org enabled=yes
Как было указано выше, в данном случае в качестве центра сертификации используется одно из сетевых устройств. Итак, для схемы необходимы 3 сертификата: CA (Certificate Authority), ответчик (серверный) и инициатор (клиентский).
Для создания CA достаточно выполнить команду на R1:
:global certca "ca"
/certificate add name=$certca key-size=4096 common-name=$certca key-usage=key-cert-sign,crl-sign days-valid=5890
/certificate sign [find where name=$certca]
Максимальное дата действия сертификатов - 2038-01-18. В случае удаления сертификата СА автоматически удаляются все зависящие от него сертификаты. Еще одни немаловажным фактором являются списки отзыва (CRL). Без этой опции даже отозванный сертификат может успешно пройти аутентификацию.
/certificate settings edit crl-use
И вручную вписать "yes". Хранить ли списки отзывали в ОЗУ или на флеш - зависит от вашего устройства.
Для облегчения генерации сертификатов в командах используются переменные. Замените значения на необходимые, либо оставьте как есть.
Выпуск сертификата для ответчика на R1:
:global certserver "server"
/certificate add name=$certserver key-size=4096 common-name=$certserver key-usage=digital-signature,key-encipherment,key-agreement,ipsec-tunnel days-valid=3650 subject-alt-name=IP:1.1.1.1
/certificate sign [find where name=$certserver] ca=$certca once do={}
:delay 130
/certificate export-certificate [find where name=$certserver] type=pem file-name=$certserver
Выпуск сертификата для инициатора на R1:
:global certclient "client"
/certificate add name=$certclient key-size=4096 common-name=$certclient key-usage=digital-signature,key-encipherment,key-agreement,ipsec-tunnel days-valid=3650
/certificate sign [find where name=$certclient] ca=$certca once do={}
:delay 130
/certificate export-certificate [find where name=$certclient] type=pkcs12 export-passphrase=12345678 file-name=$certclient
Перенесите получившиеся сертификаты на инициатор R2 и импортируйте (не забудьте удалить после):
:global certclient "client"
:global certserver "server"
/certificate import file-name=$certclient name=$certclient passphrase=12345678
/certificate import file-name=$certserver name=$certserver passphrase=""
IPsec-туннели
Прежде чем приступать непосредственно к настройке, убедитесь, что у R1 и R2 у NAT правила MASQUARADE (или SRC-NAT, зависит от вашей инсталляции) присутствует параметр ipsec-policy=out,none. Данный параметр позволяет не создавать лишних правил в NAT.
Также необходимо для ответчика R1 открыть набор портов и протоколов:
/ip firewall filter
add action=accept chain=input dst-port=500,4500 in-interface-list=WAN protocol=udp place-before=0
add action=accept chain=input in-interface-list=WAN protocol=ipsec-esp place-before=0
Для понимания общей концепции, ниже представлена схема меню IPsec внутри Mikrotik.
Процесс построения политики IPsec
Здесь важное замечание: НЕ УДАЛЯЙТЕ И НЕ МЕНЯЙТЕ ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ (синие). На них завязаны многие внутренние сервисы роутера. Производите манипуляции с ними, только если вы отдаете себе отчет в том, что делаете.
Еще одна особенность - поддержка аппаратного шифрования, от этого зависит выбор алгоритмов аутентификации и шифрования. Обращайте внимание на звездочки.
Для создания IKEv2 ответчика на R1 выполните:
ip ipsec policy group add name=IKEv2
/ip ipsec proposal add name=SHA256 auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=00:30:00 pfs-group=modp4096
/ip ipsec mode-config add name=client responder=yes address=10.0.0.2 system-dns=no
/ip ipsec profile add name=SHA256 hash-algorithm=sha256 prf-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp4096 lifetime=12:00:00 dpd-interval=15
/ip ipsec peer add name=local local-address=1.1.1.1 profile=SHA256 exchange-mode=ike2 passive=yes send-initial-contact=no
/ip ipsec identity add peer=local auth-method=digital-signature certificate=$certserver remote-certificate=$certclient policy-template-group=IKEv2 notrack-chain=prerouting match-by=certificate mode-config=client generate-policy=port-strict
/ip ipsec policy add template=yes group=IKEv2 protocol=255 action=encrypt ipsec-protocols=esp proposal=SHA256
/interface bridge add name=IPsec protocol-mode=none
/ip address add address=10.0.0.1 interface=IPsec
Последние два действия присутствуют только для того, чтобы на роутере R1 приземлить IPsec-интерфейс. На R2 такую процедуру выполнять не нужно.
На инициаторе R2 выполните:
/ip ipsec policy group add name=IKEv2
/ip ipsec proposal add name=SHA256 auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=00:30:00 pfs-group=modp4096
/ip ipsec profile add name=SHA256 hash-algorithm=sha256 prf-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp4096 lifetime=12:00:00 dpd-interval=15
/ip ipsec peer add name=server address=1.1.1.1 profile=SHA256 exchange-mode=ike2 passive=no send-initial-contact=yes
/ip ipsec identity add peer=server auth-method=digital-signature certificate=$certclient remote-certificate=$certserver policy-template-group=IKEv2 notrack-chain=prerouting match-by=certificate mode-config=request-only generate-policy=port-strict
/ip ipsec policy add template=yes group=IKEv2 protocol=255 action=encrypt ipsec-protocols=esp proposal=SHA256
На этом настройка IPsec окончена. Для проверки доступности другого конца туннеля можете использовать ping. При необходимости измените необходимые параметры.
Выполните /ip ipsec installed-sa print. Если вы видите флаги H перед записями, значит аппаратное шифрование работает.
На каждую точку подключения генерируйте отдельный сертификат. Да, лишние действия, но это убережет от дальней поездки в случае отзыва сертификата.
EoIP-туннели
Можно было бы обойтись без этих интерфейсов, но они необходимы для работы OSPF, а также для более интересных вещей: если у вас два и более каналов связи, то EoIP можно объединить в Bond с широкими возможностями настройки и отказоустойчивости.
Итак, для создания интерфейса на R1:
/interface eoip add name=EoIP-Tunnel local-address=10.0.0.1 remote-address=10.0.0.2 tunnel-id=1
/ip address add address=172.16.0.1/30 interface=EoIP-Tunnel
На R2:
/interface eoip add name=EoIP-Tunnel local-address=10.0.0.2 remote-address=10.0.0.1 tunnel-id=1
/ip address add address=172.16.0.2/30 interface=EoIP-Tunnel
tunnel-id должны совпадать. Если вы используете winbox, то при создании EoIP-интерфейсов не копируйте их! При копировании сохраняется MAC, а не генерируется новый.
Теперь трафик ходит внутри туннеля поверх IPsec.
OSPF и фильтры
Но просто туннелей мало. Нужна еще маршрутизация, желательно динамическая.
Поэтому на R1 выполните:
/routing ospf network add network=172.16.0.0/24 area=backbone
/routing ospf network add network=192.168.1.0/24 area=backbone
/routing ospf instance set router-id=192.168.1.1 redistribute-connected=as-type-1 [find where name=default]
/routing ospf interface add copy-from=[find where interface=EoIP-Tunnel] use-bfd=yes network-type=point-to-point
/routing ospf interface add copy-from=[find where interface=bridge] passive=yes
На R2:
/routing ospf network add network=172.16.0.0/24 area=backbone
/routing ospf network add network=192.168.2.0/24 area=backbone
/routing ospf instance set router-id=192.168.2.1 redistribute-connected=as-type-1 [find where name=default]
/routing ospf interface add copy-from=[find where interface=EoIP-Tunnel] use-bfd=yes network-type=point-to-point
/routing ospf interface add copy-from=[find where interface=bridge] passive=yes
Последняя команда запрещает вещание OSPF в бридж.
Чем отличаются типы, какие маршруты можно передавать и далее, вы можете прочитать в документации. Эта тема обширна и в приемлемом виде подается на MTCRE.
Теперь, когда OSPF настроен, роутеры обмениваются маршрутами, но в том числе и техническими. А что делать когда их десятки и сотни? Кроме них есть еще и сети провайдеров, которыми тоже не нужно обмениваться.
Опытным путем была получена следующая комбинация правил для фильтров R1 и R2:
/routing filter
add action=accept chain=ospf-out prefix=192.168.0.0/16 prefix-length=16-32
add action=discard chain=ospf-out
add action=discard chain=ospf-in prefix=172.16.0.0/24 prefix-length=30
Принцип фильтрации следующий: не передавать соседу ничего, кроме 192.168.ХХ.ХХ. Если нужно передать дополнительный маршрут, создается правило выше указанных.
Дополнительно
На этом базовая настройка чистого IKEv2 VPN завершена. Далее можете добавлять узлы, менять шифрование, добавлять отказоустойчивость путем объединения EoIP в Bond. Кстати, инициатор может быть одновременно и ответчиком.
Чтобы не потерять все таким трудом настроенное, бэкап следует делать с парольной фразой. Иначе закрытые ключи в него не попадают. Ну и конечно же команда экспорт в данном случае никак не поможет.
/system backup save password=1234567890
Еще один момент - частое падение OSPF. Обычно это связано с MTU основного канала или EoIP-туннеля. Достаточно его уменьшить, и OSPF приходит в норму.