Не запускается Manageengine NetFlow Analyzer 12.4 после установки

В больших компаниях мониторингу всей инфраструктуры необходимо уделять много внимания. Одним из инструментов для мониторинга сетевого трафика при использовании маршрутизаторов Cisco, являются различные NetFlow-анализаторы. В частности, Manageengine Netflow Analyzer. Этот продукт, как и другие продукты ManageEngine, всегда был специфическим в установке/настройке/использовании. Но если всё сделать правильно — он позволяет достаточно подробно посмотреть на трафик маршрутизатора.

Версия 12.4 встретила меня отсутствием желания запускаться. Сервис вроде бы начинает стартовать и «подвисает» в неопределенном состоянии без каких-то значимых ошибок в логах. Попытки перезагрузки сервера, переустановки по другому пути и прочие «шаманства» не помогли. Пришлось слегка покопаться во внутренностях этого продукта и поискать решение методом «почти научного тыка».

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

  1. Запускаем командную строку (лучше с правами админа) и переходим по пути установки netfow analyzer. По умолчанию, это «C:\Program Files\ManageEngine\OpManager». Дальше — директория bin.
  2. Запускаем StartOpManagerServer.bat, соглашаемся с EULA, выбираем тип лицензии и радуемся :)

Не запускается RRAS на Windows Server 2019

При настройке VPN-сервера на Windows Server 2019, после установки ролей Routing and Remote Access и NPS и после завершения первоначальной конфигурации роли, практически всегда возникает ошибка при старте службы RRAS. Ошибка выглядит как:

The Routing and Remote Access service terminated with the following service-specific error: 
The callback function must be invoked inline.

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

Oculus rift. Нет изображения, горит оранжевый светодиод. Решение проблемы.

Периодически владельцы Oculus Rift сталкиваются с проблемами подключения шлема к ПК. Проблемы выражаются в том, что Oculus Home «видит» всё оборудование, замечаний по работе у него нет, но на самом шлеме горит оранжевый светодиод (который говорит о том, что видеосигнала нет, а питание есть) и изображение в шлеме не выводится. Обычно эти проблемы решаются очень долго и нудно: переустановка драйверов, oculus home, переподключение шлема в другие USB-порты, проверка подключения кабеля к шлему и т.д. Судя по информации в интернете, такая проблема появляется как у пользователей видеокарт от AMD, так и от nVidia вне зависимости от версии драйверов.

В моем случае не помогало ничего. Но я заметил, что при полной переустановке драйверов видеокарты (radeon rx 580) с установленной галочкой «сброс всех настроек», в тот момент когда старые драйвера удалились, а новые еще не установились, светодиод стал белым. Конечно, без драйверов играть не получилось бы и их пришлось поставить. После установки и перезагрузки он снова был оранжевым. Я попробовал отключить шлем от видеокарты — oculus home сразу ругнулся на то, что нет подключения к HDMI. После проведенных опытов, мне показалось, что система (windows 10) или драйвера видеокарты просто отключают видеовыход HDMI, как неиспользуемый (после удаления драйверов же всё работало!). Я отключил шлем от USB и HDMI, отключил единственный монитор от видеокарты (displayport), подключил HDMI, подключил USB, затем заново подключил монитор и… светодиод стал белым! Шлем начал выводить изображение!

Я решил проверить сохранится ли работа после перезагрузки — нет, светодиод снова был оранжевым. Но при помощи таких же нехитрых манипуляций (полное отключение шлема, отключение монитора, подключение шлема, а затем монитора) я смог заставить систему понять, что в HDMI что-то включено и с этим надо как-то работать. Единственным минусом такого решения у меня является «подтормаживание» курсора и изображения на основном мониторе после горячего подключения. После перезагрузки оно пропадает. В общем-то, при использовании oculus rift основной монитор в целом и не нужен и эта проблема мне уже не мешает.

Внезапная перезагрузка Ryzen 5000 при слабых нагрузках. Решение.

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

Я не хотел прибегать к ручному разгону, как к способу решения этой проблемы (помогает всем), но и постоянные перезагрузки с последующим появлением ошибки WHEA Logger ID 18 — Cache Hierarchy Error (или аналогичных) тоже не давали насладиться спокойной работой на мощном железе. Естественно, я обновлял BIOS, драйвера, пытался включать/отключать различные параметры в настройках BIOS, как и рекомендуют на большом количестве форумов… Не помогало ничего.

Но решить мою проблему помогла случайность. Во время очередных тестов я выставил профиль питания в Windows — Высокая производительность (High performance). Сразу внимания не обратил, но перезагрузки ушли. Затем, через некоторое время, я вернул «Сбалансированный» (Balanced performance) режим и компьютер опять начал перезагружаться. И снова это происходило либо при слабых нагрузках, либо вообще в простое. Возврат профиля «Высокая производительность» снова решил проблему.

Насколько я понял, внезапные перезагрузки возникали из-за попыток ОС Windows управлять состоянием процессора (его частотой или состоянием ядер) при простое. В профиле «Высокая производительность» минимальное состояние процессора равно 100%, т.е. частота не будет снижаться меньше базовой (3.7 ГГц для Ryzen 5900X).

Таким образом, если вы страдаете от внезапных перезагрузок на новом процессоре из серии Ryzen 5000, но ваше остальное железо точно рабочее, а БП способен вытянуть всю систему и стабильно работает под нагрузками — попробуйте поставить «Высокая производительность» в параметрах питания ОС Windows и скорее всего перезагрузки уйдут.

Автоматический запуск openvpn и obfsproxy

После настройки openvpn и obfsproxy в предыдущей части, необходимо допилить всё до красивого состояния. А именно: автоматизировать запуск obfsproxy, openvpn и восстановление настроек iptables после поднятия соединения.

Итак, для автоматического запуска клиента openvpn и подключения к серверу нам необходимо:

  1. Скопировать конфигурационный файл openvpn в директорию /etc/openvpn и переименовать его в client.conf
  2. Раскомментировать строку AUTOSTART=»all» в файле /etc/default/openvpn
  3. Разрешить автозапуск сервиса:
sudo systemctl enable openvpn@client.service

После этих действий openvpn будет автоматически стартовать и пытаться установить подключение. Но для подключения ему необходим obfsproxy (весь трафик идет через него).

Настроим автозапуск obfsproxy:

1. Создадим конфигурационный файл для сервиса:

sudo nano /etc/systemd/system/obfsproxy.service

2. Поместим в него следующие строки:

[Unit]
Description=Obfsproxy Server

[Service]
ExecStart=/usr/bin/obfsproxy --log-min-severity=info obfs2 --shared-secret=<some-random-key> socks 127.0.0.1:10194

[Install]
WantedBy=multi-user.target

3. Выполним перезагрузку юнитов с диска:

sudo systemctl daemon-reload

4. Разрешим автозапуск сервиса и запустим его:

sudo systemctl start obfsproxy.service
sudo systemctl enable obfsproxy.service

Obfsproxy запущен, openvpn подключился. Осталось активировать NAT через iptables:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

И, желательно, делать это автоматически. Для этого:

1. В конфигурационный файл openvpn добавляем:

script-security 2
up /etc/openvpn/up.sh

2. Создаем скрипт /etc/openvpn/up.sh с содержимым:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.rules

3. Сохраняем текущие настройки iptables при помощи:

iptables-save > /etc/iptables.rules

4. Не забываем сделать скрипт исполняемым.

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