У роутерной ОС 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
comments powered by Disqus