Dual Wan и особенности реализации NetWatch в MikroTik

«Если в простой конфигурации микротик не работает, значит вы не умеете его готовить… или явно что-то упустили.»
image
Как работают вместе failover и netwatch. Взгляд изнутри.

Почти каждой более-менее подросшей компании начинает хотеться качества коммуникаций. Среди прочего, заказчику часто хочется отказоустойчивый «Dual WAN» и VoIP телефонию. Тоже отказоустойчивую, разумеется. Руководств и статей по каждой теме в отдельности написано много, но внезапно оказалось, что совместить первое и второе получается не у всех.

На Хабре уже есть статья «Mikrotik. Failover. Load Balancing» от vdemchuk. Как оказалось, она послужила для многих источником копипасты кода в маршрутизаторы.
Хорошее, рабочее решение, но SIP-клиенты из LAN, подключающиеся к внешней IP-АТС посредством NAT, при переключении теряли связь. Проблема известная. Связана она с работой Connection tracker, который запоминает имеющиеся соединения вовне, и сохраняет их состояние независимо от других условий.
Понять почему так происходит можно посмотрев на диаграмму packet flow:
Packet Flow v6 part
Для транзитного трафика процедура обработки connection tracker выполняется всего в одной цепочке — prerouting, (т.е. до роутинга), до выбора маршрута и исходящего интерфейса. На этой стадии еще неизвестно, через какой интерфейс пакет пойдет в Интернет, и отследить src-ip при нескольких Wan-интерфейсах невозможно. Механизм фиксирует установленные соединения уже пост-фактум. Фиксирует и запоминает на время пока через соединение идут пакеты или пока не истечет заданный таймаут.


Описанное поведение характерно не только для маршрутизаторов MikroTik, но и для большинства Linux-based систем выполняющих NAT.


В результате, при обрыве связи через WAN1, поток данных послушно направляется через WAN2, только SOURCE IP прошедших через NAT пакетов остается неизменный — от интерфейса WAN1, т.к. в connection tracker уже есть соответствующая запись. Естественно, ответы на такие пакеты идут на интерфейс WAN1 уже потерявший связь с внешним миром. В итоге, связь как будто есть, но на самом деле её нет. При этом все новые соединения устанавливаются корректно.
Hint: увидеть с каких и на какие адреса делается NAT можно в колонках «Reply Src. Address» и «Reply Dst. Address». Отображение этих колонок включается в таблице «connections» с помощью правой кнопки мыши.
image

На первый взгляд выход выглядит довольно простым — при переключении сбросить ранее установленные SIP-соединения, чтобы они установились заново, уже с новым SRC-IP. Благо простой скрипт по просторам интернета бродит.

скрипт

:foreach i in=[/ip firewall connection find dst-address~":5060"] do={ /ip firewall connection remove $i }

Три шага к фейлу.

Шаг первый. Копипастеры добросовестно переносят конфиг для Failover recursive routing:

Заголовок спойлера

# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение failover c более глубоким анализом канала###
#с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
/ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
/ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
# укажем 2 default gateway через узлы путь к которым указан рекурсивно
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping

Шаг второй. Отследить событие переключения. Чем? "/tool netwatch", естественно! Попытка отследить падение шлюза WAN1 обычно выглядит так:

Netwatch config

/tool netwatch
add comment=«Check Main Link via 8.8.8.8» host=8.8.8.8 timeout=500ms /
down-script=":log warning («WAN1 DOWN»)
:foreach i in=[/ip firewall connection find dst-address~":5060"] do={
:log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
/ip firewall connection remove $i}"
up-script=":log warning («WAN1 UP»)
:foreach i in=[/ip firewall connection find dst-address~":5060"] do={
:log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
/ip firewall connection remove $i}"

Шаг третий. Проверка.
Админ гасит первый аплинк WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!
Админ включает обратно WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!

Fail.

В реальной обстановке такой конфиг работать отказывается. Неоднократное повторение шага №3 приводит админа в состояние озлобления и мы слышим «Не работает ваш микротик!».
image

Разбор полётов.

Всё дело в непонимании того, как происходит работа утилиты Netwatch. Применительно в отношении именно рекурсивного роутинга, утилита просто пингует заданный хост согласно основной таблице маршрутизации, используя активные маршруты.
Проведем эксперимент. Отключим основной канал WAN1 и посмотрим и интерфейс /tool netwatch. Мы увидим, что хост 8.8.8.8 по-прежнему имеет состояние UP.
Для сравнения опция check-gateway=ping, работает для каждого маршрута в отдельности в т.ч. рекурсивно, и делает сам маршрут активным либо НЕактивным.

