С ростом количества удаленных рабочих мест/офисов возникает проблема не только пропускного канала центрального офиса, но и производительности 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. Если возникнут вопросы – поддержка отвечает.