Содержание
Схема сети
В головном офисе установлен маршрутизатор GW1. В филиале установлен маршрутизатор GW2. Маршрутизатор в филиале будет инициатором установления защищенного соединения. Маршрутизатор в головном офисе будет ожидать, когда инициатор запросит установление соединения.
Головной офис
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-адрес внешней сети головного офиса: 10.1.200.1/24
IP-адрес внешнего интерфейса маршрутизатора GW1: 10.1.200.1/24
IP-адрес внутренней сети головного офиса: 192.168.25.0/24
IP-адрес внутреннего интерфейса маршрутизатора GW2: 192.168.25.1/24
Настройка
Настройка первого маршрутизатора
Через графический интерфейс
Настройка IPsec-пира. На первом этапе надо указать адрес пира (маршрутизатора с которым будет устанавливаться соединение). В качестве алгоритма шифрования мы выбрали aes-128. Конечно можно использовать и более длинные ключи, но это не имеет практического смысла, т. к. даже для подбора такого ключа требуется очень-очень много лет. Поэтому мы считаем, что более длинные ключи нужны либо в маркетинговых целях либо, если вы очень заморочены на глобальной слежке правительства. Сертификат другого маршрутизатора (Remote Certificate) мы не указываем, т. к. авторизация сертификата будет производиться с помощью ключа удостоверяющего центра, который был импортирован ранее.
Настройка политики IPsec. Следующим шагом надо настроить политику IPsec. Политика описывает в каких случаях должно использоваться шифрование. Т. е., если пакет совпадает с правилом описанным в политике, то выполняется заданное действие. В нашем случае это шифрование. Если пакет не совпадает с правилом, то он идет дальше без обработки политикой.
Настройка правила обхода NAT.Если теперь попробовать установить туннель IPsec он не заработает и пакеты будут отклонены. Это произойдет потому, что оба маршрутизатора используют правило NAT, которое изменяет адрес источника после того, как пакет шифруется. Удаленный маршрутизатор принимает шифрованный пакет, но не может расшифровать его потому, что адрес источника не совпадает с адресом, который указан в настройках политики. Для более подробную информацию о прохождении пакетов можно увидеть здесь: http://wiki.mikrotik.com/wiki/Manual:Packet_Flow#IPsec_encryption. Правило обхода NAT обязательно должно находиться выше правила "masquerade".
Примечание: Если правило обхода NAT было создано после того, как было установлено защищенное соединение, то оно не заработает. Для того, что бы оно начало работать надо либо удалить все соединения на вкладке "Connections" у файервола либо перезагрузить маршрутизатор.
И с помощью захвата и перетаскивания мышью перетянем правило так, что бы оно находилось выше правила "masquerade".
Через консоль
/ip ipsec peer
add address=10.1.100.2/32 enc-algorithm=aes-128 generate-policy=port-strict send-initial-contact=no nat-traversal=no auth-method=rsa-signature certificate=server comment=filial1
/ip ipsec policy
add action=encrypt src-address=192.168.15.0/24 dst-address=192.168.25.0/24 sa-src-address=10.1.100.1 sa-dst-address=10.1.200.1 ipsec-protocols=esp tunnel=yes comment=filial1
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=192.168.15.0/24 dst-address=192.168.25.0/24
Настройка второго маршрутизатора
Через графический интерфейс
Расписывать заново каждое действие мы не будем, т. к. они полностью аналогичны настройкам на первом маршрутизаторе. Настройка IPsec-пира.
Настройка политики IPsec.
Через консоль
/ip ipsec peer
add address=10.1.100.1/32 hash-algorithm=sha1 enc-algorithm=aes-128 send-initial-contact=yes nat-traversal=no auth-method=rsa-signature certificate=client1 comment=HQ
/ip ipsec policy
add action=encrypt src-address=192.168.25.0/24 dst-address=192.168.15.0/24 sa-src-address=10.1.100.2 sa-dst-address=10.1.100.1 ipsec-protocols=esp protocol=all tunnel=yes comment=HQ
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=192.168.25.0/24 dst-address=192.168.15.0/24
Настройка маршрутизации
Маршрутизация при использовании IPsec "в чистом виде" не может быть использована, т. к. IPsec не создает виртуальный интерфейс, которому может быть назначен IP-адрес и добавлена запись в таблицу маршрутизации.
Следует учесть
- AES является единственным алгоритмом, который поддерживается модулем аппаратного шифрования, если такой установлен на маршрутизатор.
- Максимальное значение MTU при котором не будет фрагментации с использованием IPsec с алгоритмами SHA1 для подписи и AES-128 для шифрования = 1418. При использовании других алгоритмов значение MTU будет другим. Если используется механизм обхода NAT IPsec, следует понизить MTU на 28.
- AES является единственным алгоритмом, который поддерживается модулем аппаратного шифрования, если такой установлен на маршрутизатор.
- IPSec очень нестабильно работает за NAT’ом. Поэтому желательно, что бы внешние интерфейсы маршрутизаторов имели "белые" IP-адреса.
Проверка
Через графический интерфейс
Если IPSec-соединение установлено успешно, то в графе Established должен появиться таймер времени (5), который показывает, как давно установлено соединение. Индикатором является именно наличие таймера, а не факт наличия соединения (4), которое в случае проблем будет отображаться, но таймер будет отсутствовать.
Через консоль
Выполнить команду /ip ipsec policy print stats , которая покажет актуальное состояние соединения IPSec. В случае удачи мы должны получить: ph2-state=established.
GW1: 
Примечание: Состояние established через консоль будет отображаться только после того, как между двумя сетями произойдет попытка соединения. Например будет запущен ping. До тех пор пока соединение не будет установлено будет отображаться статус no-phase2. При этом через графический интерфейс всегда будет отображаться актуальная информация.
Связь IPsec между роутерaми Mikrotik RB1100AHx2(4) и Keenetic Ultra II
Наши серверы стоят в дата-центре компании «Ростелеком». Чтобы контролировать, настраивать, администрировать их из нашего офиса, мы используем связь с роутером и межсетевым экраном в дата-центре по шифрованному каналу IPsec. В нашем офисе мы используем хорошо себя зарекомендовавшую модель Zyxel Keenetic Ultra II — универсальное решение с аппаратным криптомодулем и аппаратными разгрузками NAT и контрольных сумм. Кроме того, в совокупности с модулем Keenetic DECT Plus этот роутер обслуживает и нашу IP-телефонию. Сегодня мы обсудим связку этого роутера и роутера Mikrotik RB1100AHx2, который мы в настоящее время используем в дата-центре.
Дано (все белые IP вымышлены):
Конфигурация RB1100AHx2
Белый IP-адрес WAN-интерфейса 152.12.12.12
Внутренняя сеть 192.168.10.0/23
Конфигурация Keenetic Ultra II
Белый IP-адрес WAN-интерфейса 182.12.12.12
Внутренняя сеть 192.168.80.0/24
Обязательное условие — внутренние сети не должны пересекаться!
Настройка Mikrotik:
Прежде всего идем в IP -> IPsec -> Groups, если там нет ни одной группы, просто жмем плюсик «Добавить», в открывшемся окне, в поле «Name» пишем «default» и жмем Ok, проще говоря добавляем группу default. Иначе в дальнейшем будут глюки при установлении соединения в фазе 1, дело в том, что темплейт policy по умолчанию должен принадлежать какой-то определенной группе. Иначе в поле «Policy Template Group» первой фазы (в настройке Peer) будет значение unknown, а связь не будет устанавливаться. Похоже на какую-то магию, но OS закрытая, доступа к внутренностям у нас нет, что там происходит сказать нельзя, так что просто добавляем группу, если ее нет, и идем дальше.
Добавляем Policy, для чего идем в IP -> IPsec -> Policies, жмем плюсик «Добавить»
Policy — это правило, что именно нужно делать при пересылке данных между подсетями, которые мы указываем на вкладке General. Source Address — локальная сеть в дата-центре, обслуживаемая роутером Mikrotik RB1100AHx2. Destination Address — локальная сеть в офисе, которую обслуживает Zyxel Keenetic Ultra II. Галочку «Template» не ставим, она превращает Policy в темплейт, а нам нужна именно Policy.
На вкладке Action мы указываем действие, которое должно происходить, мы хотим шифровать данные в туннеле (галочка Tunnel), туннель устанавливается между WAN-интерфейсами обоих роутеров, на которых прописаны белые адреса, которые участвуют в создании Security Association (SA), SA Src. Address (белый IP RB1100AHx2), SA Dst. Address (белый IP Keenetic Ultra II). Данные шифруются так, как указано в default proposal.
Далее настраиваем первую фазу IPsec — идем в IP -> IPsec -> Peers, жмем плюсик «Добавить»
Тут настроек уже больше. Address — IP-адрес удаленного роутера, вписываем туда белый IP Keenetic II Ultra. Port — обычный порт ISAKMP, менять его не стоит. Local Address можно не указывать. Придумываем ключ PSK, вписываем в поле Secret, где-нибудь его временно сохраняем — он понадобится, когда будем настраивать Keenetic UItra II. Устанавливаем галочку NAT Traversal, чтобы с роутером смогли связаться устройства, расположенные за NAT. Далее выставляем необходимые алгоритмы шифрования. Аппаратно обоими роутерами поддерживаются хеширование SHA1 (недавно был-таки взломан неутомимыми сотрудниками Google, а еще раньше не менее работоспособными китайцами), SHA256 и шифрование AES128-CBC, AES192-CBC, AES256-CBC — можно указать их все, при установлении SA обычно выбирается максимально возможные алгоритмы. Lifetime — время жизни ключа, по окончании действия ключа он будет перегенерирован. DPD или Dead Peer Detection — своеобразный keepalive, проверка удаленного peer, раз в какое-то время (DPD Interval) устройства спрашивают друг друга «ты там как, жив?» (R-U-THERE), ответ должен быть «да, живой я» (R-U-THERE ACK).
Если ответа нет, инициатор переспрашивает некоторое количество раз (DPD Maximun Failures), после чего уничтожает IPsec-сессию, и удаляет обе SAs. После этого устройства будут пытаться восстановить связь, если это прописано в настройках. При DPD Interval «disabled» ключ не будет обновляться в первой фазе при достижении конца Lifetime, так что лучше в этом поле выставить некое значение. DH Group это группа Диффи-Хеллмана, соответствия этих modp номерам в Keenetic есть в этой таблице.
Настройка второй фазы IPsec — идем в IP -> IPsec -> Proposals. Там уже есть default proposal, он был указан при создании Policy, так что можно просто подогнать его под себя. Помним об алгоритмах, обрабатываемых аппаратно, имеет смысл выставить именно их, при использовании аппаратного критомодуля загрузка процессоров обоих роутеров стремится к нулю.
Здесь тоже есть поле Lifetime, по окончании которого ключ будет перегенерирован. Здесь это происходит всегда, в отличии от первой фазы.
Открываем терминал и добавляем правило, разрешающее прохождение пакетов в обход маскарадинга (помним, какие сети мы разрешили в policy):
/ip firewall nat add src-address=192.168.10.0/23 dst-address=192.168.80.0/24 action=accept chain=srcnat comment=»To Office»
Ставим его над маскарадингом, на первое место:
/ip firewall nat move [find comment=»To Office»] 0
На этом настройку Mikrotik можно считать завершенной. Приступаем к
Настройке Keenetic Ultra II
Заходим в WEB-интефейс роутера, в самом низу его находим кнопку со щитом — раздел «Безопасность». Нажимаем ее, ищем вкладку IPsec VPN. Если ее там нет (вот неожиданность!) — идем в раздел Система (кнопка с шестеренкой) -> Обновление, жмем кнопку «Показать компоненты», ищем в списке IPsec VPN и ставим рядом с ним галочку, жмем в самом низу кнопку «Установить». Обычно он устанавливается сразу. Если серверы NDMS живы. Иногда надо подождать, но когда-нибудь вы его установите, если будете достаточно терпеливы.
Компонент установился? Роутер перезагрузили? Он делает это не торопясь, основательно, наверное тщательно расставляет каждый бит по ячейкам памяти… Но вот наконец, снова идем в раздел безопасность и находим-таки там вкладку IPsec
Ставим галочку «Включить», жмем кнопку «Применить». В IPsec-подключениях сначала будет пусто, жмем кнопку «Добавить». Возникнет окно настройки IPsec-подключения
Вписываем имя соединения. Выставляем галочки «Включить» (мы же все еще хотим установить соединение с mikrotik?), Автоподключение, Nail up (для удержания соединения), «Обнаружение неработающего пира (DPD)», задаем необходимый интервал проверки.
В поле «Удаленный шлюз» вписываем белый IP-адрес Mikrotik.
Далее настраиваем фазу 1. Мне лично не удалось заставить работать эти два роутера с протоколом IKE v2, поэтому все настройки приведены для IKE v1. У нас в офисе белый IP-адрес, грех не сделать его идентификатором локального шлюза. Поскольку мы указали белый IP-адрес Mikrotik, то в поле «Идентификатор удаленного шлюза» можно поставить «Any», или «IP-адрес», так же в нашем распоряжении есть три отлично работающих DNS, соответственно все устройства имеют корректные доменные имена, мы могли бы использовать в качестве идентификатора и FQDN. Помните, мы при настройке Mikrotik RB1100AHx2 придумывали ключ PSK, так вот, самое время его вписать в поле «Ключ PSK», кстати, оглянитесь, за плечами у вас нет врагов? Ключ прямо так и будет виден.
Хеш, алгоритмы шифрования и группу Диффи-Хеллмана надо выставить точно такие же, как и на Mikrotik, в настройках Peer, иначе роутеры не смогут друг с другом договориться. Режим согласования лучше оставить Main, Aggressive хоть и ускоряет подключение, но менее безопасен, например ключ передается не по шифрованному каналу, а по открытому, в виде хеша, а мы же зачем-то тут настраиваем IPsec… Так мы плавно перешли к настройке фазы 2
Режим задаем, конечно, туннель, ведь именно IPsec-туннель мы все это время и настраивали. Алгоритмы шифрования, хеши и группа Диффи-Хеллмана здесь должны соответствовать настройкам Proposal в Mikrotik. Вписываем локальную и удаленную подсети в соответствующие поля. Жмем «Применить».
Если все сделали правильно — пойдет инициализация соединения, в логах Mikrotik не должно быть ошибок, в IP -> IPsec -> Remote Peers должен образоваться Peer:
А в IP -> IPsec -> Installed SAs появиться две Security Associations, и должен быть виден обмен данными:
На стороне Keenetic весь процесс соединения отображается в логе, а информацию о соединении мы увидим на странице «Системный монитор» и вкладке «IPsec VPN»:
Со стороны Keenetic можно попробовать достучаться до какой-либо из удаленных машин.
При настройке VPN-сервера на Mikrotik, могут быть ошибки. Некоторые из них не связаны с очепятками и недостатком знаний. Могут встречаться нелогичные или специфичные для какой-то ситуации ошибки.
Proxy-arp на внутреннем бридже
При подключении по VPN вы можете неприятно удивиться, почему вы можете открыть страницу логина в роутер, 192.168.88.1 (если у вас такой), но не сможете открыть ни один внутренний ресурс. Штука в том, что надо включить proxy-arp на внутреннем интерфейсе, за которым есть нужный вам ресурс. У меня proxy-arp включен на весь bridge-local. Этот параметр позволяет взаимодействовать хостам, находящимся в разных сегментах сети, между друг другом.
Меню Interfaces -> открываете bridge-local, в пункте ARP выбираете proxy-arp.
Глюк default policy на микротик
При абсолютно верных настройках L2TP/IPSec подключения на клиенте (например, Windows 7) и на сервере (Mikrotik), не удается установить VPN-подключение. При этом в лог Mikrotik идет сообщение "failed to pre-process ph2 packet", а на клиенте Windows 7 выходит ошибка 789: попытка L2TP-подключения не удалась из-за ошибки, произошедшей на уровне безопасности. Данная проблема может иметь место на прошивках вплоть до последней стабильной на текущий момент (6.30).
Решение: удалить созданную по умолчанию группу в меню IP — IPSec — Groups, создать новую и указать ее в IP — IPSec — Peers в поле Policy Template Group.
По сообщению Hopy, еще одним решением проблемы с группами может стать выполнение этой команды после пересоздания группы:
ip ipsec peer set 0 policy-template-group=*FFFFFFFF
Возможно, это наследие от старых конфигураций, точного ответа нет, но тем не менее, это вариант. Кстати, возможно по этой причине (и ей подобным) все же стоит выполнять полный сброс устройства перед начальной настройкой. Но требованием это не является, это уж точно.
Ошибки firewall на всех этапах
Ну и не забывайте про то, что в нормальной ситуации при подключении удаленного клиента действуют сразу несколько ограничений, в числе которых брандмауэр клиента, брандмауэр шлюза клиента (или провайдерский прокси), брандмауэр самого микротик (и не только цепочка input — серьезно помешать может цепочка forward), который вы раньше настроили максимально строго, не так ли? Всякие NAT через NAT и траверсом погонять могут. Так что старайтесь всегда разумно и спокойно локализовывать проблему.
