VDSina Хостинг

В эту субботу мы начали предоставлять хостинг для имиджборда 8kun.net.

Мы хотим выразить свою позицию относительно 8kun, свободы слова, свободного интернета и конкретно о статье об экстремизме УК РФ.

С 2015 года до сегодня в России сотни человек были осуждены на реальные сроки лишения свободы за высказывания в интернете. Статья «экстремизм» стала инструментом подавления политической оппозиции и способом лишения одного из главных прав, гарантируемых нам конституцией РФ — свободы слова.

В июне 2016 года был принят «антитеррористический пакет» Яровой, который дал ФСБ законное право расшифровывать нашу переписку и ужесточил наказание за экстремизм в интернете. В Уголовном Кодексе нет четкого правового определения слова «экстремизм», часто под этим понимается просто критика властей и существующих порядков.

В 2018 году государство начало война с Telegram, который отказался выдавать ключи шифрования. На нее планируется выделить еще 20 млрд рублей из наших налогов.

В условиях цензуры и давления на СМИ, свободный интернет остается единственной надеждой на реальное представление о том, что происходит в мире.

Мы теряем наши конституционные права и свободы одно за другим.

После теракта в редакции газеты Charlie Hebdo 7 января 2015 года, два гражданских активиста Владимир Ионов и Марк Гальперин вышли с плакатами Je suis Charlie на Манежную площадь в Москве.

Власти быстро отреагировали — суд рассмотрел два административных материала и назначил Марку Гальперину арест на 38 суток. Дадина суд приговорил к аресту на 15 суток и к штрафу в размере 20 тысяч рублей.

Мы не поддерживаем терроризм и осуждаем нетерпимость. Но еще меньше мы хотим присоединиться к тем, кто под видом защиты пытается лишить нас конституционных прав и впервую очередь — свободы слова.

В сложившейся ситуации, единственное, что мы считаем верным — это защищать ее даже в тех проявлениях, которые не вызывают у нас симпатии.

Мы — 8chan.

https://vdsina.ru

Если ваша работа требует держать множество SSH-сессий к разным серверам, вы наверняка знаете, как они легко ломаются при переключении на другой Wi-Fi или при временной потере интернета. Но что, если я скажу вам, что все эти проблемы давно решены и можно забыть про сломанные сессии и постоянные переподключения?

Открывая крышку ноутбука, все мои десятки SSH-сессий сразу доступны и находятся в том же состоянии, в каком я их оставил. В статье описывается настройка терминального сервера для системного администратора. Использование такого сервера позволяет забыть о сломанных SSH-сессиях, постоянном переподключении и вводе паролей.

Настройка сервера
Идея проста и наглядно проиллюстрирована на картинке в заголовке поста: все SSH-подключения мы будем держать на специальном терминальном сервере. Этот сервер будет нашей точкой входа для управления другими серверами. При этом на конечных серверах не потребуется настройки или установки дополнительного ПО.
Для терминального сервера подойдет почти любая конфигурация, но лучше иметь побольше оперативной памяти, чтобы хранить лог консоли внутри каждой сессии и иметь возможность в любой момент проскроллить историю вверх и посмотреть, что вы делали на сервере сессии месяц назад. Обычно 1-2ГБ памяти достаточно.

Выбор дистрибутива
В терминальном сервере самое главное — это uptime, ведь чем реже мы перезагружаемся, тем больше живут наши SSH-сессии. Поэтому выбираем максимально консервативный LTS (Long Term Support) дистрибутив, например стабильную ветку debian или ubuntu. Настраиваем автоматические обновления (unattended-upgrades) таким образом, чтобы внезапный перезапуск программ не стал неожиданностью.

Настройка SSH-сервера
Так как терминальный сервер будет открывать доступ ко всем нашим серверам разом, будет правильно его обезопасить. Для этого запретим аутентификацию с помощью паролей, оставив только доступ с помощью ключей, а так же запретим логиниться пользователем root.
Предварительно нужно создать нового пользователя в системе.

/etc/ssh/sshd_config
.....
# Запрет логиниться пользователем root
PermitRootLogin no
# Запрет использования паролей, только ключи
ChallengeResponseAuthentication no
# Если паролей нет, то и PAM не нужен
UsePAM no
....

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

Часто начинающие админы в своих руководствах советуют менять порт SSH и вместо 22 устанавливать какой-то нестандартный вроде 2222. На мой взгляд это плохая практика, не добавляющая никакой безопасности.

• Это не позволит защититься от перебора паролей, так как автоматические сканеры всё равно найдут SSH на любом порту и начнут долбиться.
• Это вносит бардак, если систему администрирует несколько человек и каждый выдумывает свои порты. Когда таких систем десятки, приходится искать сканером на каком порту спрятан SSH на этот раз.
• Это ломает встроенные ограничения безопасности в программах. Например, веб-браузеры не подключатся на порт 22, если явно указать его в HTTP, но при этом подключатся на другой нестандартный порт. Это можно использовать для срабатывания IDS/IPS систем DDoS.

Tmux — одно окно чтобы править всеми
Tmux — это невероятно удобная программа для управления виртуальными терминалами, без которой я просто не представляю своей работы. Поначалу он кажется запутанным и сложным, но если пересилить себя и научиться им пользоваться, вы больше не сможете от него отказаться.

Для тех, кто не знает что такое tmux, представьте себе веб-браузер с вкладками, только вместо сайтов там консольные сессии. Можно открыть бесконечное количество вкладок и в каждой вкладке запустить свою программу. При этом он запущен на сервере, и от него в любой момент можно отключиться, при этом все запущенные вкладки и программы останутся на своём месте и к ним можно будет вернуться.

Устанавливаем tmux, если он еще не установлен:

apt install tmux

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

Создаем новую сессию:

tmux new

В этот момент мы создали новую сессию с одним окном и сразу подключились к ней. Можно видеть появившуюся внизу зелёную панель состояния. Это что-то вроде панели с вкладками в браузере. На ней будут отображаться текущая вкладка и соседние, а также служебные сообщения.

В этот момент, даже если мы закроем SSH-подключение и заново подключимся к серверу, наша запущенная сессия tmux останется в прежнем состоянии, вместе со всеми запущенными программами так, будто мы ее свернули. Попробуем запустить программу top внутри сессии tmux и отключимся от неё. Для наглядности закроем полностью окно терминала и заново подключимся к серверу.

После переподключения к серверу подключимся к нашей запущенной ранее сессии:
tmux attach

И убедимся, что запущенная программа top продолжает работать. На этом месте важно понять главный принцип: после запуска сессия tmux остается работать в фоне на сервере вне зависимости от того, подключены вы к ней или нет.

Так как сессия tmux позволяет несколько одновременных подключений, это можно использовать для совместной работы нескольких человек на сервере, чтобы видеть в реальном времени одну и ту же консоль. Для этого все подключаются к одному серверу под одной учетной записью и вводят tmux attach. Там же можно и чатиться, прямо в командной строке. Мы часто это используем, чтобы не перекидывать друг другу лог консоли в мессенджере, а сразу работать за одним терминалом.