Netwatch использует уже активные на данный момент маршруты. Когда что-либо происходит на линке до шлюза провайдера ISP1 (WAN1), маршрут до 8.8.8.8 через WAN1 становится неактивным, и netwatch игнорирует его, отправляя пакеты в новый default route. Failover играет злую шутку, и netwatch считает, что всё в порядке.
Второй вариант поведения netwatch, это двойное срабатывание. Механизм его таков: если пинги от netwatch попадут в таймаут check-gateway, то на один цикл проверки хост будет признан DOWN. Сработает скрипт переключения канала. SIP-соединения корректно перейдут на новый линк. Работает? Не совсем. Скоро таблица маршрутизации перестроится, хост 8.8.8.8 получит статус UP, вновь сработает скрипт сброса SIP-соединений. Соединения второй раз переустановятся через WAN2.
В результате, при возвращении в строй ISP1 и переходе рабочего трафика на WAN1, SIP-соединения так и останутся висеть через ISP2 (WAN2). Чревато это тем, что при проблемах у на запасном канале система этого не заметит и телефонной связи не станет.
image

Решение.

Для того, чтобы трафик на используемый для мониторинга хост 8.8.8.8 не заворачивался на ISP2, нам нужно иметь запасной маршрут до 8.8.8.8. На случай падения ISP1, создаем резервный маршрут с большим значением distance, например distance=10 и type=blackhole. Он и станет активным при пропадании линка до WAN1 Gateway:
/ip route add distance=10 dst-address=8.8.8.8 type=blackhole

В итоге имеем дополнение конфига всего лишь одной строкой:

Исправленный роутинг

# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение failover c более глубоким анализом канала###
#с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
/ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
/ip route add distance=10 dst-address=8.8.8.8 type=blackhole
/ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
# укажем 2 default gateway через узлы путь к которым указан рекурсивно
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping

Данная ситуация характерна именно при падении последней мили, когда шлюз ISP1 становится недоступным. Либо при использовании туннелей, которые более подвержены падениям в силу цепной зависимости.
Надеюсь, статья поможет вам избежать подобных ошибок.
Не читайте устаревшие мануалы. Будьте в курсе, и всё у вас «взлетит».

image
ссылка на оригинал статьи https://habrahabr.ru/post/319082/

VZ7 vs VZ6: есть ли повод обновляться?

В уходящем году вышла новая версия нашего основного продукта – системы виртуализации Virtuozzo. С тех пор мы постоянно получаем вопросы: «Стоит ли обновляться?», «Чем 7ка лучше 6ки?» и так далее. Поэтому на праздниках возникло желание расставить точки над i и в одном посте рассказать об отличиях Virtuozzo последней версии от предыдущих.

image

Хочется сразу отметить, что этот пост был подготовлен для пользователей Virtuozzo 6 и более ранних версий, а также открытого проекта OpenVZ (о новой версии которого мы уже писали). Это, конечно, не значит, что его нельзя или неинтересно читать тем, кто еще не пользуется Virtuozzo…просто здесь мы будем предметно рассказывать об отличиях последней версии, чтобы заинтересованные хаброчане могли принять решение, актуально им обновление или в нем пока нет смысла.

О платформе

Сама по себе платформа Virtuozzo стала более обширной. Теперь в состав продукта входят наше фирменное решение Systems Container, позволяющее запускать «легкие» виртуальные машины, гипервизор на базе KVM для управления виртуальными машинами, а также программно-определяемое хранилище. Преимущество состоит в том, что все это работает, как единый центр виртуализации, так что вы можете создавать «легкие» виртуальные машины и полноценные ВМ, выделяя ресурсы единого хранилища данных Virtuozzo Storage, создавая его на базе установленных в серверы жестких и твердотельных дисков.

Гипервизор

Как в открытой, так и в коммерческой платформе (которые развиваются теперь синхронно и используют один и тот же исходный код), мы перешли на гипервизор KVM. Причина очень проста: за последние годы KVM совершил очень большой рывок вперед, и мы обнаружили, что не успеваем со своим проприетарным гипервизором за темпами развития индустрии. Оказалось, что гораздо перспективнее участвовать в проекте KVM, внося свой вклад в развитие открытой системы виртуализации, а также дополняя его необходимыми функциями для использования в VZ7. Было реализовано более 200 патчей и доработок, которые делают KVM по-виртуоззовски более эффективным решением.

