Что такое ip tunnel на mikrotik

Mikrotik + IPSec + Cisco = Мир, Дружба, Жвачка

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

Ньюансы

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

Предыстория

Столкнулся по работе с необходимостью замены серверов в наших филиалах, на что-нибудь более надёжное, аппаратное.
Связь у нас с центральным офисом осуществляется через тонели с шифрованием ipsec. В центральном офисе у нас, собственно всё на кошкообразных построено, а в большинстве филиалов стоят обычные сервера под FreeBSD, которые цепляются тонелями, с помощью racoon.
Встала задача, в связи с устареванием, выходом из строя самих серверов, начать устанавливать простые, недорогие аппаратные решения.

Братья по-разуму, коллеги и форумы натолкнули меня на изделия Mikrotik, и сразу же я направил к ним письмо следующего содержания:

Ответ пришёл неожиданно, очень быстро, в течении одного дня:

Я сразу остановил свой выбор на «RB450G». Заказали, привезли.
Сразу скажу, по вышеуказанной ссылке настроить не удалось. Данные там устаревшие, некоторые параметры в версии 5.20 просто отсутствуют.
Порылся по форумам, почитал статьи примерно такого содержания:
betep.wpl.ru/2009/02/wiki-mikrotik.html
netandyou.ru/17 — кстати интересная, но рассматривается пример ipsec в gre-тоннеле, а в моём случае тип тонеля ipip, и режим работы crypto ipsec transform-set на циске не «Tunnel», а «Transport». Впрочем тоже не получилось.
Так же перерыл ещё кучу материалов на форумах, добился, чтобы проходило соединение, шифрование включалось, но ничего не работало, пакеты отказывались бегать по тоннелю, как я не старался их к этому принудить.
Два потерянных дня и побудили меня написать на хабр, возможно кому-то эти строки помогут в работе.

В итоге, всё оказалось банально и очень просто.

Я акцентрировал своё внимание на настройках политик IPSec в микротике, и похоже это было ошибкой 🙂
После вдумчивого изучения материала, который мне действительно помог:
wiki.mikrotik.com/wiki/Manual:IP/IPsec#Transport_mode_2 — от сюда и ниже на пару-тройку страниц
и
wiki.mikrotik.com/wiki/Manual:Interface/IPIP — тут просто основы, но на-всякий случай.

Я просто убрал все политики (к слову — они были правильно настроены, судя по динамическим, создавшимся позже), и просто установил галочку автогенерации политик. Что успешно и проделала циска с микротиком после соединения.

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

Cisco:

Микротик:

Если кто-то настраивает через микротиковский GUI «Winbox», аналогичная настройка:
1. Интерфейсы-IP Tunnel. Добавить:

2. В разделе IP-IPSec-Proposals в дефолтном правиле ОБЯЗАТЕЛЬНО сменить SHA1 на MD5!
3. IP-IPSec-Peers. Добавить:

После этого, если циска уже настроена, то должна поднятся сессия:

И автоматически сгенерируются политики:

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

После этого можно заглянуть обратно в IP-IPSec, закладка Instaled SAs, и вы должны увидеть, что байтики бегут по тунелю в обе стороны:

Надеюсь этот материал сэкономит кому-нибудь время и нервы.

Источник

Настройка VPN средствами IPsec Mikrotik

Стандарт IPsec создавался для обеспечения безопасности незащищенного протокола IP. Достигается это путем добавления собственных заголовков в оригинальный пакет для его инкапсуляции, т.е. сокрытия оригинального содержимого.

Не смотря на появление более новых протоколов, позволяющих организовать защищенный канал связи через сеть интернет, IPsec остается довольно популярным так как обладает довольно высокой степенью безопасности и хорошей производительностью.

Чтобы правильно настроить VPN с помощью IPsec, необходимо понимать базовые принципы. Поэтому статья поделена на следующие части:

Принципы работы протокола IPsec и базовые термины

IPsec может работать в двух режимах: транспортном и туннельном:

При создании туннеля создается связь, которая называется SA (Security Association).
Каждая связь SA создается для однонаправленного соединения. Так как данные необходимо передавать в двух направлениях, то SA создаются парами. Одна пара SA создается для протокола AH, другая для ESP. Созданные SA хранятся в базе данных узлов (роутеров Mikrotik), которые создают туннель.

На каждом узле имеется база данных политики безопасности (Security Policy Database).
Политики содержат следующие настройки:

Установка соединения 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. Правило для обратного направления трафика будет отличаться адресами Src. Address 192.168.2.0/24 и Dst. Address 192.168.1.0/24

После добавление правил на обоих роутерах, в таблице RAW должны присутствовать следующие правила:

Настройка IPsec на роутере офиса №1:

1. Настройте Profile для фазы 1

Профили определяют набор параметров, которые будут использованы для согласования IKE в фазе 1.

2. Настройте Proposal для фазы 2

3. Добавьте Peer

