Рубрика: Новости компании

Сегодня поговорим о том, как построить отказоустойчивую быструю защищенную корпоративную сеть передачи данных на OS Debian.

Итак: VxLAN ethernet-туннель поверх IP-туннеля WireGuard с динамическими маршрутами OSPF

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

• VxLAN — технология виртуальной сети, использующая инкапсюляцию L2 Ethernet в UDP-пакеты.
• OSPF — не нуждающийся в представлении протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала и использующий для нахождения кратчайшего пути алгоритм Дейкстры.

В примере будем предполагать, что у нас есть три площадки со своим маршрутизатором на Debian Linux:

1. router01
   • WAN IP: 123.124.125.1
   • LAN: 10.1.1.0/24
2. router02
   • WAN IP: 124.125.126.2
   • LAN: 10.2.2.0/24
3. router03
   • WAN IP: 125.126.127.3
   • LAN: 10.3.3.0/24

Этап 1 — Установка шифрованного туннеля WireGuard

Для установки соответствующего ПО можно обратиться к официальной документации Debian.

В нашей конфигурации можно воспользоваться разными топологиями туннеля.
Например:

1. Подключение многих к одному (клиенты-сервер или звезда)
2. Подключение всех ко всем (ячеистая сеть или mesh)
3. Смешанный тип подключений

В данной статье мы воспользуемся первым вариантом (хотя это и не принципиально).
Сеть туннеля WireGaurd назначим 10.10.10.0/24
Второй и третий маршрутизатор будут подключаться к первому.

На первом маршрутизаторе создадим конфигурацию с подключениями ко второму и третьему:

/etc/wireguard/wg0.conf

[Interface] ListenPort = 4444
PrivateKey = закрытый_ключ_первого_маршрутизатора

Второй маршрутизатор

[Peer] PublicKey = открытый_ключ_второго_маршрутизатора
AllowedIPs = 10.10.10.2/32
Endpoint = 124.125.126.2:4444

Третий маршрутизатор

[Peer] PublicKey = открытый_ключ_третьего_маршрутизатора
AllowedIPs = 10.10.10.3/32
Endpoint = 125.126.127.3:4444

На втором маршрутизаторе создадим конфигурацию с подключением к первому маршрутизатору:

/etc/wireguard/wg0.conf

[Interface] ListenPort = 4444
PrivateKey = закрытый_ключ_второго_маршрутизатора

Первый маршрутизатор

[Peer] PublicKey = открытый_ключ_первого_маршрутизатора
AllowedIPs = 10.10.10.0/24
Endpoint = 123.124.125.1:4444

На третьем маршрутизаторе, также, создадим конфигурацию с подключением к первому маршрутизатору:

/etc/wireguard/wg0.conf

[Interface] ListenPort = 4444
PrivateKey = закрытый_ключ_третьего_маршрутизатора

Первый маршрутизатор

[Peer] PublicKey = открытый_ключ_первого_маршрутизатора
AllowedIPs = 10.10.10.0/24
Endpoint = 123.124.125.1:4444

Далее на всех маршрутизаторах добавим конфигурацию сетевого интерфейса для WireGuard:

/etc/network/interfaces

auto wg0
iface wg0 inet static
address 10.10.10.1/24 # для второго и третьего — 10.10.10.2/24 и 10.10.10.3/24 соответственно
pre-up ip link add $IFACE type wireguard
pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf
post-down ip link del $IFACE

После этого поднимем интерфейсы туннеля на всех маршрутизаторах:

ifup wg0

На этом установка шифрованного туннеля WireGuard закончена.

Этап 2 — Установка виртуальной сети VxLAN поверх WireGuard

Определимся, что виртуальная сеть будет иметь адресацию — 10.20.20.0/24

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

/etc/wireguard/vxpeers (расположение и имя файла не имеет значения)

10.10.10.1
10.10.10.2
10.10.10.3