image

Более того, в коммерческой версии гипервизора KVM, который работает в Virtuozzo 7, реализована полноценная поддержка Microsoft Hyper-V (кстати, мы серьёзно обогатили практикой работы с гостями Windows и сам открытый проект KVM). Поэтому виртуальные машины Microsoft работают в Virtuozzo 7 практически также как на Hyper-V.

Более защищенные контейнеры

По запросам наших пользователей мы также реализовали ряд нововведений для контейнеров. За счет перехода Virtuozzo на новое ядро Linux 3.10+ (RHEL 7), появилась поддержка cgroups и namespaces, что обеспечивает больший уровень изоляции по сравнению с ядерными модулями. Также вместо обычных ID контейнеров в Virtuozzo 7 используется единый UUID.

Живая миграция

В новой версии Virtuozzo была также реализована полная поддержка CRIU (ссылка) – программного инструмента для Linux, который позволяет заморозить контейнер и сохранить его на диске в виде простого набора файлов. В результате вы можете восстановить его с той же точки, причем при правильных действиях приложение даже не заметит, что ему сменили рабочую среду. CRIU и проект P.Haul помогают создать новую экосистему для «живой миграции» контейнеров на базе открытых технологий (CRIU – это полностью OpenSource-проект), и это огромный рывок в вопросах миграции по сравнению с Virtuozzo 6. Дело в том, что CRIU большей частью реализован в пользовательском пространстве и почти не требует модификаций ядра. Благодаря этому развитие самого инструмента не требует выпуска постоянных патчей для ядра и их согласования, а также перезагрузок при обновлении системы – критичный кстати вопрос для промышленных сред.

Обновления безопасности – без остановки сервисов

Еще одна интересная возможность, которая помогает снизить потери при работе с новой Virtuozzo 7 – это ReadyKernel. Новая версия нашей операционной системы Virtuozzo Linux поддерживает возможность установки обновлений безопасности без перезагрузки серверов. С одной стороны, это позволяет устанавливать патчи сразу же, уменьшая риски взлома и компрометации систем, а с другой – не терять деньги из-за остановки сервисов, вызванных перезагрузкой.

Пользователи Virtuozzo 6 уже знакомы с системой установки обновлений ядра без перезагрузки — Rebootless Kernel Update (RKU). Но дело в том, что RKU все же работала не так хорошо – она останавливала контейнеры, загружала новое ядро и после этого запускала контейнер или ВМ. Да, этот механизм позволял загрузить практически любое ядро, но все же приводил к некоторым простоям. В Virtuozzo 7 за счет использования ядра 3.10+ мы перешли на технологию kpatch, и все стало намного круче.

