17.01.2016

Почему за EoIP over OpenVPN нужно отрубать руки. И почему обе.

У роутерной ОС RouterOS (каламбур получился =)) есть уникальная возможность создавать Ethernet туннели между удаленными точками. Технология проприентарная и никем больше не реализованная (такой же результат можно получить с помощью VPLS, но это совсем другой уровень). Функция интересная и даже рабочая. С помощью неё мы можем соединить несколько удаленных точек в один широковещательный домен с одним DHCP сервером и связью на L2.

Технология эта применяется... А вот тут тупик. Давайте подумаем, где же она может применяться и чем может не устроить старый добрый роутинг. Связь между любым оборудованием, знакомым с IP (а такого оборудования с Ethernet интерфейсами сейчас чуть менее 100%) возможна с помощью маршрутизации - это основа протокола. На ум приходят лишь видеорегистраторы, способные видеть камеры лишь в пределах своего сегмента сети. 
Отсюда вывод: если вам понадобится туннель EoIP для проброса VLAN'a, Ethernet сегмента или каких-то других хотелок - задумайтесь. Скорее всего не нужно городить EoIP, а смотреть в сторону изменения структуры сети, перехода на другие технологии.

К тому же туннель EoIP нешифрованный и все ваши данные, идущие по нему можно легко перехватить. К счастью, в последних версиях RouterOS добавили функцию шифрования IPSec прямо внутри EoIP без каких-то дополнительных телодвижений.

В своем немалом опыте работы с Mikrotik (3 года плотной работы), я встречал EoIP 3 раза. Из них 2 раза эта технология была применена банально из-за незнания админами принципов маршрутизации. А третий раз для помещения серверов в один сегмент, будто они находятся в одном месте - просто чтобы запутать следы.

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


Из нешифрованности EoIP, а так же в силу того, что поднять такой туннель можно только между двумя белыми IP адресами встает вопрос, а что же делать. И выход лежит на поверхности - поднять любой туннель (желательно шифрованный) и поверх него него пустить EoIP. После беглого гугления узнаем, что хорошая защита и конфигурируемость у OpenVPN. И решаем использовать его, тем более в сети полно мануалов.

Да, OpenVPN хорош. Он позволяет использовать различные виды шифрования, в том числе "неломаемый" blowfish, использует сертификаты. Возможностей у него куча, включая пушинг маршрутов (в Linux). Но в тех материалах, что гуглятся на раз-два не указано, что работает OVPN на уровне User-Space, в то время, как все остальные (pptp, l2tp, sstp) на уровне ядра.

Это значит, что приоритет у всех процессов, выполняющихся на уровне ядра выше, чем у сервера OpenVPN. То есть процессор маршрутизатора сначала выполнит все свои задачи, а потом возьмется за шифрование, инкапсуляцию трафика в туннель. По этой же причине OVPN сильно нагружает процессор.

Что получаем в итоге. Весь трафик нашей сети (с обеих сторон) должен залезть в EoIP туннель. Включая широковещательный трафик, который так любит Microsoft - LLMNR, выборы мастер-браузера и т.д.(а это 10-15% трафика) Это трафик нужно фрагментировать и инкапсулировать в туннель. Сам EoIP туннель нужно зашифровать, фрагментировать и инкапсулировать в OVPN, процессы которого выполнятся в последнюю очередь и нагрузят процессор. Получаем жуткий оверхед на CPU, паразитный трафик на всех концах туннелей и отрубаем вторую руку.

Ещё можно палец на ноге отрубить за то, что выбрали TCP туннель. RouterOS пока не умеет работать с OVPN over UDP. То есть туннель зависит от TCP, который очень придирчив к качеству соединения и при потере нескольких пакетов нужна будет новая инициализация соединения и, как следствие, потеря EoIP туннеля и связности сети.

В качестве доказательства привожу картинку нагрузки на роутер. С одной стороны сервера, с другой - 10 компьютеров на винде с запущенными терминальными клиентами (mstsc) и несколько телефонов. Средний трафик - около 1 Mb/s, загрузка процессора 5% OVPN, 5% Ethernet. В пики видно то, что на картинке - 30% OVPN, 20% Ethernet. То есть половину CPU отдали за свою недальновидность.