Tmux умеет делить окно на несколько (каждое окно внутри вкладки называется pane), это удобно, когда нужно одновременно видеть две консоли. Например, в одном окне редактировать скрипт, а в другом смотреть лог.


По умолчанию, для управления tmux-ом используется хоткей Ctrl+b. После нажатия этого управляющего хоткея tmux ожидает ввода основной команды из одной буквы.

Вот основные команды:

• Ctrl+b + c — (create) Создать новое окно (вкладку)
• Ctrl+b + <цифра> — Переместиться на вкладку номер N, где цифра это клавиша от 0 до 9. Нумерация окон начинается с нуля.
• Ctrl+b + x — закрыть текущее окно. Если будет закрыто последнее окно, сессия tmux завершится.
• Ctrl+b + w — отобразить список всех окон, по которому можно перемещаться кнопками курсора вверх-вниз и выбрать нужное, нажав enter.
• Ctrl+b + " — разделить окно пополам по горизонтали и создать новое
• Ctrl+b + % — разделить окно по вертикали и создать новое
• Ctrl+b +, — переименовать текущее окно
• Ctrl+b + вниз/вверх/влево/вправо — перемещаться по pane'ам внутри окна
• Ctrl+b + page up/page down — прокрутить скролл вверх
• Ctrl+b + / — искать по истории, как в vim или less

Это все хоткеи, которые мне потребовались за 10 лет использования tmux. На самом деле их намного больше, но для начала лучше остановиться на этих.

Конфиг Tmux
Я считаю хоткей Ctrl+b неудобным, так как прожимать три клавиши для любого действия выходит слишком много. Тема конфигов tmux это отдельная область вкусовщины, и у каждого бывалого пользователя есть свое видение как правильно и удобно. Есть даже целые авторские подборки конфигов и тем для tmux.

Для отправной точки я приведу пример своего конфига, который, как мне кажется, исправляет все сложности, мешающие быстрому освоению tmux. Конфиг располагается в домашней папке с именем ~/.tmux.conf