Далее добавим конфигурацию сетевого интерфейса виртуальной сети VxLAN:

/etc/network/interfaces

auto vxlan0
iface vxlan0 inet static
address 10.20.20.1/24 # для второго и третьего — 10.20.20.2/24 и 10.20.20.3/24 соответственно
pre-up ip link add $IFACE type vxlan id 42 dev wg0 dstport 0
pre-up for peerip in $(cat /etc/wireguard/vxpeers); do \
ip a | egrep «$peerip\/» 2>&1 1> /dev/null || \
bridge fdb append to 00:00:00:00:00:00 dst $peerip dev $IFACE; done
post-down bridge fdb del 00:00:00:00:00:00 dev $IFACE
post-down ip link del $IFACE

И поднимем интерфейс:

ifup vxlan0

Этап 3 — Настройка динамической маршрутизации локальных сетей за маршрутизаторами

Для организации OSPF можно использовать Quagga или FRRouting.

Для FRRouting есть нюанс — после перезапуска конфигурация не применяется.
Чтобы решить эту проблему в файле /etc/frr/daemons надо переменную ospfd_options привести к виду:
ospfd_options=» -A 127.0.0.1 -f /etc/frr/ospfd.conf»

После установки выбранного пакета и активации ospfd подключимся к консоли OSPF:

telnet localhost ospfd

После ввода пароля вводим следующие команды:

enable
configure terminal
hostname router01 # для второго и третьего маршрутизаторов — router02 и router03 соответственно
access-list filter_connected_routes_alist permit 10.1.1.0/24 # для второго и третьего маршрутизаторов — 10.2.2.0/24 и 10.3.3.0/24 соответственно
access-list filter_connected_routes_alist deny any
route-map filter_connected_routes_rmap permit 10
match ip address filter_connected_routes_alist
interface vxlan0
ip ospf mtu-ignore
<Ctrl+D>
router ospf
ospf router-id 10.20.20.1 # для quagga — router-id 10.20.20.1 # для второго и третьего маршрутизаторов — 10.20.20.2 и 10.20.20.3 соответственно
redistribute connected metric 1 route-map filter_connected_routes_rmap
network 10.20.20.0/24 area 0
write memory

После этого выходим из консоли нажатиями Ctrl+D.
Через некоторое время (пол.минуты — минута) демоны ospfd обменяются конфигурацией и добавят динамические маршруты на всех маршрутизаторах.

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

Самое приятное в нашей работе — отзывы благодарных клиентов. Это значит, что мы не напрасно стараемся, а занимаемся полезным делом, которое получается.

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

В этот день основные узлы службы прекратят поддерживать устаревший протокол DNS. Это изменение сделает большинство операций DNS более эффективными и позволит развертывать новые функции, в т.ч. механизмы защиты от DDoS-атак.

Я полагаю, что событие для большинства произойдет незаметно. Тем не менее не лишним будет проверить свой домен здесь https://dnsflagday.net

Сегодня в России утвержден национальный стандарт ГОСТ Р 58305-2018 «Система менеджмента проектной деятельности. Проектный офис». На сайте Росстандарта его пока нет, но скачать можно здесь.

Теперь мы можем адаптировать наш Redmine – система управления проектами» к требованиям Российского ГОСТа.

Автор этой статьи исходит из того, что все читатели уже знакомы с понятием «Менеджмент» (Управление). Хрестоматия учит нас, что это воздействие на объект для достижения цели. Другими словами, управление — это цикличный процесс постоянного получения, обработки и передачи информации. Попробуем рассмотреть как это можно сделать в Redmine.

Рассмотрим классический контур управления:

• Постановка цели;
• Планирование действий;
• Мониторинг и контроль промежуточных результатов;
• Внесения корректирующих действий.

Постановка цели

Итак, на предстоит сформулировать цели для строительства Дворца Спорта, состоящего из двух объектов. При этом сформулировать цели необходимо не абы как, а используя методологию SMART

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