По оценке наших специалистов, использование ReadyKernel помогает экономить до 200 часов работы администраторов в месяц (http://www.iksmedia.ru/news/5336522-Virtuozzo-Linux-7-ekonomit-zakazchi.html) на каждые 10 000 серверов.

Резервное копирование и восстановление

Средства резервного копирования в Virtuozzo 7 также были серьезно переработаны. Для этого была разработана новая API и реализован механизм CBT (changed block tracking). Для этого мы использовали стандартные механизмы QEMU/KVM, создав систему формирования снэпшотов, сохраняя образы контейнеров и виртуальных машин в формате QCOW. Virtuozzo 7. Благодаря этому создания накопительных резервных копий стало происходить намного быстрее, чем в Virtuozzo 6.

Кроме этого стало возможным экстренное восстановление! Даже если в какой-то момент система резервного копирования перестала работать, вы можете просто конвертировать файл QCOW2 в любой образ при помощи утилиты qemu-img.

Управление памятью

Мы уже говорили несколько слов о новой технологии управления памятью, которая реализована как в OpenVZ 7 (ссылка), так и в Virtuozzo 7. Новинка охватывает и контейнеры, и ВМ, и систму хранения. Advanced Memory Management (AMM) контролирует всю работу с памятью, включая KSM, а также технологии прогнозирования использования памяти для различных наборов WSS. Благодаря этому становится возможным автоматическая балансировка с минимальным влиянием на работу пользователей. AMM поддерживает гостевые системы Windows и Linux, а средства Online Memory Management (OMM) гарантируют доступность нужного объема памяти для контейнеров, а также позволяют увеличивать или уменьшать его без перезагрузки – и это еще один способ обеспечения непрерывности сервисов.

Поддержка OpenStack

Начиная с Virtuozzo 7 мы поддерживаем работу с контейнерами и ВМ через Libvirt. Благодаря этому Virtuozzo может работать с большими экосистемами, использующими libvirt, — то есть OpenStack и Virtual Machine Manager. То есть пользователи OpenStack могут раскрыть весь потенциал OpenStack для управления частным или публичным облаком с использованием контейнеров и ВМ Virtuozzo через OpenStack API или панель Horizon. Новый модуль Virtuozzo Storage также помогает создать программно-определяемую систему хранения для OpenStack

Каталог приложений

Последнее, о чем мы расскажем сегодня, — это возможность моментальной установки готовых и уже сконфигурированных приложений для любых пользователей. Поддерживать такой каталог самостоятельно, следить за обновлениями – весьма сложно. Поэтому в новой версии мы создали свой, готовый набор Virtuozzo Application Catalog. Вместе с Bitnami мы поддерживаем постоянно актуальный набор десятков приложений и сред разработки, уже готовых для развертывания в качестве виртуальной машины или контейнера: WordPress, Redmine, SugarCRM, Alfresco, Drupal, MediaWiki, GitLab и многих других.

image

Заключение

Сегодня мы поговорили об общих отличиях Virtuozzo 7 от предыдущей версии. Так что если вы являетесь нашим пользователем, у вас будет целая декада праздников, чтобы обдумать необходимость обновления. Как раз после праздников мы подготовим пост о том, как обновиться до «семерки» с минимальными потерями.
С наступающим Новым Годом!
ссылка на оригинал статьи https://habrahabr.ru/post/319112/

One Core API чтоб править Windows

           "Если Microsoft не обеспечивает совместимость — сообщество обеспечивает совместимость".                                                                                 Aceler 

Поздравляем хабражителей с Рождеством! И у нас есть праздничный сюрприз для вас!

Представляем вашему вниманию проект One Core API — слой совместимости с открытым исходным кодом для Windows XP/2003, который позволяет запускать на этих системах программы для более поздних ОС. По сути это враппер функций NT6. Путем дополнительных ухищрений обеспечивается поддержка DirectX 10. One Core API создан на основе исходников Wine и ReactOS, но его разработкой занимается другая команда.
Всех желающих приглашаем присоединится к разработке: github.com/Skulltrail192/One-Core-Api

Демонстрация возможностей

Приложения, что на скриншотах ниже, нельзя так просто взять и запустить под Windows XP, если только не использовать One Core API.

image

image

image

image

image

image
ссылка на оригинал статьи https://habrahabr.ru/post/319110/

Google добавил блокировщик рекламы AdNauseam в список вредоносного ПО

Компания Google удалила из каталога Chrome Web Store блокировщик рекламы AdNauseam и добавила его в список вредоносного ПО, что привело к невозможности использовать ранее установленные экземпляры данного расширения, в том числе установленные вручную в режиме разработчика.

AdNauseam — форк uBlock-Origin, распространяющийся под лицензией GPLv3. От оригинала его отличает то, что AdNauseam не только скрывает рекламу, но и симулирует клик на каждом рекламном блоке для того чтобы ввести в заблуждение применяемые в рекламных сетях механизмы отслеживания интересов пользователей.

По словам разработчиков, Google сформулировала причину удаления следующим образом: «An extension should have a single purpose that is clear to users…» (Расширение должно иметь одно предназначение и оно должно быть очевидным). Вот только описание приложения явно и чётко описывает эту функциональность, да и исходные коды приложения находятся в свободном(GPL) доступе. Так что это лишь надуманный повод, а причина кроется в том, что данное расширение прямо противоречит интересам Google, точнее его рекламного подразделения.

Была предпринята попытка поиграться с терминологией с целью сделать описание максимально однозначным, но вряд ли это приведёт к каким-то сдвигам в позиции Google. Фактически Google явно показывает пользователям, что оставляет за собой право удаления (не только из Chrome Web Store, но и из собственно браузера) любого неудобного для их бизнес-модели приложения вне зависимости от нарушения этим приложением формальных правил.

С позицией разработчиков можно ознакомиться по ссылке: adnauseam.io/free-adnauseam.html
ссылка на оригинал статьи https://geektimes.ru/post/284372/

Из АЭС в дата-центры: новая тенденция в мире телекоммуникаций

С каждым днем объем сгенерированной человеком информации увеличивается. Все эти данные нужно где-то хранить и как-то обрабатывать, особенно, если речь идет о цифровых данных. Соответственно, требуется больше-дата-центров, как говорится, хороших и разных. Но подходящих мест для строительства дата-центра, в случае, если нужен действительно мощный ЦОД, не так много.

Существует ряд важных условий при выборе такого места. Это определенный климат, наличие энергетической и сетевой инфраструктуры, относительная близость населенных пунктов и т.п. Во многих регионах, где все эти условия можно выполнить, возникает одна проблема — стоимость аренды или покупки земли, а также стоимость строительства. Для того, чтобы избежать значительных затрат, разработчики предлагают самые разные варианты, вплоть до создания плавучих дата-центров (что вполне реально и реализуется сейчас). Есть и более необычные предложения — например, преобразовать заброшенную АЭС в ЦОД.

Такое предложение было внесено экс-сотрудником Google Джоном Данном, который в свое время занимал должность топ-менеджера корпорации. Этот человек долгое время занят в телекоммуникационной сфере, так что бредовые идеи — явно не его конек. Он десять лет занимался поиском мест для создания новых ЦОД Google, опыта в этом плане Данну не занимать. Почему же тогда он предложил провести столь необычную модернизацию?

Дело в том, что бывшая АЭС располагается в очень неплохом месте. Речь идет об электростанции Vermont Yankee, которая использовалась с 1972 года по 2014. Три года назад АЭС закрыли, и чиновники штата стали искать способ использовать простаивающий объект. Изначально его хотели преобразовать в солнечную энергостанцию или же электростанцию, которая работает на природном газе.

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

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

Единственное, что сейчас использовать нельзя — это место, где располагается реактор. Его, ко всему, еще необходимо полностью деактивировать, что займет много времени. Тем не менее, свободные площади бывшей АЭС позволяют начать развертывание ЦОД уже сейчас. По мнению экспертов, запустить дата-центр средних размеров в этом месте можно всего за полгода.

Кстати, проект не такой уже и бредовый, как может показаться. Уже продолжительное время возможность создания новых ЦОД на основе выведенных из эксплуатации АЭС рассматривает компания Amazon. Руководство этой компании решило запустить похожий проект в Италии. Здесь ведутся переговоры с владельцем одной из старых АЭС, компанией Enel. Если все получится, что в итальянской провинции Монтальто ди Кастро появится один из крупнейших дата-центров страны. Стоимость проекта оценивается примерно в 1 млрд долларов США. Располагаться ЦОД будет примерно в двух часах езды от Рима. И это лишь пилотный проект, который, в случае успеха, будет масштабирован. Amazon планирует преобразовать в Италии от трех до пяти АЭС, превратив их в ЦОД.

И Россия тоже

Еще два года назад государственная корпорация Росэнергоатом объявила о намерении создать один из крупнейших дата-центров в России поблизости от Калининской АЭС. Эта АЭС оборудована четырьмя водяными энергетическими реакторами ВВЭР-1000, с мощностью в 1000 МВт каждый. Да, о преобразовании АЭС в ЦОД речь здесь не идет. Но располагаться новый дата-центр будет непосредственно рядом с энергетическим объектом.

Это сделано для того, чтобы обеспечить ЦОД надежным источником электричества. Перебои в данном случае практически исключены, так что дата-центр будет одним из наиболее надежных в РФ. Росэнергоатом — это часть госкорпорации Росатом, концерн, управляющий российскими атомными электростанциями. Дата-центр будет коммерческим. Около 10% мощностей планируется использовать на нужды самой государственной компании, остальное же предложат частным компаниям и организациям. Завершение работ в рамках первой очереди строительства запланировано на март 2017 года. Дата-центр рассчитан примерно на 4800 стоек.

По мнению авторов проекта, мощности нового ЦОД будут активно использоваться зарубежными компаниями, которые переносят данные российских пользователей на территорию РФ.


Коллеги, мы, компания Kingservers, сейчас ищем ИТ-авторов для технических сайтов (не Хабрахабр и не Geektimes, сторонние русскоязычные и англоязычные ресурсы). Условие — человек, который пишет статью (она должна быть грамотной и технической), должен еще иметь и возможность опубликовать ее на таком ресурсе. Если вы — такой автор, пишите в личку.
ссылка на оригинал статьи https://habrahabr.ru/post/319086/