Здесь указывается информация необходимая для установки соединения между демонами IKE двух узлов. Затем это соединение будет использовано для согласования ключей и алгоритмов для соединений SA.

Для работы IPsec должны быть доступны порты UDP/4500 (IPsec NAT traversal) и UDP/500 (IKE). Проверьте файрволл, чтобы не было правил, блокирующих трафик на эти порты.

Выберите Peer и укажите секретный идентификатор Secret. Чем сложнее Secret тем лучше, поэтому для его создания лучше воспользоваться генератором пароля.

5. На завершающем этапе создайте Policy (Политику), которая контролирует сети/хосты защищенного канала.

Конфигурация IPsec для роутера офиса №2:

Конфигурация второго узла идентична первому, с соответствующими ip-адресами. Последовательность настройки выполняйте в таком же порядке.

Начните с настройки Profile и Proposal.

Затем добавьте Peer и Identity.

В завершении создайте Policy.

Ниже, на слайде, представлены все настройки IPsec второго узла в Winbox:

Источник

IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера

upd: Отличный разбор про устройство современного стэка IPsec протоколов ESPv3 и IKEv2 опубликовал stargrave2. Рекомендую почитать.

Linux: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)

Mikrotik: CCR 1009, RouterOS 6.46.5

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»

Скорее всего у вас, как и у меня, на WAN интерфейсе настроен snat/masquerade, это правило надо скорректировать, чтобы исходящие пакеты ipsec уходили в наш туннель:
Переходим в раздел «IP» — «Firewall».
Вкладка «NAT», открываем наше правило snat/masquerade.

Рестартуем демона racoon

Если при рестарте racoon не запускается, значит в конфиге имеется ошибка, в syslog racoon выводит информацию о номере строки, в которой обнаружена ошибка.

Демон racoon при загрузке ОС стартует раньше поднятия сетевых интерфейсов, а мы указали в секции listen опцию strict_address, необходимо добавить в файл systemd юнита racoon
/lib/systemd/system/racoon.service, в секцию [Unit], строку After=network.target.

Сейчас наши ipsec туннели должны подняться, смотрим вывод:

Теперь необходимо настроить 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» — «Addresses», добавляем адрес:

Теперь можно добавлять маршруты в сети за linux машиной, при добавлении маршрута, gateway будет наш интерфейс IPIP-IPsec0.

Так как наш сервер linux является транзитным, то на нем имеет смысл задать параметр Clamp TCP MSS для ipip интерфейсов:

создаем файл /etc/iptables.conf со следующим содержимым:

и в /etc/network/interfaces
post-up iptables-restore

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Настройка туннелей GRE и IPIP на роутерах Mikrotik

Туннели, созданные с помощью данных протоколов, не имеют никаких механизмов обеспечения безопасности (шифрование, аутентификация), поэтому в чистом виде они практически не используются. Для обеспечения нужного уровня безопасности используется IPsec, поверх которого уже разворачивается GRE или IPIP-туннель ( GRE over IPsec, IPIP over IPsec). Далее, говоря о данном типе туннелей мы будем подразумевать ввиду именно их.

Ни GRE, ни IPIP не используют порты, поэтому они не могут преодолеть NAT, это требует от обоих узлов иметь выделенные IP-адреса или находиться в одной сети. Проблема NAT частично снимается при использовании IPsec, за счет использования протокола NAT-T, но требование выделенных адресов узлов остается. Кроме того, по этой причине вы не сможете установить более одного GRE или IPIP-соединения между узлами.

Далее мы будем придерживаться следующей схемы:

Настройка GRE-туннеля

В терминале это можно выполнить командой:

Полностью аналогичную настройку выполняем и на втором роутере, только меняем местами Local Address и Remote Address, после чего туннель должен перейти в рабочее состояние. За отслеживание состояние туннеля отвечает параметр Keepalive, по умолчанию он предполагает десять попыток с интервалов в 10 секунд, если за это время с противоположной стороны не будет получен ответ, то туннель будет считаться неработоспособным.

В противном случае вы будете получать ошибку при согласовании параметров IPsec:

Настройка IPIP-туннеля

В терминале это же действие:

Затем дублируем настройки на второй роутер, заменяя местами Local Address и Remote Address, также учитываем все то, что было сказано выше о настройках IPsec.

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

В терминале для этого же действия выполните команду:

Где вместо interface=gre-tunnel1 укажите имя собственного туннельного интерфейса.

Аналогичные настройки следует выполнить и на втором роутере.

На втором роутере делаем аналогичные настройки с учетом IP-адреса роутера и сети назначения.

После чего пробуем получить из одной сети доступ к узлу другой. Если все сделано правильно, то попытка увенчается успехом.

Дополнительные материалы:

Mikrotik

The Dude

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

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

Источник

Создание домашней сети на базе устройств MikroTik: Часть 5 — Создание EoIP туннеля