1. Передача Генподрядчику исходной документации
2. Строительство
   1. Площадка
   2. Объект №1
   3. Объект №2
3. Подготовка Исполнительной документации
   1. Объект №1
   2. Объект №2
4. Сдача надзорным органам

В Redmine для стратегического планирования присутствует сущность «Цель». И вот как это выглядит в табличном контексте:

и на диаграмме Ганта

Планирование

Определившись с целями, переходим к планированию действий. В Redmine для этого есть сущность «Задача».

Тут следует сделать лирическое отступление. Дело в том, что сущность «Задача» имеет некоторые свойства, с которыми необходимо познакомиться поближе. Начать с того, что типов сущностей может быть несколько (неограниченное количество) и каждый тип (именуемый «трекер») может быть адаптирован для описания кастомного объекта.

Каждый трекер наделен набором общих (ранее предопределенных полей). В т.ч. Автор, Исполнитель, Статус, Приоритет, Версия, Дата начала и окончания, Готовность (%). Кстати, вывод любого из перечисленных свойств можно подавить.

Но кроме того, каждый трекер может быть наделен дополнительными полями. Вот список распространенных типов дополнительных полей:

• Текст
• Длинный текст
• Дата
• Логический
• Пользователь
• Целый
• С плавающей точкой
• Список
• Список ключ/значение
• Файл
• Ссылка

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

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

В нашем проекте, мы будем использовать два трекера:

1. Задача — для постановки задач стороне исполнителя проекта;
2. Платеж — для постановки задач стороне заказчика (в части предоставление документации, доступов на объекты, оформления необходимых в работе нормативных актов, а также осуществления платежей).

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

Декомпозиция

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

и на диаграмме Ганта

Ресурсный план

При формировании задач важно выстроить не только календарный план работ, но и спланировать все не обходимые ресурсы. Ключевым словом в системе Redmine является слово «все». Т.к. мы имеем возможность создавать любое количество сущностей для учета любых ресурсов. Это могут быть люди, деньги, кубометры, нормочасы, тоннокилометры, да, что угодно в тех единицах, которые вам необходимы.

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

Контроль

Для контроля выполнения задач существует несколько механизмов. Первый из них — создание пользовательских вычисляемых фильтров. Другими словами, вы можете сами сформулировать критерий, и простейшими средствами запрограммировать его. Например: Все задачи, для которых прошло половина отведенного срока, однако процент выполнения которых менее 30%.

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

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

В качестве заключения

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

Именно это его свойство позволяет управлять проектом не через вертикаль руководителей (нередко с искажениями), а получая информацию из единственного источника.

Ну, а попробовать попробовать Redmine вы можете в нашем облаке.

Время бежит быстро, и вот уже день становится короче, а воздух холоднее. Но мы встречаем очень с оптимизмом потому, что завершили программирование модуля СЭД на базе Redmine. Кроме удовольствия программирования на Ruby мы получили мощную систему документооборота в привычном интерфейсе.

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

Таким образом, мы получили систему, которая в одном интерфейсе объединяет:

1. Систему управления проектами (аналог MS Project, Oracle Primavera);
2. CRM, интегрированную с АТС Asterisk (аналоги Мегаплан, Битрикс24, AmoCRM);
3. IP АТС (аналоги Avaya, Cisco Call Manager);
4. Почтовый сервер, сервер календарей и контактов (аналог MS Exchange);
5. Систему электронного документооборота (аналоги Documentum, Логика ECM, Directum);
6. Систему хранения и группового редактирования документов с контролем версий (аналог Google Docs).

Таким образом, наше полноценное решение для бизнеса стало еще более полным, но при этом осталось  свободным от лицензий и санкций.

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

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

