Производительный VPN сервер на базе Mikrotik

С ростом количества удаленных рабочих мест/офисов возникает проблема не только пропускного канала центрального офиса, но и производительности VPN сервера центрального узла. Как показывают простые тесты предельная суммарная (прием/передача) производительность VPN простых железок 951 серии (которых вполне достаточно для удаленного офиса) 18-20Мб/сек.  При использовании сложных алгоритмов шифрования, и того меньше.

Столкнувшись с проблемой производительности туннелей, решено вывести функцию центрального VPN сервера за пределы своей сети – на масштабируемый VPS хостинг. Это дает:

  1. Возможность плавно наращивать производительность (и стоимость) центрального узла;
  2. Получить предельную производительность канала 1Гб/сек, которая, скорее всего, будет очень дорога при покупке такого канала у провайдера центрального офиса;
  3. Защищенность VPN сервера от DDOS;
  4. Надежность канала и оборудования;
  5. Возможность доступа к консоли роутера при ошибке в настройках и потере сетевого доступа к роутеру. Есть конечно SafeMode в winbox, но всякое бывает;
  6. Полная отвязка от провайдеров офисов в плане выделения публичных каналов;
  7. Значительно упрощается резервирование каналов до центрального офиса за счет необходимости резервирования только исходящих каналов в удаленных офисах. Все узлы становятся равноправными.
  8. Возможность в будущем вынести IP атс так же на хостинг и тем самым сократив пинг, как до провайдеров так и до самой АТС.

Минусы:

  1. Нужно платить от 80руб. в мес. что легко перекрывается отказом от публичных IP в одном из офисов.

Выбор VPS хостинга

Для тех кто хочет найти своего провайдера необходимо учитывать параметры:

  • Надежность дата центра. Тут наверно субъективно, но взор падает на крупные города и крупные дата-центры;
  • Страна размещения. Т.к. для работы нет нужды обходить блокировки необходимо выбирать провайдеров России, что значительно улучшит качество каналов. Регион размещения лучше выбрать по пингу. Для 90% – Москва.
  • 99% что слабым местом будет процессор и ширина канала. Объем памяти и тип и объем дисков никакого значения не имеет (в последних релизах CHR объем дисков урезан до 15Гб), т.е. утилизация процессора и канала идет более быстрыми темпами чем памяти.
  • Частота процессора должна быть максимальной, чтобы купив 1 ядро и минимум памяти (обычно самый дешевый тариф) получить сразу прирост производительности.
  • Ширина канала, обычно, не меняется для виртуальной машины, поэтому лучше сразу искать хостинг с нужным параметров с учетом роста. Бывают хостинги с мощным железом но канал 20Мб/сек. Очень часто пишется что канал 1Гб, а фактические тесты показывают что 30-50Мб. Часто 1Гб выделяется на пул машин, т.е. на совместное использование.
  • Ищите хостера с бесплатным тестовым периодом, т.к. это даст вам возможность протестировать все в реальных условиях, а не на рекламных проспектах. Дают потестировать – значит уверены в своих возможностях.

Мне пришлось перебрать 7 провайдеров прежде чем найти подходящего:

Почему?:

  • Бесплатный тест 3 дня;
  • Мощный процессор: 97Мб/сек VPN PPTP канал утилизирует процессор на 15-20%;
  • Реальный гигабитный канал (протестировано на паблик BW серверах mikrotik);
  • Защита клиентов от DDOS;
  • Возможность добавления внутреннего интерфейса для взаимодействия с другими виртуальными машинами, что избавит от необходимости VPN канала с рядом стоящей IP АТС или Web сервера.

Далее будет информация применительно к этому провайдеру.

RouterOS vs Cloud Hosted Router

Выбор прост – CHR:

  1. Система специально разработана для виртуализации;
  2. Лицензия не привязана к железу. Можно легко менять хостинг. Для RouterOS при смене железа нужно покупать пакет замены лицензии;
  3. Нет никаких ограничений в бесплатной версии кроме пропускной способности канала – 1Мб/сек. Следующий уровень уже платный – 1ГБ/сек. по цене равен level 4.