# Вместо ctrl+b будет использовать одну кнопку. Нам моем macbook это самая правая клавиша в цифровом ряду
set-option -g prefix `

# Когда нужно послать символ <`> нажимаем `+a
bind-key a send-prefix

# Нумерация окон с единицы вместо ноля
set -g base-index 1
set-option -g base-index 1
setw -g pane-base-index 1

# Lowers the delay time between the prefix key and other keys - fixes pausing in vim
set-option -sg escape-time 1

# Лимит истории консоли в 1000 строк. Столько строк можно отскроллить вверх
set -g history-limit 1000

# Цвета статус бара

# default statusbar colors
set-option -g status-fg white
set-option -g status-bg default

# default window title colors
set-window-option -g window-status-fg default
set-window-option -g window-status-bg default




# Автозапуск окон с командами при первом запуске
#------------------

# Respawn windows when PANE IS DEAD
bind-key R respawn-window

# Создать сессию default с окном local
new -d -s default -n local

# Создать окно с именем irc и командой irssi
neww -d -n irc irssi

# Создать окно с именем superserver и командой ssh root@superserver.com
neww -d -n superserver ssh root@superserver.com

# Создать окно с именем anotherserver и командой ssh root@123.123.123.123
neww -d -n superserver anotherserver root@123.123.123.123

Данная конфигурация позволяет автоматически создавать несколько окон при запуске, в которых сразу запускаются SSH-сессии. При этом не требуется вручную создавать новую сессию командой tmux new, достаточно всегда вводить tmux attach. Если сессия до этого не существовала, она будет создана.

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

Для этого добавим в конец файла ~/.bashrc запуск tmux. Важно помнить, что такая конструкция будет работать только с конфигом выше.

if [ ! "$TMUX" ]; then
 tmux attach
fi

if [ "$TMUX" ]; then
 export TERM=screen
fi

Это простое условие означает, что если мы не в tmux, то подключаемся к нему.
На этом конфигурация tmux на терминальном сервере закончена. Отныне для каждого нового SSH-подключения мы будем создавать отдельное окно в tmux. И даже если соединения с терминальным сервером будет потеряно, все SSH-подключения останутся активными.

Mosh — больше никаких разрывов
Теперь нам нужно обеспечить непрерывное соединение с терминальным сервером, которое будет всегда активно. Даже если мы на несколько дней закрыли ноутбук и открыли его в другой wifi-сети, соединение должно восстанавливаться само.

Mosh — надстройка над обычным OpenSSH сервером, которая позволяет забыть о разрывах соединения. Mosh авторизуется по обычному SSH, после чего поднимается отдельный UDP-канал, который мгновенно восстанавливается после разрыва, даже если у вас сменился внешний IP-адрес.
Так как нам нужно держать постоянное подключение к терминальному серверу, мы установим mosh только на сервер и на наш рабочий компьютер. При этом на удалённые серверы ничего устанавливать не потребуется, так как подключения к ним и так уже живут вечно в tmux.

Устанавливаем mosh на сервер:

apt install mosh

Устанавливаем mosh на наш рабочий компьютер. Он доступен для всех основных операционных систем, но нативный клиент есть только для Unix-подобных операционных систем. Версия для Windows реализована с помощью Cygwin либо приложения Chrome.

Я использую macOS, и устанавливаю mosh через пакетный менеджер brew:

brew install mosh

В большинстве случаев mosh не требует дополнительной настройки и работает прямо из коробки. Достаточно вместо команды ssh написать mosh:

mosh user@my-server.com

Для нестандартных конфигураций команда выглядит чуть сложнее. Например, если нужно указать порт и путь к ключу:

mosh --ssh="ssh -p 2222 -i /path/to/ssh.key" user@my-server.com

Первичную аутентификацию mosh выполняет как обычный SSH-клиент, авторизуясь на стандартный порт 22. При этом mosh-сервер изначально не слушает никаких портов, и кроме оригинального демона OpenSSH наружу никаких портов на сервере не открыто. После подключения по TCP, mosh запускается на сервере в юзерспейсе и открывает дополнительный тоннель по UDP.


Теперь запущенная на клиенте сессия mosh будет всегда восстанавливаться при появлении интернета. На своем ноутбуке я держу открытой одну сессию mosh месяцами без перезапуска и мне не приходится постоянно заново логиниться на терминальный сервер, он просто всегда работает.

Чтобы каждый раз не вводить длинную команду подключения к терминальному серверу, я сделал алиас команды подключения из одной буквы:

alias t='mosh --ssh="ssh -p 443 -i /path/to/ssh.key" user@my-server.com'

Заключение
Эта простая схема позволяет значительно сэкономить время и нервы, не терять результат работы при обрыве SSH. Мне постоянно приходится видеть, как начинающие админы начинают каждый раз заново логиниться на свои сервера и убивать залипшие SSH-сессии.
Возможно, на первый взгляд это покажется слишком запутанным, но я уверяю вас, стоит себя один раз пересилить и привыкнуть, как вы начнете смотреть со снисходительным сожалением на тех, у кого до сих пор ломаются SSH-подключения.

https://vdsina.ru

TL;DR В статье описывается самый простой способ настроить VPN-сервер, у которого IP-адрес для подключения VPN-клиентов отличается от IP-адреса, с которого клиенты выходят в интернет.

Используете VPN для защиты приватности в интернете и арендуете для этого свой личный сервер? При этом вы единственный клиент, который подключается к этому серверу во всем мире? Так ли сложно найти ваш реальный IP-адрес, как вам кажется? С вступлением в силу пакета Яровой, это становится намного проще.

Double VPN — популярная тема, вокруг которой много спекуляций. Часто этим термином называют совершенно разные технологии, но почти всегда это означает разнесенные на уровне IP-адресов точки подключения и выхода в интернет. Мы рассмотрим самый простой способ настройки VPN-сервера в таком режиме, который не требует дополнительной настройки на серверной стороне и позволяет получить максимальную скорость и самые низкие задержки.

Модель угроз
Для того, чтобы от чего-то защищаться, нужно четко понимать модель угроз. Мы не будем рассуждать о новых законах, требующих от провайдеров хранить весь трафик клиентов, но совершенно точно можно сказать, что данные о подключениях, т.н. Netflow, хранить достаточно просто, и это давно и успешно делается. То есть факт подключения условного IP-адреса 1.1.1.1 к адресу 2.2.2.2 в определенное время суток записывается.

Имея доступ к такой информации в масштабах провайдера, города или страны, достаточно просто установить, кто именно скрывается за VPN.

Чтобы повысить уровень приватности при использовании VPN, необходимо разделить точку подключения и точку выхода в интернет на уровне IP. На картинке выше наш пользователь находится за забором под пристальным вниманием Ирины Яровой. Все подключения, проходящие через забор, Ирина строго запоминает. Пользователь, как порядочный гражданин, подключается к адресу good.citizen.vpn, при этом назад он возвращается уже с адреса super.cool.guy.vpn. В итоге для Ирины эти два подключения выглядят не связанными между собой.

Какие бывают двойные VPN
Под названием «двойной» VPN часто понимают разные вещи, но почти всегда это значит разнесенные территориально или на сетевом уровне узлы подключения и выхода в интернет. Иногда это просто маркетинговый трюк VPN-провайдеров, который не значит абсолютно ничего, такие услуги могут называться «тройным» и «четверным» VPN.

Мы разберём самые типовые схемы, которые применяют на практике.

VPN между серверами
Самый распространенный способ. В таком режиме клиент устанавливает VPN-подключение к только первому серверу. На первом сервере настроен тоннель ко второму, и весь трафик от клиента уходит ко второму серверу, и так далее. Промежуточных серверов может быть несколько. При этом тоннель между серверами может быть установлен по любому другому протоколу, отличному от протокола, по которому подключен клиент, например IPsec, или вообще без шифрования, вроде GRE или IPIP. В таком режиме все промежуточные сервера может быть видно в трассировке маршрута. Проверить, как именно подключены между собой промежуточные сервера на стороне клиента нет возможности, поэтому можно только доверять провайдеру.

На всём пути следования трафика минимальный MTU (Maximum transmission unit) остаётся равным значению самого первого тоннеля, и каждый промежуточный сервер имеет доступ к расшифрованному трафику клиента.

VPN через прокси

Тоже достаточно распространённый способ. Часто используется для маскирования VPN-трафика под другой протокол, например в Китае. Такой способ удобнее цепочки из проксей, потому что с помощью VPN легко маршрутизировать весь системный трафик в тоннель. Существуют также инструменты для перехватывания системных вызовов программ и перенаправления их в прокси: ProxyCap, Proxifier, но они менее стабильны, так как иногда пропускают запросы и они уходят мимо прокси или работают некорректно с некоторыми программами.

В этом режиме прокси-сервер не видно в трассировке маршрута.


VPN внутри VPN
Самый параноидальный и медленный способ: все тоннели поднимаются на стороне клиента, при этом каждый внутри другого. Такой способ требует хитрой настройки маршрутов на стороне клиента и запуска всех VPN-клиентов в нужном порядке. Это плохо сказывается на задержках и производительности, зато промежуточные сервера не имеют доступа к открытому трафику клиента. Все накладные расходы по инкапсуляции суммируются, и максимальный размер пакета (MTU), доступный в итоге клиенту, уменьшается в зависимости от числа тоннелей. Промежуточные сервера не видны в трассировке маршрутов.


Настройка VDS
Самый лёгкий способ настроить VPN с разделёнными точками входа и выхода — подключить несколько IP-адресов на один виртуальный сервер. Этот способ позволяет получить максимальную скорость и минимальные задержки, так как по сути трафик терминируется на одном сервере. У нас, в Vdsina.ru вы можете это сделать самостоятельно из панели управления. В то время как IPv4 везде кончаются, мы выдаем дополнительные IP-адреса даже на серверах за 60 рублей!

Разберем поэтапно настройку сервера.

Выбираем сервер
Заказываем VDS с подходящим тарифом, в нужном датацентре. Учитывая нашу задачу, выберем датацентр подальше, в Нидерландах ;)


Подключаем дополнительный IP-адрес
После покупки дополнительного IP-адреса его нужно настроить по инструкции.


Для наглядности назначим PTR-запись на IP. Это доменное имя, которое будет видно при обратном преобразовании IP-адреса в домен. Это может быть любое значение, в том числе несуществующий домен.

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

xxx.xxx.38.220 — super.cool.guy.vpn # внешний адрес (точка выхода)
xxx.xxx.39.154 — good.citizen.vpn # адрес подключения (точка входа)

Проверка двух IP
Важно помнить, что тот IP-адрес, который был установлен на сервере изначально, будет точкой выхода, соответственно новый адрес будет точкой входа. Подключимся по SSH к серверу и проверим, какой адрес используется в качестве внешнего.

Для этого проще всего из консоли использовать сервис ifconfig.co. При запросе через curl он возвращает IP-адрес, с которого был сделан запрос.

$ curl ifconfig.co
xxx.xxx.38.220

По последним цифрам видно, наш внешний адрес действительно соответствует точке выхода. Попробуем проверить корректность работы второго IP в качестве точки входа. Для этого просто используем встроенную в SSH функцию SOCKS-прокси.

Команды выполняются на клиенте:

ssh -D 9999 root@good.citizen.vpn

# в новом окне
curl -x socks5h://127.0.0.1:9999 ifconfig.co
super.cool.guy.vpn

Первая команда устанавливает SSH-сессию с адресом good.citizen.vpn и одновременно активирует SOCKS-прокси внутри этой сессии, который доступен на локальном порту. Вторая делает обычный HTTP-запрос через этот прокси.

Важно помнить, что в наших примерах для запросов используются выдуманные доменные имена. Они будут отображаться только при PTR-резолве, и полноценный запрос к ним сделать не получится. Поэтому на данном этапе обращаться к серверу нужно через IP-адрес.

Настройка сервера IKEv2


IPsec IKEv2 — современный протокол VPN, поддерживаемый почти всеми операционными системами из коробки. Он используется как протокол по-умолчанию в Windows, macOS и iOS. При этом не требует установки стороннего ПО и работает в большинстве случаев быстрее OpenVPN. На хабре уже были статьи по настройке сервера IKEv2, но все они описывают использование самоподписанных сертификатов, и неудобны тем, что требуют установить корневой сертификат на стороне VPN-клиента.

Мы же разберем пример настройки сервера с использованием доверенного сертификата от Let's Encrypt. Это позволяет не устанавливать клиенту посторонние корневые сертификаты, а выдать только логин и пароль.

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

Обновляем систему и устанавливаем нужные пакеты

apt update && apt upgrade

apt install certbot strongswan libstrongswan-extra-plugins

Выпуск сертификата
Для выпуска доверенного сертификата вам потребуется направить реальный домен на IP-адрес точки входа. Мы не будем рассматривать этот пункт подробно, так как он выходит за рамки статьи. В качестве примера мы будем использовать вымышленный домен good.citizen.vpn

Если у вас на сервере уже есть есть веб-сервер, используйте подходящий способ выпуска сертификата через certbot или другой клиент для Let's Encrypt. В данном примере предполагается, что порт HTTP (80) ничем не занят.

certbot certonly --standalone --agree-tos -d good.citizen.vpn

Ответив на вопросы мастера? мы получим подписанный сертификат и ключ

# find /etc/letsencrypt/live/good.citizen.vpn/

/etc/letsencrypt/live/good.citizen.vpn/
/etc/letsencrypt/live/good.citizen.vpn/fullchain.pem
/etc/letsencrypt/live/good.citizen.vpn/README
/etc/letsencrypt/live/good.citizen.vpn/cert.pem
/etc/letsencrypt/live/good.citizen.vpn/privkey.pem
/etc/letsencrypt/live/good.citizen.vpn/chain.pem

Для проверки подлинности IKEv2 сервера используются те же X.509-сертификаты, что и для
HTTPS. Чтобы Strongswan смог использовать эти сертификаты, их нужно скопировать в папку /etc/ipsec.d.

Вот как должны быть расположены сертификаты:

cp /etc/letsencrypt/live/good.citizen.vpn/cert.pem /etc/ipsec.d/certs/
cp /etc/letsencrypt/live/good.citizen.vpn/privkey.pem /etc/ipsec.d/private/
cp /etc/letsencrypt/live/good.citizen.vpn/chain.pem /etc/ipsec.d/cacerts/

Так как сертификаты letsencrypt перевыпускаются часто, делать это вручную неудобно. Поэтому автоматизируем этот процесс с помощью хука для certbot.

Задача скрипта скопировать три файла в нужную папку каждый раз, когда сертификат обновился, и после этого послать команду strongswan перечитать сертификаты.

Создадим файл /etc/letsencrypt/renewal-hooks/deploy/renew-copy.sh и сделаем его исполняемым.

#!/bin/sh

set -e

for domain in $RENEWED_DOMAINS; do
        case $domain in
        good.citizen.vpn)
                daemon_cert_root=/etc/ipsec.d/

                # Make sure the certificate and private key files are
                # never world readable, even just for an instant while
                # we're copying them into daemon_cert_root.
                umask 077

                cp "$RENEWED_LINEAGE/cert.pem" "$daemon_cert_root/certs/"
                cp "$RENEWED_LINEAGE/chain.pem" "$daemon_cert_root/cacerts/"
               cp "$RENEWED_LINEAGE/privkey.pem" "$daemon_cert_root/private/"

                 # Reread certificates
                /usr/sbin/ipsec reload
                /usr/sbin/ipsec purgecerts
                /usr/sbin/ipsec rereadall
                ;;
        esac
done

Теперь после каждого перевыпуска сертификата скрипт будет копировать новые файлы в папки strongswan-а и посылать команду демону перечитать сертификаты.

Настройка Strongswan
Добавим конфиг strongswan /etc/ipsec.conf

config setup

    #  Разрешить несколько подключений с одного аккаунта
    uniqueids=no

    # Increase debug level
    # charondebug = ike 3, cfg 3

conn %default

    # Универсальный набор шифров для большинства платформ
    ike=aes256-sha256-modp1024,aes256-sha256-modp2048

    # Таймауты "мёртвых" подключений
    dpdaction=clear
    dpddelay=35s
    dpdtimeout=2000s

    keyexchange=ikev2
    auto=add
    rekey=no
    reauth=no
    fragmentation=yes
    #compress=yes

    # left - local (server) side
    leftcert=cert.pem # Имя файла сертификата в папке /etc/ipsec.d/certs/
    leftsendcert=always
    # Маршруты отправляемые клиенту
    leftsubnet=0.0.0.0/0

    # right - remote (client) side
    eap_identity=%identity
    # Диапазон внутренних IP-адресов назначаемых VPN-клиентам
    rightsourceip=10.0.1.0/24
    rightdns=8.8.8.8,1.1.1.1

 # Windows and BlackBerry clients usually goes here
conn ikev2-mschapv2
    rightauth=eap-mschapv2

# Apple clients usually goes here
conn ikev2-mschapv2-apple
    rightauth=eap-mschapv2
    leftid=good.citizen.vpn

Логины и пароли VPN-клиентов задаются в файле /etc/ipsec.secrets

В этом файле также нужно указать имя приватного ключа, который мы ранее копировали из папки letsencrypt:

# Имя файла приватного ключа в папке /etc/ipsec.d/private/
: RSA privkey.pem

# Пользователи VPN
# имя : EAP "Пароль"
IrinaYarovaya : EAP "PleaseLoveMe123"
Mizooleena : EAP "IwannaLoveToo3332"

На данном этапе можно перезапустить сервер strongswan и проверить, активировался ли новый конфиг:

$ systemctl restart strongswan

$ ipsec statusall
Virtual IP pools (size/online/offline):
  10.0.1.0/24: 254/0/0
Listening IP addresses:
 xxx.xxx.38.220
Connections:
ikev2-mschapv2:  %any...%any  IKEv2, dpddelay=35s
ikev2-mschapv2:   local:  [CN=good.citizen.vpn] uses public key authentication
ikev2-mschapv2:    cert:  "CN=good.citizen.vpn"
ikev2-mschapv2:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-mschapv2:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
ikev2-mschapv2-apple:  %any...%any  IKEv2, dpddelay=35s
ikev2-mschapv2-apple:   local:  [good.citizen.vpn] uses public key authentication
ikev2-mschapv2-apple:    cert:  "CN=good.citizen.vpn"
ikev2-mschapv2-apple:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-mschapv2-apple:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear

Можно видеть, что конфиг успешно активирован и сертификат подключен. На данном этапе уже можно подключаться к VPN-серверу, но он будет без доступа к интернету. Чтобы выпустить клиентов в интернет, нужно включить форвардинг и настроить NAT.

Настройка NAT
Активируем форвардинг пакетов:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

Включаем NAT. Важно иметь в виду, что это просто пример минимальной конфигурации iptables. Настройте остальные правила в зависимости от ваших потребностей.

ethName0 — замените на свое имя интерфейса
10.0.1.0/24 — диапазон IP-адресов который будет выдаваться VPN-клиентам. Мы задавали его в /etc/ipsec.conf
111.111.111.111 — IP-адрес точки выхода, в нашем примере это адрес super.cool.guy.vpn

iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o ethName0 -j SNAT --to-source 111.111.111.111

Отладка
На данном этапе настройки мы должны получить полностью работающий сервер, к которому уже могут подключаться клиенты. Перед продолжением лучше убедиться в этом, проверив подключение.

В случае проблем с подключением можно смотреть лог в реальном времени:

journalctl -f -u strongswan

Автозапуск при загрузке
Если всё успешно, можно добавить strongswan в автозапуск при загрузке:

systemctl enable strongswan

Сохранение правил iptables
Чтобы сохранить правила iptables после перезагрузки, существует специальный пакет iptables-persistent. Важно помнить, что он сохранит текущий набор правил и добавит его в автозагрузку.

apt install iptables-persistent

Итог
Мы показали самый простой вариант настройки сервера с разнесенными точками входа и выхода. Такая конфигурация позволяет получить максимальную скорость VPN, так как не использует дополнительные тоннели между серверами, при том, что IP-адреса точек входа и выхода находятся в разных подсетях. Такой подход позволяет экспериментировать и дальше, подключив к серверу более двух IP-адресов.

Протокол IKEv2 прекрасно подходит для использования его на десктопных ОС для каждодневной работы, так как максимально нативно интегрирован в систему и при прочих равных, позволяет получить бОльшую скорость, чем через сторонние программы VPN.

https://vdsina.ru

Мало хостеров предлагает тарифы VDS с высокой тактовой частотой процессора, хотя кажется, что всё просто: вставил в сервер i9 помощнее, настроил биллинг и готово.

Когда мы готовили тарифы Hi-CPU, то выяснили, что:

• серверы с i9 потребляют тонны электричества
• поймать баланс и сделать выгодный тариф на качественном железе непросто
• ЦОДы предпочитают с таким не связываться

Рассказываем, как мы справились с этим и запустили Hi CPU.

Зачем нужен Hi-CPU
Мы готовили идеальный тариф под Битрикс. Почему?
Конечно, из-за денег.


По данным CMS iTrack, половина всех сайтов, сделанных на CMS — WordPress и лишь 11,68% сайтов используют Битрикс. Однако по рейтингу CMS Magazine, коммерческих сайтов использующих Битрикс в два раза больше, чем WordPress. Большая часть сайтов на WordPress — блоги, личные сайты и прочие визитки.

Битриксом пользуются тысячи российских компаний, готовые платить за качественный VDS. И многим нужны Hi-CPU решения, которых на рынке не хватает: чаще всего, хостеры предлагают тарифы с частотой процессора 2-3 гигагерца — подходят для повседневных задач, но для скоростной обработки множества мелких уже недостаточно. Особенно, если хостер не борется с оверселлом процессорного времени.

Так что верным способом стать качественным Битрикс-хостингом было сделать выгодный Hi-CPU тариф и стать featured-partner — попасть в рейтинг рекомендуемых хостеров, который составляет сам Битрикс.

Подготовка: первоначальное тестирование
Для начала мы проверили, сколько Битрикс-попугаев выдает сборка на стандартном тарифе. Процессор — Intel Scalable Xeon Silver 4116. Получили 107 попугаев.


Intel Scalable Xeon Silver 4116 неплохо справляется с типичными VDSовскими задачами, но для Битрикса нужно что-то помощнее, особенно, если цель — попасть на вершину рейтинга.


Поиск мощного железа для попугаев
Первое, что надо сделать — взять процессор с большей частотой: в основном растит попугаев именно частота процессора.

Сначала рассматривали самосбор на основе Intel Core i9-9900K S1151. Некоторые коллеги так и делают и попугаев у них выходит даже больше, чем на серверных процессорах. Однако, как мы упоминали, топовые i9 и сборки на их основе потребляют столько энергии, что пришлось бы либо задрать цену, либо разориться на счетах за электричество. Да и ЦОД был не в восторге: потребовал организовать дополнительное охлаждение стоек и инженеров для настройки и обслуживания самосбора (и дополнительное охлаждение инженеров).

Учитывая риски, отсутствие гарантии и в целом десктопную начинку, от самосбора оказывалось больше проблем, чем пользы.

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

Оптимальным вариантом показалось найти MicroCloud в 3U. По сути, это 12 серверов в одном, что позволяет в 4 раза экономить место в стойке при той же производительности. Серверы выбирали в ноябре 2018 года и тогда решений в 3U было не так уж много, выбор почти сразу пал на Supermicro SuperServer 5039MS-H12TRF.


Он состоит из двенадцати отдельных нод


Каждая нода это по сути отдельный сервер. У нас другая сборка, чем на картинке, но принцип тот же.

Сердцем выбрали Intel Xeon E3-1270 v6. Опирались на опыт: мы уже использовали этот процессор на платформе Dell R330 для других высоконагруженных проектов. E3-1270 ещё ни разу не подводил, цена и качество нас устраивали.

Для начала купили только один Microcloud: он стоит в районе 20 тысяч долларов, а свободных денег было не так много. Оно и к лучшему: на рынке постоянно появляются новые, более эффективные и недорогие решения. К тому моменту, как появились деньги на новый сервер, мы проанализировали рынок заново.

Первая проблема при установке
Первый MicroCloud доставили через неделю после заказа. Уже в ЦОДе оказалось, что он не помещается в стойку. Мы хотели поставить его к серверам 1U, но направляющие в стойке расположены так, что Microcloud банально не входил. Чтобы его поместить, пришлось бы устроить даунтайм для других серверов и сдвинуть направляющие.

Решили повременить с запуском и поставить Microcloud в новую стойку. Это оказалось оптимальным решением: энергопотребление и тепловыделение у MicroCloud отличается от обычных серверов. Да и сетевое оборудование со своими особенностями.


В MicroCloud планировали установить десяти-гигабитные сетевые карты, чтобы как следует разогнать миграцию VDS-контейнеров. Этот трюк мы уже проделывали с 1U серверами, но с MicroCloud всё оказалось сложнее.

Десяти-гигабитные сетевые карты для MicroCloud серверов оказались большой редкостью. Мы заказывали Low Profile AOM-CTGS-i2TM MicroLP, ждали пару месяцев и получили ответ: «извините, производитель редко сталкивается с подобными заказами. Карты будут готовы через полгода». От идеи пришлось отказаться: пока хватает стандартных гигабитных карт, но в будущем мы ещё раз попытаемся купить десяти-гигабитные.

Настройка шаблона и заявка в Битрикс
Изначально мы собрали шаблон с уклоном на Битрикс, но и удобством для остальных CMS: например, добавили нестандартную для Vesta конфигурацию с выбором версии PHP. Всю конфигурацию и оптимизацию делали на схеме apache + mod_fcgi. Параметры подбирали так, чтобы они давали лучший усреднённый результат для всех тарифов.

Производительность Битрикса зависит напрямую от тактовой частоты процессора. В среднем частота процессоров для тарифов Hi-CPU была на 40-50% больше, чем у процессоров, обслуживающих обычные тарифы. Результаты замеров коррелировали: минимум на 30% больше производительности при высокой нагрузке на сервер, около 60% — в «хорошую погоду».



Когда всё отладили, зарегистрировались на сайте для партнеров Битрикса и заполнили заявку, к которой прикрепили данные с VDS с шаблоном, оптимизированным под Битрикс.

Война за первое место в рейтинге
Результаты производительности подтвердились, но итоговая оценка оказалась ниже, чем мы рассчитывали: рейтинг учитывает не только производительность, но и абсолютную стоимость тарифа и наличие тестового периода.


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

Цена и здравый смысл
Другие хостинги отправили заявки со своими самыми дешёвыми тарифам, у которых меньше оперативной памяти, места на SSD и трафика, чем у нашего. Мы же послали заявку с более дорогим тарифом, но более подходящим под нормальную работу Битрикса.

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

Создавая VDSina мы делаем ставку на удобство: регистрация должна проходить на лету, без капчи (от у нас неё изжога), проверки паспортных данных и подтверждения номера телефона. Ввёл почту, пополнил баланс на 30 рублей и VDS разворачивается за 60 секунд — для нас это вопрос принципа.

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

При такой схеме борьбы с халявщиками страдают нормальные клиенты и мы принципиально не хотим грузить их в общем-то нашей проблемой.

Чтобы была возможность потестировать хостинг мы сделали посуточную тарификацию и минимальный платёж в 30 рублей — это практически ничего не стоит клиентам, которые действительно ищут удобный VDS для работы.

Пока наши клиенты довольны таким раскладом и мы тоже.

Тесты производительности наших Hi CPU



Планы на будущее
Недавно к нам пришёл уже четвертый по счету сервер. На этот раз — Supermicro MicroCloud с 12 x Xeon E-2136, 48 x DDR4 16Gb и 12 x 1TB NVME P4510.


Новый MicroCloud уже ввели в эксплуатацию, и теперь мы строим планы по экспансии Hi-CPU в Нидерланды и другие страны. У нас работают серверы для обычных тарифов в двух нидерландских ЦОДах, но когда встаёт вопрос о чём-то посложнее 1U-сервера, то приходится пройти через 9 кругов согласований.
Но это уже другая история.

https://vdsina.ru

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

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

Выбор фреймворка: почему искали новый
Предыдущая панель была реализована на собственном фреймворке, написанном на jQuery. Мы сидели на VMManager, он требовал много доработок: по интерфейсу и функционалу, было тяжело сопровождать такой код. Добавление нового функционала в панель со стороны фронта занимало много времени. Понятно, что при желании и на jQuery можно реализовать хороший фреймворк (я до сих пор люблю jQuery) или даже подобие CMS, но это был не оптимальный вариант: начиная скудной документацией по самописному фреймворку и заканчивая не совсем корректной архитектурой самого приложения.

Старая панель была реализована в виде Single Page Application и на этом его хорошие качества заканчивались. После решения очередной головоломки по добавлению кнопки в список, пришло понимание, что нужна альтернатива. Выбор пал на Vue.

Почему SPA?
Single Page Application — идеальный выбор для панели управления. Панель управления в плане рендеринга довольно простая штука, эту работу можно легко доверить браузеру пользователя. К тому же панели не важна SEO-оптимизация, для этого у нас есть основной сайт. Ну и требуемое время на начальную загрузку всех необходимых скриптов пользователи панели воспринимают спокойно в силу специфики самих этих пользователей. Опять же, бекенд у нас получился классическим RestAPI сервисом — для предоставления в будущем открытого API нашим клиентам.

SPA приложение получилось таким легким, что хорошо работает с браузера телефонов и планшетов — мы просто сделали адаптивную верстку и создавать отдельное приложение не пришлось.

Почему Vue?
3 года назад Vue был относительно молодым фреймворком, но уже тогда о нем много говорили и писали, и когда вышел релиз версии 2.0, мы решили сделать ставку на него — и не прогадали. Сначала планировали просто постепенно заменять какие-то компоненты написанные на jQuery и Vue это позволял делать легко. Но потом, после того, как были переписаны довольно объемные компоненты, все таки решили, что лучше переписать вообще все приложение на Vue.
Это бы рискованный шаг и мы решили его сделать по 4 причинам:

• Vue — простой декларативный фреймворк, его понимают даже верстальщики. Если что, под него легко найти разработчика или просто научить товарища. А значит у нас не будет проблем с поиском нового разработчика и его вхождением в проект, если меня переедет трамвай (хвала богам, в моем городе их нет).
• Vue объективно хорош для написания SPA приложений.
• У меня перед глазами был опыт развития React и я предположил, что популярность Vue будет расти так же. Сейчас фреймворк входит в TOP-3 популярных JS-фреймворков (это легко проверить поисковым запросом), уступая только React и Angular. У него хорошая поддержка, развитая экосистема и большое комьюнити.
• Скорость разработки. Лично я сразу стал воспринимать Vue как этакий конструктор и разработка на нем идет довольно быстро: если мне нужен, например, компонент выбора даты, скорее всего на Vue он уже существует, свободен в использовании и опробован сообществом. Я просто устанавливаю компонент в проект, пишу тег и все работает. По сути, наша панель состоит на 70-80% из готовых библиотек. Я имею в виду именно использование компонента, а не размер кодовой базы, который можно проверить командой типа: npx intrinsic/loc

При реализации проекта всегда учитываешь его перспективы, особенно перспективы развития. И то, что в экосистеме Vue уже имеются такие инструменты как Weex, Quasar Framework или Nuxt по мне существенно расширяют горизонты развития нашей панели.

На Хабре есть замечательная статья о Vue от его создателя, а я расскажу о некоторых особенностях нашего приложения.

Синхронизация Vuex с сервисом RestAPI
Часть данных глобального хранилища Vuex в нашем приложении синхронизируется с RestAPI путем обыкновенных запросов по соответствующим адресам. Зачем мы так сделали? Ну хотя бы для того, чтобы основные настройки пользователя не были привязаны к конкретному браузеру конкретного устройства. Можно зайти в нашу панель с компьютера жены или из игрового клуба и при этом получить в то же знакомое окружение, что и было у вас на своей родной машине.

Кроме того, когда синхронизация была только с localStorage, некоторые браузеры при обновлениях теряли содержимое localStorage — оно полностью удалялось. Да и в последнее время прослеживается какая то тенденция к ужесточению политики хранения данных пользователей в куках, например функция в WebKit Intelligent Tracking Prevention — не ровен час они доберутся и до localStorage.

Шина событий
Да, мы используем глобальную шину событий. Как и в любом другом крупном приложении с множеством компонентов, рано или поздно возникает необходимость наладить взаимодействие между не связанными между собой компонентами. Даже через глобальное хранилище. Понятно, что если есть связь родитель-потомок, их взаимодействие стандартно организуется через свойства props в одну сторону и методом $emit в другую, ну или через хранилище, как и описано в рекомендациях Vue.

Но в документации описана и возможность использования глобальной шины событий. У нас в проекте куча форм с разными наборами полей и в некоторых случаях (их немного, но все из них принципиальные) нужно как-то по особенному реагировать на изменение значения поля. Хранить в глобальном хранилище значения всех полей каждой формы не имеет смысла:

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

Поэтому я решил использовать механизм шины событий. При этом ничто не мешает использовать свой Event emitter — главное использовать этот механизм аккуратно, только для исключительных ситуаций и тщательно все подчищать за собой.

Взаимодействие RestAPI с панелью
Для большей отзывчивости интерфейса в старом jQuery-фреймворке обратная связь от RestAPI к клиентскому приложению эмулировалась через хитрую систему таймеров: она производила опросы RestAPI с определенным интервалом и перерисовывала узлы DOM, которые затронули изменения.

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

Для решения этой проблемы в новой панели я решил использовать связку из модуля Nchan для веб сервера Nginx и новых возможностей HTML5-интерфейсов — EventSource и WebWorker.

Модуль Nchan поддерживает отправку сообщений через Websocket, EventSource и Long-Polling. Я провел несколько тестов и решил использовать EventSource: сообщения могут быть только текстовыми и поток сообщений осуществляется только в одну сторону (от сервера). Это полностью решало поставленную задачу.

Сейчас работу интерфейса EventSource осуществляет в отдельном фоновом потоке WebWorker, независимо от активности вкладки. В этом же потоке организована примитивная очередь сообщений, чтобы ничего не потерялось. Очередь отправляется в основной поток приложения, который свою очередь производит необходимые перерисовки интерфейса, когда ему удобно и позволяет браузер.

Бэкдоры: как и зачем я проверяю безопасность компонентов
Перед подключением библиотеки ее обязательно проверить на безопасность: был случай, когда компонент специально внедрили бэкдор, который позволял заходить на сайт и скачивать данные.

Но чаще дыры в безопасности появляются скорее по неаккуратности разработчиков. В маркетах приложений есть команда, которая проверяет компоненты на безопасность, но она не слишком зубастая и библиотеки лучше проверять вручную.

Я всегда проверяю пакеты на наличие хуков preinstall, install и postinstall в поле “scripts” файла “package.json”. Кроме того, использую статические анализаторы пакетов, такие как retire, snyk и команду “audit” пакетного менеджера npm.

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

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

После того, как пакет прошел анализ, я обязательно фиксирую его версию. Если нужна другая версия — пакет проходит анализ заново. Да, это занимает время, но оно того стоит.

Пока бэкдоры ни разу не попадали к нам на продакшн.

Много-много комментариев
Как я уже говорил, Vue был выбран за простоту и декларативность. В дополнение к этому я пишу много комментариев, практически к каждой строчке: чтобы в случае чего новый разработчик мог легко войти в проект и чтобы я сам легко возвращался к старым кускам кода.

За что я полюбил новый фронтенд и панель в целом

• Стало проще поддерживать код

Разработка заняла полгода. Теперь я скорее занимаюсь поддержкой панели, свой код не жмет и не натирает.

Клиенты могут быстро получать то, что запрашивали


Стало быстро и удобно добавлять новые функции, которые появились в бекенде: например, оплату для юридических лиц я добавил за 2 дня, снепшоты — за 1 день.

https://vdsina.ru

Завоз железа. Засетапили новую партию железа в лучшем дата-центре Москвы — DataPro. В данный момент доступны: Стандартные серверы vdsina.ru/pricing (CPU 3.2 GHz), Hi-CPU vdsina.ru/pricing/hi-cpu-vds (CPU 4.5 GHz), Выделенные серверы vdsina.ru/pricing/dedicated-server (CPU 4.2 GHz).



500(!!!) Мбит/сек скорость подключения КАЖДОГО сервера (VDS / VPS / cloud / instance / хуинстанс) клиента сверх-хостинга серверов на ЛЮБОМ ТАРИФЕ! Это невероятно, НО в стоимость тарифов входит защита от ddos-атак!

vdsina.ru/tech/api
https://vdsina.ru

Мы «Хостинг технологии» и 5 лет назад запустили VDSina — первый vds хостинг, созданный специально для разработчиков. Мы стремимся сделать его удобным, как DigitalOcean, но с русской поддержкой, способами оплаты и серверами в России. Но DigitalOcean это не только надежность и цена, это еще и сервис.

Софт от ISPsystem оказался веревкой, которая связывала нам руки на пути к крутому сервису. Три года назад мы использовали биллинг Billmanager и панель управления серверами VMmanager и быстро поняли, что оказывать хороший сервис без своей панели практически нереально.

Как ISPsystem убивал удобство
Баги
Мы не могли сами пофиксить баг — каждый раз приходилось писать в чужую поддержку и ждать. Решение любой проблемы требовало реакции сторонней компании.

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

Угроза даунтаймов
Обновления могли порождать непрогнозируемые даунтаймы, которые провоцировали новые ошибки.

Каждый апдейт был лотереей: приходилось прикрывать биллинг и приносить жертвы богам обновлений — пару раз апдейт вызывал даунтайм на минут 10-15. Наши админы в это время седели на глазах — мы никогда не знали, сколько продлится даунтайм и не могли спрогнозировать, когда ISPsystem решит выпустить новый апдейт.

На пятом поколении Billmanager стало получше, но чтобы получить доступ к необходимым фичам пришлось ставить бету, которая уже обновлялась каждую неделю. Если что-то ломалось, приходилось давать доступ чужим разработчикам, чтобы они что-то поправили.

Неудобный интерфейс панели
Всё было разделено на разные панели и управлялось из разных мест. Например, клиенты платили через Billmanager, а перезагружать или переустанавливать VDS им приходилось в VMManager. Нашим сотрудникам тоже приходилось переключаться между окнами, чтобы помочь клиенту, проверить нагрузку на его сервере или посмотреть, какую ОС он использует.

Такой интерфейс отнимает время — и наше, и клиентов. Ни о каком удобстве, как у DigitalOcean, в такой ситуации речи не идёт.

Короткие лайфциклы с частым обновлением API
Мы писали собственные плагины — например, плагин с дополнительными способами оплаты, которых нет в VMManager.

В последние годы у VMManager был относительно короткий жизненный цикл, причем в новых версиях могли произвольно меняться названия переменных или функций в API — это ломало наши плагины. Поддержку старых версий быстро сворачивали и приходилось обновляться.

Нельзя дорабатывать
Точнее можно, но крайне неэффективно. Лицензионные ограничения не дают вносить изменения в исходники, можно только писать плагины. Максимум плагинов — какие-то элементы меню, пошаговый мастер. ISPsystem заточены на универсальность, а нам нужны были специализированные решения.

Так созрело решение написать свою панель. Мы поставили цели:

• Быстро реагировать на ошибки, баги и иметь возможность самостоятельно устранять их, не заставляя клиента ждать.
• Свободно модифицировать интерфейс под рабочие процессы и нужды клиента.
• Повысить юзабилити чистым и понятным дизайном.

И начали разработку.

Архитектура новой панели
У нас есть самодостаточная команда разработки, так что панель мы написали сами.
Основную работу проделали три инженера — технический директор Сергей придумал архитектуру и написал серверный агент, Алексей сделал биллинг, а фронтенд собрал наш фронтендер Артыш.

Шаг 1. Серверный агент
Серверный агент — это веб-сервер на питоне, который управляет библиотекой libvirt, которая, в свою очередь, управляет гипервизором Qemu-kvm.

Агент управляет всеми услугами на сервере: создание, остановка, удаление vds, установка операционных систем, изменение параметров и так далее через библиотеку libvirt. На момент выхода статьи это больше сорока разных функций, которые мы дополняем в зависимости от задачи и потребностей клиента.

По идее libvirt можно было управлять прямо из биллинга, но это требовало слишком много дополнительного кода и мы решили разнести эти функции между агентом и биллингом — биллинг просто делает запросы агенту через JSON API.

Агент — первое, что мы сделали, поскольку он не требовал никакого интерфейса и тестировать его можно было прямо из консоли сервера.

Что дал нам серверный агент: появилась прослойка, которая упрощает жизнь всем — биллингу не нужно передавать целую кучу команд, а только сделать запрос. А агент сделает все, что нужно: например, выделит место на диске и оперативную память.

Шаг 2. Биллинг
Для нашего разработчика Алекса это была уже не первая панель управления — Алекс в хостинге давно, поэтому он в целом понимал, что нужно клиенту и что нужно хостеру.

Биллинг мы и называем между собой «панелью управления»: в нем не только деньги и услуги, но и управление ими, поддержка клиентов и многое другое.

Для перехода с софта ISPSystem, необходимо было полностью сохранить клиентам предыдущий функционал, перенести все финансовые действия пользователей из старого биллинга в новый, а также все услуги и связи между ними. Мы изучили что есть в текущем продукте, потом решения конкурентов, в основном DO и Vultr. Посмотрели на недостатки и преимущества, собрали отзывы людей, которые работали со старыми продуктами от ISPsystem.

В новом биллинге использовали два стека: классический PHP, MySQL (а в будущем планируется перейти на PostgreSQL), Yii2 в качестве фреймворка на бекэнде и VueJS на фронте. Стеки работают независимо друг от друга, разрабатываются разными людьми, а общаются с помощью JSON API. Для разработки тогда и сейчас мы используем PHPStorm и WebStorm от JetBrains и нежно их любим (ребята, привет!)

Панель спроектирована по модульному принципу: модули платёжных систем, модуль регистраторов доменов или, например, модуль SSL-сертификатов. Можно легко добавить новую функцию или убрать старую. Задел на расширение заложен архитектурно, в том числе и в обратную сторону, «к железу».

Что мы получили: панель управления, над которой у нас полный контроль. Теперь баги правятся за часы, а не недели, а новые функции реализовываются по просьбе клиентов, а не по желанию ISPSystem.

Шаг 3. Интерфейс
Интерфейс — наше командное детище.


Сначала мы посмотрели, что будет, если сделать надстройку над API ISPsystem, ничего кардинально не меняя в интерфейсе. Вышло так себе и мы решили всё сделать с нуля.

Мы верили, что главное — сделать интерфейс логичным, с чистым и минималистичным дизайном и тогда получим красивую панель. Расположение элементов обсуждали в Мегаплане и постепенно родится тот интерфейс, который пользователи видят в панели управления сейчас.

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

Фронтенд
Панель решили сделать SPA приложением — нетребовательной к ресурсам и с быстрой загрузкой данных. Наш фронтендер Артыш решил писать ее на Vue — на тот момент Vue только появился. Мы предположили, что фреймворк будет развиваться динамично, как React, через какое-то время коммьюнити Vue разрастется и появится море библиотек. Мы поставили на Vue и не пожалели — теперь добавить на фронт новые функции, которые уже запрограммировали на бекенде занимает мало времени. Подробнее про фронтенд панели мы расскажем в отдельной статье.

Связь фронтенда с бекендом
Фронтенд связали с бекендом через пуши. Пришлось попотеть и написать собственный обработчик, но теперь обновление информации на странице происходят почти моментально.

Что получилось: интерфейс панели стал проще. Мы сделали ее адаптивной, а быстрая прогрузка позволяет пользоваться ей даже с мобильников в последние минуты перед взлетом, не устанавливая отдельное приложение для работы с панелью.

Шаг 4. Тестирование и схема миграции
Когда все завелось и прошли первые тесты, встал вопрос миграции. Первым делом мы поставили биллинг и начали тестировать его работу с серверным агентом.

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

Приходилось тестировать и перепроверять буквально все, так как данные сливали в одну новую базу из трёх старых: Billmanager, VMmanager и IPmanager менеджера. Пожалуй, тестовые миграции — самое сложное, с чем мы столкнулись в процессе разработки новой панели.

После перепроверок, мы прикрыли старый биллинг. Финальная миграция данных была очень тревожным моментом, но, слава Богу, выполнилась за несколько минут и без заметных проблем. Были мелкие баги, которые мы чинили в течение недели. Основное время заняло тестирование того, что получилось.

Затем мы разослали письма клиентам с адресом новой панели и биллинга и сделали редирект.

В итоге: IT’S ALIVE!

Хэппиэнд
С первых часов работы своего софта мы почувствовали все прелести перехода. Код был полностью наш и с удобной архитектурой, а интерфейс — чистым и логичным.
Первый отзыв после запуска новой панели


Мы запустили процесс перехода в декабре, накануне Нового 2017 года, когда нагрузки было меньше всего, чтобы сделать переход проще для клиентов — почти никто не работает накануне праздников.

Главное, что мы получили при переходе на свою систему (кроме общей надежности и удобства) — возможность быстро добавлять функционал под ключевых клиентов — быть к ним лицом, а не задницей.

Что дальше?
Мы растём, растёт количество данных, клиентов, данных клиентов. На бекенд пришлось добавить Memcached-сервер и два менеджера очередей с разными задачами. На фронтенде есть кэширование и свои очереди.

Конечно, у нас еще были приключения по мере разработки и усложнения продукта, например, когда мы добавляли HighLoad.

В следующей статье расскажем, как запускали Hi-CPU тариф: про железо, ПО, какие задачи мы решали и что у нас получилось.

vdsina.ru

Стоимость лицензии включена в тарифы.


https://vdsina.ru