После организации IP туннеля на базе OpenVPN, нам необходимо поверх него, создать еще один туннель используя EoIP
Для начала давайте немного взглянем, что такое EoIP в MikroTik RouterOS:
Ethernet over IP (EoIP) Tunneling — это протокол MikroTik RouterOS, который создает туннель Ethernet между двумя маршрутизаторами поверх IP-соединения. Туннель EoIP может работать через туннель IPIP, туннель PPTP или любое другое соединение, способное транспортировать IP.
Когда функция моста маршрутизатора включена, весь трафик Ethernet (все протоколы Ethernet) будет соединен так же, как если бы там был физический интерфейс Ethernet и кабель между двумя маршрутизаторами (с включенным мостом). Этот протокол позволяет использовать несколько сетевых схем.

Сетевые настройки с интерфейсами EoIP:
Возможность подключения локальных сетей через Ethernet
Возможность подключения локальных сетей через зашифрованные туннели
Возможность подключения локальных сетей через беспроводные сети 802.11b «ad-hoc»

Протокол EoIP инкапсулирует Ethernet-фреймы в пакеты GRE (IP-протокол номер 47) (как и PPTP) и отправляет их на удаленную сторону туннеля EoIP.

Т.е. по сути между нашими удаленными объектами, после создания туннеля, будет «ходить» любой трафик, как в обычной проводной локальной сети.

Переходим ко второму роутеру

После добавления туннельных интерфейсов в сетевой мост Вы уже должны успешно пинговать локальные ПК(смартфоны, ноутбуки и др.).
Вроде бы все хорошо. На каждом объекте свой DHCP сервер, заданы свои пулы адресов.
Но как мы знаем при подключении нового клиента к сети он начинает широковещательную рассылку специальных пакетов DHCPDISCOVER.
Рассылка идет начиная с адреса 0.0.0.0 до адреса 255.255.255.255 т.е. по всем возможным.
В ответ сервер DHCP посылает пакет DHCPOFFER. Клиент в ответ на пакет DHCPOFFER посылает пакет DHCPREQUEST. В ответ на пакет DHCPREQUEST сервер DHCP посылает пакет DHCPACK, завершая цикл инициализации.
Соответственно для нас НЕжелательно, чтобы подобные пакеты с одного объекта убегали в другой и наоборот.
Нам нужно ограничить объект только тем пулом IP адресов, которые мы задали. Но нельзя запрещать клиентам общаться между собой.

И MikroTik позволяет нам это сделать!

3. Запрещаем прохождение DHCP Broadcast запросов через туннель EoIP
Давайте разбираться.
Смотрим на каких портах и по какому протоколу работает DHCP: Wiki DHCP
Видим: Передача данных производится при помощи протокола UDP. По умолчанию запросы от клиента делаются на 67 порт к серверу, сервер в свою очередь отвечает на порт 68 к клиенту, выдавая адрес IP и другую необходимую информацию, такую, как сетевую маску, шлюз по умолчанию и серверы DNS.

Добавляем такое же правило на второй роутер.
Вот теперь, вроде бы, можно считать настройку единой локальной сети законченной…

Далее у нас встает вопрос безопасности и доступа из вне к локальным устройствам.
Все верно, имея статический IP мы подвержены риску быть взломанными. Т.к. наш статический IP доступен в интернете он может подвергаться различного рода «атакам».
Поэтому нам нужно сделать так, чтобы только мы могли подключаться к нашим роутерам и другим сервисам в локальной сети.
Также у нас на очереди система мониторинга DUDE.

Дополнение:
Я провел небольшое тестирование скоростных характеристик своего туннеля.
Делал я их с помощью утилиты bandwidth-test в WinBox между самими роутерами. Т.е. роутер-роутер через сети провайдеров.
Тарифы такие:
hAP ac — 500 Mbps (Практические пока до 300 Мбит/сек)
hEX — 100 Mbps (Практические 95 Мбит/сек)
Пробовал я все доступные на RouterOS для OpenVPN (v6.39.3) методы аутентификации (md5, sha1) и шифрования (blowfish 128, aes 128, aes 192, aes 256) и вообще без шифрования и аутентификации (null)
Соответственно максимально возможная скорость ограничена hEX стороной т.к. у него всего 100 Мбит/сек.
Самую быструю скорость удалось получить конечно в режиме без шифрования и аутентификации вообще Send — 85 Mbps / Receive — 85 Mbps
Самую низкую с шифрованием AES256 Send — 25 Mbps / Receive — 25 Mbps
Оптимальным вариантом я бы выбрал режим Auth (sha1) и Cipher (aes 128) т.к. для домашней сети не нужно сильного шифрования Send — 31 Mbps / Receive — 31 Mbps
Какой режим выбирать, решать Вам!

P.S.
Я не претендую на идеальное построение подобной сети. Это один из многих способов.
Если Вы знаете, как построить подобную сеть лучшим образом или доработать текущую, можете не стесняться и писать свои варианты в комментариях
У меня успешно работает =)

Список всех статей в хронологическом порядке: История статей

Источник