1) Для начала нам понадобится плагин Якова Анникова Computed custom field;
2) Плагин добавляет вычисляемое поле в диалоге редактирования настраиваемых полей (вот теперь смотрите на рисунок);
3) Остается написать скрипт на Ruby и поместить его в поле «Формула»;
4) При этом доступные кастомные поля можно выбирать из диалога, а штатные переменные посмотреть в документации (кстати они же используются и в Redmine API);
5) Все. Программирование процедуры завершено.

Теперь вкусняшки:

1) При сохранении поля, Redmine правильным образом возвращает ошибки компиляции — это очень удобно.
2) А вот пример простейшего кода, который автоматически делегируется задачи, для которых пользователь забыл уставить значение в поле «Назначена» (и сообщает об этом в поле «Описание»).

if (self.assigned_to_id.blank?) # Поле «Назначено» не заполнено
if (self.status_id == 1) # Статус == «Новая»
self.assigned_to_id = 112 # ID for МБК. Отдел техподдержки
self.due_date = start_date + 2
self.description = self.description + + «\r\n — \r\n» + «Redmine: Пользователь не назначил задачу никому. Выполнено автоматическое назначение задачи на техническую поддержку»
end
end

Приятная пятничная новость!

Мы сообщали ранее о возможности интеграции OnlyOffice с NextCloud, что безусловно расширяло функциональность обоих.
Но такое пересечение было неполным и приходилось либо выбирать наиболее подходящее, либо (как это делали мы) использовали оба решения.

Отныне интегрируемый в NextCloud редактор OnlyOffice позволяет получить все преимущества в одном интерфейсе. Более того, отпало ограничение на поддержку доменной аутентификации.

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

Российская операционная система «Альт 8 СП» получила сертификат Федеральной службы по техническому и экспортному контролю. Программный продукт соответствует новым требованиям ФСТЭК России к операционным системам. Действие сертификата № 3866 распространяется до 10 августа 2023 г.

«Альт 8 СП» семейства Linux разработана «Базальт СПО» и производится ИВК для организаций, которым необходимы отечественные решения с высоким уровнем защиты. Операционная система позволяет организациям выполнить требования Приказов ФСТЭК №17 «Требования по защите информации, содержащейся в государственных информационных системах» от 11.02.2014 и №21 «Требования по защите персональных данных» от 18.02.2014. «Альт 8 СП» включена в Единый реестр российских программ для электронных вычислительных машин и баз данных.

На основе ОС «Альт 8 СП» можно осуществлять построение государственных информационных систем (ГИС) и информационных систем персональных данных (ИСПДн) до 1 класса (уровня) защищенности включительно.

Ранее мы сообщали о том, что дистрибутив Альта, был сертифицирован Минобороны.

Лаборатория МБК является официальным бизнес партнером разработчика ОС ООО «Базальт СПО».

В практической эксплуатации гипервизора Proxmox мы столкнулись с ограничением производительности аппаратного ресурса, вызванного постоянным ростом количества пользователей и предоставляемых сервисов (виртуальных машин). Балансировка IOPS методом дросселирования применена, но ее возможности тоже уже исчерпаны.

Для начала несколько терминов чтобы было понятно.

IOPS — это input/output operations per second, числа операций ввода/ вывода в систему хранения в секунду.

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

Одна из важнейших причин для перехода на совместно используемые системы хранения — миграция в реальном времени (Live migration). Т.е. некая виртуальная машина может перемещаться на другой узел без её предварительного останова.

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

Третья причина — многоуровневость данных. Различные файлы могут содержаться в различных пулах хранения на основе их требований к производительности (допустим, виртуальный файловый сервер может предоставлять очень быстрое обслуживание если его ВМ содержатся в некотором пуле на SSD).

Proxmox имеет исключительные встраиваемые модули для вариантов хранилищ из основных направлений развития. В нашем случае использовался LVM. Мы вывели часть физических дисков из RAID и собрали на них новый деградированный RAID средствами ZFS. После этого, не останавливая виртуальные машины, перенесли их в новое ZFS-хранилище. Освободившийся RAID размонтировали, а физические диски добавили в новый RAID.

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