Никаких преимущество у RouterOS в виртуальной среде – нет. MetaRouter и KVM в виртуальной среде не работает.

Установка CHR

Решений явно много, но я использовал свой сценарий с удаленной загрузкой образа диска из Windows. Общий смысл такой: на сервере запускаем утилиту nc, которая ожидает входящие подключения и данные полученные в этом подключении она будет передавать утилите dd, которая полученные данные запишет прямо на диск. Утилите nc данные будем передавать с Windows машины, при помощи специально написанной для этого утилиты chr.copytonet.

Приступим:

  1. Создаем виртуальную машину с Debian 7/8;
  2. Подключаемся к созданной машине через SSH. В Windows среде – putty;
  3. Скачиваем приложение chr.copytonet. Оно необходимо как замена Linux клиенту nc.
  4. Скачиваем RAW (Raw disk image) образ Cloud Hosted Router – https://mikrotik.com/download и кладем рядом с chr.copytonet;
  5. Запускаем chr.copytonet и следуем инструкциям (по умолчанию подходят для hexcore).
  6. Сразу после успешного завершения – в SSH консоли сервера выполняем команду: reboot. Машина перезагрузится.
  7. У hexcore есть DHCP поэтому CHR сразу получит настройки IP по этому IP сразу можно подключиться при помощи winbox и выполнять нужные настройки. Естественно первым делом сменив пароль пользователя admin. Через 10 минут простоя увидите кучу попыток входа (подбора пароля).

Дальнейшая настройка VPN каналов делается так.

Если в вашем удаленном офисе/дома у админа стоит Mikrotik который не обеспечивающий нужной пропускной способности можно заставить рабочую станцию самостоятельно установить VPN подключение, соответственно шифрование и обеспечение канала будет за счет ресурсов этой станции, а не микротика удаленного офиса.

Результаты тестирования канала

Тестируем канал hexcore с публичными серверами Mikrotik (1 ядро 3066МГц, 1Гб):

UPD: Hexcore добавил штатную поддержку CHR и можно без дополнительных усилий создать машину сразу с CHR. Если возникнут вопросы – поддержка отвечает.

2 мысли о “Производительный VPN сервер на базе Mikrotik”

  1. Отличная статья. Установил Cloud Hosted Router на VPS хостинге, правда другого провайдера. Всё настроил, работает. Настраивал по этой инструкции “http://mikrotik.vetriks.ru/wiki/VPN:SSTP_site-to-site_(%D0%BE%D0%B1%D1%8A%D0%B5%D0%D0%B8%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BE%D1%84%D0%B8%D1%81%D0%BE%D0%B2_%D0%B1%D0%B5%D0%B7_%D1%81%D0%BB%D1%83%D0%B6%D0%B1%D1%8B_%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D0%B2)”. Поднял VPN SSTP. CHR выступает в качестве головного офиса. Ни как не могу настроить связь между клиентами, нет связи. От каждого клиента до офиса связь есть, а между офисами нет. Можете подсказать в чём проблема?

    1. Посмотрите мастер объединения офисов по PPTP, а именно – построение маршрутов. У филиалов нужно прописать маршрут: соседний филиал искать на шлюзе головного офиса. Вариантов несколько. Я использую route marks, для разделения маршрутов. Для локальной сети офиса, например, 192.168.10.0/24 прописываю таблицу main в ip route rules, следующим правилом отправляю искать соседние офисы в центральный офис: 192.168.0.0/16 – route marks = vpn_centr. Для некоторых офисов бывает делаю отдельный прямой маршрут в этом случае кроме локального прописываю до общего правила еще специально для офиса: 192.168.11.0/24 route mark = vpn_direct_11.
      1. 192.168.10.0/24 -> main
      2. 192.168.11.0/24 -> vpn_direct_11
      3. 192.168.0.0/16 -> vpn_centr

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.