OVPN Server

38 комментариев:

  1. Анонимный18.01.2016, 0:44

    Спасибо, очень полезно.

    ОтветитьУдалить
    Ответы
    1. Пожалуйста! Рад, что читаете.

      Удалить
  2. Анонимный07.04.2016, 21:19

    Спасибо за статью! Так как лучше настроить туннели между филиалами при помощи Mikrotik, одновременно с минимальной загрузкой канала и максимальной защитой данных.

    ОтветитьУдалить
    Ответы
    1. Это очень философский вопрос. Нужно плясать от конкретных целей и условий. Чаще всего я рекомендую проприентарный SSTP.

      Удалить
  3. Спасибо за статью! У меня тут на работе встал вопрос. Вкратце, нужно соединить два микротика 800 км друг от друга, на одном конце компьютер, на другом видеорегистратор, шифрование не нужно. Предлагают 3 варианта - GRE, EOIP, SSTP. Что подскажете в такой ситуации.
    Спасибо!

    ОтветитьУдалить
    Ответы
    1. А какие типы трафика внутри туннеля и какие объёмы? В большинстве случаев для описанных условий - L2TP или GRE.

      Удалить
  4. Про EoIP.
    2 гипервизора в разных местах (центральный офис и Датацентр).
    Выбран был Proxmox.
    ВМы бекапятся с одного гипервизора на другой и и со второго на первый сразу же попадая в сторедж, где лежат бекапы и которые видны в веб-морде.

    Микротики в этих же гипервизорах.

    Основной задачей была прозрачная миграция ВМ между площадками без! перенастройки сети (как транспортной сети так и настроек сети в самих ВМ) и простой удобный веб-интерфейс.

    Так вот из-за того, что ограничен бюджет и отсутствуют серьезные ИТ-специалисты решение с ЕоИП очень помогло для бекапа и восстановления ВМ на любом гипервизоре. Из-за того, что 1 бкаст домен и 1 ИТ-подсеть рестор проходит прозрачно без pre- и post- настройки, не говоря уже о роутинге и DNS.

    Как выкрутиться в таком клиническом случае - я не знаю.
    Другое дело - это замена EoIP на OpenVPN + Linux Bridge.

    Но GUI микрота и простейшая конфигурация в виде Winbox сделали свое дело. В итоге вся инфраструктура (до серьезных проблем) управляется среднего уровня ИТ-спецом через браузер с любой платформы и точки, где есть Интернет. Да, филиалы имеют железные микротики и канал в каждую площадку (OpenVPN-туннель), где гипервизоры.

    Удачи.

    PS: Если решение есть, значит оно кому-то нужно.

    ОтветитьУдалить
    Ответы
    1. А какая скорость у вас между двумя ДЦ и как быстро льются бэкапы?

      Удалить
  5. Приветствую! не подскажешь как решить проблемку: Поднят EoIP, так вот когда он находится в бридже, то устройства, которые находятся в этом же бридже рандомно теряют доступ к ресурсам в интернете. Как только я отключаю туннель из бриджа, то устройства выходят в сеть стабильно.

    ОтветитьУдалить
    Ответы
    1. Адреса по обе стороны бриджа какие? Подозреваю, что проблема в default gateway и маршрутизации.

      Удалить
    2. Как оказалось дело было в MTU, сделал правило в Mangle на занижение до 1410 все полетело

      Удалить
  6. Привет. Подскажи плиз, есть своя AS заанонсена в датацентр и есть другой датацентр где надо использовать эти ip, как можно прробросить ip шники, подойдет ли eoip или можно через простой gre как то сделать ?

    ОтветитьУдалить
    Ответы
    1. Любой туннель должен подойти

      Удалить
  7. А вот подскажите пожалуйста такой момент.
    Есть телефоны Cisco 7945/7965, находятся за NAT Mikrotik.
    С другой стороны имеем Asterisk. Который тоже за NAT Mikrotik.
    Поскольку SIP в Cisco телефонах с NAT не дружит в принципе, да и сам SIP over NAT это тот еще головняк - какие возможны варианты?
    Подключаться через L2TP/IPSec и настроить двустороннюю маршрутизацию из локальной в удаленную подсети - все равно имеем тот же NAT. И SIP на Cisco не взлетает =(
    Получается что опять же единственно однозначно рабочий вариант это EoIP?

    ОтветитьУдалить
    Ответы
    1. А откуда в двусторонней маршрутизации NAT? Если только в интернет. Но вы же в одной сети. Думаю, должно работать. Хотя, с телефонами Cisco ни разу не сталкивался.

      Удалить
    2. Не совсем понял тут про двустороннюю маршрутизацию.
      Схематично если представить, то выглядит примерно так:
      Cisco 7965/7945 -> Mikrotik (NAT) -> INTERNET <- Mikrotik (NAT) <- Asterisk

      Удалить
    3. если есть туннель между Mikrotik'ами, значит есть маршрутизация между asterisk и Cisco без всяких натов.

      Удалить
    4. циски берут адрес tftp по dhcp это l2 уровень от того что есть между ними маршрутизация по l3 цискофону не тепло не холодно

      Удалить
    5. Kin, никто не мешает нам поставить dhcp сервер рядом с телефоном. Это проще, чем городить жуткий оверхед.

      Удалить
    6. и каждый раз когда нудно обновить прошивку или настройки в 20 филлиалах прописать новый конфиг в dhcp вместо того чтоб ткнуть 1 кнопку во фронтенде к астериску, или когда трубка сменилась руками маки перебивать. Нет я уж лучше потерплю оверхед и бродкаст трафик чем это. Ну и это только один юзер кейс где описанный способ является единственно верным, бывают еще и неткомы которые работают исключительно по l2 и весы и платы потокового вещания и тд и тп, и если вы не сталкивались с задачами где нужно применить это решение это не значит что решение плохое, это значит что у вас недостаточно опыта. Короче говоря там где нужно обеспечить l2 коммутацию, надо обеспечить l2 коммутацию, а не повторять в каждой точке подключения половину инфраструктуры центрального узла (за что как раз и надо отрубать руки). А с бродкастом кстати можно боротьмся как и жертвовать скоростью канала в угоду конфигурябельности.

      Удалить
    7. и да орписанное вами это не жуткий оверхед, жуткий это когда к вашей схеме добавляются вланы c QoS в еопе а поверж уже этого оборудование поднимает свою шифрованную сессию атор прошивки которого спился 3 года назад исходников нет и понять что это за протокол не получается

      Удалить
    8. Согласен с Вами, что решение нужно выбирать исходя из требований. В том конкретном случае, о котором я писал в этом посте был как раз таки жуткий оверхед и весь стек применяемых технологий в данном конкретном случае был ни к чему - все можно было решить довольно стандартным подходом.

      Мораль статьи: думайте, прежде чем делать. Напишите требования к проекту, а уже потом выбирайте технологии.

      Удалить
    9. Ну если так хочется чтобы DHCP был на сервере с астериском, можно DHCP-Relay использовать.
      Хотя дело вкуса. Я то тоже L2 VPN стараюсь избегать.

      Удалить
    10. Если вам вдруг понадобился L2VPN, то у вас проблема в архитектуре. И надо кардинально перестраивать архитектуру, а не городить костыли.

      Удалить
    11. ...в большинстве случаев это так.

      Удалить
  8. Анонимный27.10.2016, 11:40

    Странно поставлен вопрос... OpenVPN может работать так же как и EoIP так же пропускать Л2, не нужно одно в другое пихать.
    Что же касается самой технологии, то EoIP прекрасное решение многих задач как правильно сказано для тех кто понимает...

    ОтветитьУдалить
    Ответы
    1. Перед внедрением любой технологии необходимо оценить все её позитивные и негативные моменты, рассмотреть конкурирующие технологии. И затем сделать осознанный выбор, а не впиливать первое попавшееся. Скажем, зачем BGP в типичной сети из офиса и 3 филиалов. Так же и тут. Слишком много оверхеда получилось в данной конкретной конфигурации.

      Удалить
  9. Тут был такой комментарий:
    Подскажите пожалуйста, возникла такая задачка, есть центральный офис с белым IP. а также планируется несколько удаленных точек.
    На удаленных точках интернет только через 3G 4G свистки МТС, Мегафон, Билайн (что лучше будет по качеству сигнала)
    на удаленных точках будет стоять компьютер, в котором установлен usb ключ.
    В центральном офисе будет 1ска, которой необходимо обращаться к этому ключу.

    Так как белые IP адреса получить у GSM провайдеров проблематично, то
    решено установить микротики, которые будут выступать в качестве клиента и
    и будут подключаться к центральному микротику в центр.офисе.
    Хотелось бы чтобы связь осуществлялась автоматически, то есть удаленные точки
    без действий сотрудников подключались к центру.

    Встал вопрос о выборе VPN туннеля. Так как наслышан, что воздушные провайдеры
    могут резать GRE, то от PPTP решили отказаться.
    Остается L2TP(+-IPSEC), SSTP, OVPN

    Посоветуйте как быть в такой схеме работы.


    Но почему-то автор или гугл его удалили.
    Мой ответ: я бы выбрал SSTP - его не отличить от https трафика, а значит и порезать почти невозможно

    ОтветитьУдалить
  10. Вопрос автору !
    Академически решаю задачу загрузки PXE клиентов в удаленной сети с сервера в центральной сети.
    Для простоты настроен PPTP в нем EoIP
    Удаленная локалка забриджована с одним из VLAN центральной сети
    Казалось бы имитация провода работает пакеты ходят неизменными
    Но при загрузки PXE клиента он получает первое DHCP , а получение данных с TFTP сервера не происходит (тайм аут)
    Понимаю что протокол TFTP сервера странноватый в плане назначения портов диалога и передачи но почему то казалось что EoIP должно было этот нюанс скорректировать.
    Интересно ваше мнение admin@fima.ru

    ОтветитьУдалить
    Ответы
    1. Я бы посмотрел на логи TFTP сервера и клиента. Ну и в сторону MTU. А если ничего не поможжет, то запускать Packet Sniffer на обеих сторонах и анализировать трафик

      Удалить
  11. >"неломаемый" blowfish

    жжоте

    ОтветитьУдалить
  12. Анонимный05.08.2017, 8:33

    Создается EoIP интерфейс, на него вешается OSPF. Как еще просто поднять связь между филиалами?

    ОтветитьУдалить
    Ответы
    1. В случае с EoIP достаточно объединить в bridge интерфейсы EoIP и локально сети.
      Но правильней будет поднять другой тип VPN и настроить роутинг - руками или с помощью OSPF. Как настроить OSPF я писал тут http://www.bubnovd.net/2016/03/ospf-mikrotik-routeros.html
      Также OSPF глубоко рассматривается в курсе MTCRE, который у нас будет проходить в сентябре http://www.bubnovd.net/2017/07/mikrotik-certified-routing-engineer-8september17.html

      Удалить
    2. Анонимный06.08.2017, 0:54

      Bridge не подходит - много подсетей. Через какой VPN кроме EoIP будет работать OSPF?

      Удалить
    3. Анонимный06.08.2017, 3:29

      EoIP заменил на IPIP, ничего не поменялось - все так же работает с OSPF.

      Удалить
    4. Давайте начнем с описания задачи. Что сейчас есть и что хотим получить?

      Удалить
  13. Анонимный17.08.2017, 12:06

    Здравствуйте!
    Есть 9 точек, которые надо объединить в одну сеть, белый ip есть есть только в центральной точке. Так же в качестве резервного канала планирую использовать gsm модемы. Какой VPN Туннель лучше использовать? И я правильно понял, что EoIP у меня не получится использовать? Хотелось бы получить единую сеть.

    ОтветитьУдалить
    Ответы
    1. EoIP просто так не получится сделать. Но это можно обойти, создав, к примеру, L2TP туннель и поверх него уже EoIP.
      В Вашей ситуации я рекомендую L2TP с IPSec шифрованием или SSTP.

      Удалить