На устройствах Mikrotik с более, чем одни свичом (например модели 2011, 3011, 4011...) есть проблема с порт-флаппингом. Выглядит это как рандомные постоянные отключения и тут же обратные включения портов. Проблема давняя и компания в свое время выпустила фикс шредингера, который... ну вы поняли в общем. В подавляющем большинстве, флаппинг проявляется на портах второго свича.
Решений проблемы несколько:

1. Использовать только порты первого свича. Решение упоротое, но оно имеет место.
2. Отключение от микрота и всех подключенных к нему коммутаторов устройств с 100мбитным линком. Это поможет лишь в случае, если такие устройства в сети есть.
3. Наш любимый терминал (для тех, кто не в курсе, не весь функционал микротов доступен с «мышкокликательного» интерфейса).

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

/interface ethernet switch set switch1,switch2 cpu-flow-control=no

Если свичей на вашем устройстве больше двух, или они называются не стандартно, то соответственно дополнить\исправить в строке параметр «switch1,switch2».
Данное решение добавляет ограничения на использования функционала, относящегося к мониторингу интерфейсов, но, по крайней мере, убирает проблему с отвалом соединений.

Те, кто пользуется яблочной продукцией с беспроводным оборудованием корпоративного класса знают, что есть серьезные проблемы с беспроводной связью в такой связке. Спешу обрадовать (или расстроить), я нашел решение проблемы наконец. По итогу у вас есть несколько вариантов:

1. Сменить беспроводную точку на какое-нибудь говно от Dlink, Huawei, Asus и прочих фирм-производителей домашнего барахла.
2. Выкинуть свое устройство от яблочной компании и перестать натягивать сову на глобус (использовать эти устройства в корпоративной среде), купив соответствующее устройство.
3. Обратиться ко мне за платной перенастройкой сетевого оборудования.

Для тех, кто станет сейчас охать и ахать на тему того, что я не собираюсь устранять их проблему за бесплатно: а с чего вы решили, что я всегда буду решать любые ваши проблемы по доброте душевной? Данный пост лишь для того, чтобы вы знали, что проблему решить таки можно (по крайней мере до тех пор, пока яблочная компания в очередной раз не выкинет очередную дурь), хоть и за не маленькие деньги.

Т. к. Ubuntu — это кривое поделие, а не дистрибутив, штатная работа L2TP с включенным IPSec там не работает из графического интерфейса. Для того чтобы подключение заработало, необходимо:

1. Перейти в настройки VPN.
2. Создать новое L2TP подключение.
3. Перейти в пункт настройки IPSec.
4. Указать Preshared ключ и нажать на пункт дополнительно.
5. Указать алгоритмы шифрования первой и второй фазы (в случае микрота — это 3des-sha1-modp1024 и 3des-sha1 соответственно).

После этого подключение будет работать.

Меня достаточно часто спрашивают, почему мой выбор среди публичных облачных сервисов пал на Pcloud.. На рынке очень много различных облачных сервисов, среди которых есть 3 очень распространенных — Dropbox, Google Drive и Microsoft OneDrive, а также малоизвестное, в широких кругах, облако — Pcloud. Именно среди них я и провел простейшее тестирование скорости.

Почему не взял в расчет сервисы вроде Mega? Все просто — это не облако, а файловое хранилище. Сфера применения подобных решений отличается от облачных дисков.

Почему не брал в расчет российские облачные диски? Простите, а вы с головой дружите вообще, чтобы задавать подобные вопросы?

Почему не брались сервисы вроде box, hubic, hotta и аналогичных? А вы сами то уверены в надежности данных сервисов? А может уверены в том, что их завтра не купят другие поставщики услуг? Или может уверены в том, что разработчики ПО добавят их поддержку в свои продукты? Это сервисы сами в себе, с россыпью минусов: у кого-то ужасные скорости, у кого-то конское ограничение по объему файлов, кто-то активно любит лазить в содержимое вашего облака (да, яндекс?), кто-то поддерживает ограниченный набор операционных систем, у кого-то кошмарные скорости и т. д.
Отсюда и выбор у нас не велик при всем его, казалось бы, богатстве.

Тестирование проводилось простейшим способом, однако он очень наглядно демонстрирует скорости трех решений. Суть теста: создаем файл на сервере, размером в 1GB и сначала загружаем его, а затем скачиваем обратно и замеряем время. Т. к. мы тут все взрослые ребята, а не придурки с type-c головного мозга, то делать это будем не с секундомером, а нормальными методами:

1. Для теста создан новый виртуальный сервер с гарантированным выделенным каналом в 100мбит/с
2. Устанавливаем rclone, который позволяет работать с подавляющем количеством облачных сервисов
3. Создаем тестовый файл: dd if=/dev/zero of=test bs=1 count=0 seek=1G
4. Подключаем в rclone нужные облака
5. Запускаем процесс загрузки: time rclone copy test XXXcloud:
6. Запускаем процесс скачивания: rm -rf test && time rclone copy XXXcloud:test test

По завершению каждой операции скачивания\загрузки будет выведен таймер затраченного времени. Единственное отличие в тесте — облако от Google. Почему? Потому, что эта компания в каждом регионе устанавливает свое промежуточное кэширующее решение, чтобы ускорить работу с наиболее часто запрашиваемыми данными. По этой причине, для скачивания с данного облака приводится 2 результата: недавний файл, который был закачан в облако и находится в кэше и файл, которого в кэше нет (файлы идентичного объема). Так что тут нужно держать в голове, что часть ваших данных будет доступна на высоких скоростях, а часть..

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

Зачастую VDS хостинги не предоставляют возможность установки Mikrotik CHR. Однако это легко обойти. Для того, чтобы установить нужную нам систему в обход ограничений, необходимо выполнить несколько простых шагов:

1. Разворачиваем на хостинге Linux дистрибутив (в примере я буду указывать команды для Ubuntu)
2. Логинимся на сервер и получаем права суперпользователя:

sudo -i

3. Обновляем пакетную базу и устанавливаем необходимые пакеты:

apt update && apt -y install unzip wget

4. Скачиваем raw образ системы (актуальные ссылки смотрим на сайте в разделе загрузок):

wget https://download.mikrotik.com/routeros/6.47.4/chr-6.47.4.img.zip

5. Распаковываем образ:

unzip chr-6.47.4.img.zip

6. Включаем сочетания SysRq:

echo "1" > /proc/sys/kernel/sysrq

7. Переподключаем все файловые системы в режиме чтения:

echo u > /proc/sysrq-trigger

8. Находим название системного диска:

lsblk

9. Записываем на него образ:

dd if=chr-6.47.4.img of=/dev/vda

10. Перезагружаем виртуальную машину:

echo "b" > /proc/sysrq-trigger

11. После перезапуска, вместо линукс системы, будет запущен Mikrotik CHR, развернутый на весь объем жесткого диска

Для дистрибутива Centos команды несколько отличаются:

1. Разворачиваем на хостинге Linux дистрибутив (в примере я буду указывать команды для Centos)
2. Логинимся на сервер и получаем права суперпользователя:

sudo -i

3. Обновляем пакетную базу и устанавливаем необходимые пакеты:

yum install wget unzip

4. Монтируем tmpfs в /tmp: mount -t tmpfs tmpfs /tmp
5. переходим в директорию tmp и скачиваем raw образ системы (актуальные ссылки смотрим на сайте в разделе загрузок):

cd /tmp && wget https://download.mikrotik.com/routeros/6.47.4/chr-6.47.4.img.zip

6. Распаковываем образ:

unzip chr-6.47.4.img.zip

7. Включаем сочетания SysRq:

echo "1" > /proc/sys/kernel/sysrq

8. Находим название системного диска:

lsblk

9. Записываем на него образ:

dd if=chr-6.47.4.img of=/dev/vda

10. Перезагружаем виртуальную машину:

echo "b" > /proc/sysrq-trigger

11. После перезапуска, вместо линукс системы, будет запущен Mikrotik CHR, развернутый на весь объем жесткого диска

P.S. Не забудьте предварительно параметры сети посмотреть, иначе потеряете доступ до виртуалки.