А сколько все эти балалайки сами потребляют ресурсов? Обязательно ли наличие БД? Можно ли производить анализ в риал тайме?
И я так понимаю что это только для х86 работает? На АРМ не запустить?
И вот еще, есть демон, который запускает разные тесты, анализирует результаты и т.п. Ему можно задать условия, что если тест фэйл, то отправь уведомление (есть несколько вариантов как он это может сделать). Так вот надо чтобы при получении такого сообщения, менеджер кое-куда слазил, собрал статистику, состояния, запустил кое-то еще и в итоге все результаты сохранил.
Задача связана с администрирование парка машин, которые очень разные функции, но в основном они занимаются различными сетевыми функциями, роутят, НАТят, глубокий анализ пакетов на предмет передаваемых данных, RADIUS базы данных пользователей, хранение лога сообщений. Время от времени необходимо провести корреляцию между различными событиями в сети. Чтобы не хранить тонных историй о том как все работало, хочется иметь решение, которому можно задать условия, при выполнении которых сделать такие-то действия.
Например, такая задачка есть - отслеживать загруженности интерфейса (сколько бит/с) и CPU, при превышении определенных уровней, запустить tcpdump с определенным фильтром и записать перехваченные файл на диск, отправить уведомление администратору.
или
Есть скрипт, который мониторит подключенный по ком-порту телеметрию специфическую, дает запросы, парсит вывод, сохраняет данные в базу. Надо сделать задание, что если в ответ на запрос получена абракатаба, ну или зафиксирован крэш телеметрии (в выводе по ком порту получен эксепшэн), то по ssh зайти на управляемую розетку, выключить/включить телеметрию, далее по ком-порту отловить приглашение на вход в загрузчик устройства телеметрии, войти и загрузить файл прошивки, еще раз передернуть питание, отправить администратору уведомление, что был сбой, все исправлено.
Не пингуется откуда, из этой же сети или из другой?
Не ответа при пинге с хоста на BVI или с BVI на хост или оба варианта?
Что выдается в выводе ping с хоста на роутер и с роутера на хост?
Что ARP таблице на роутере и хосте?
Нашел вот такое письмо, в котором говорится, что при приобретение прав на ПО (вот только я не понял исключительных или нет), налогоплательщик освобождается от НДС. www.klerk.ru/doc/103793/
Тогда мне надо заморачиваться тем, чтобы у всех кто подключается была возможность создавать VPN и поддерживать этих пользователей. Среди тех кто подключается есть не только админы (знающие люди), но и много обычных операторов (простые юзеры), кто по бумажке подключается и выполняет стантартные действия.
Это то понятно. Простые и очевидные решения понятны и известны. Хочется найти красивое решение. Плюс я не упоминал такой момент, операторы, инициирующие ssh сессии — это пользователи 3-х фирм и пускать их на наш сервер ой как не хочется. Гемора с секурностью столько возникнет, что эта задача покажется невинной шалостью.
По поводу «напрямую» я имел ввиду, что необходима только одна сессия между пк админа и датчиком. То что она будет проходить через сервер это не страшно, важно чтобы на сервере не осуществлялась терминация ssh сессии.
От оператора только доступ в Интернет (EDGE/3G). GRE делают сами устройства, там линукс (какая точно версия сейчас не скажу).
DNS сейчас поднят на сервере.
Да, согласен. Разбили в пух и прах. Как говорится, надежда умерает последней.
Просто как-то не дает покоя мысль, что не элегантного решения для такой задачи =( вот в голову всякая абракатабка и лезет.
Ну и все таки попробую ответить на ваши вопросы из спортивного интереса =)
1. Клиент подклчается на 2 хоста, т. е. делает запросы на deviceID1 и deviceID2 соответственно будет две разные записи в НАТ трансляции.
2. Тут не будет отличается от обычной ситуации когда с одного пк несколько сессий открывается. Каждая сессия будет иметь уникальный SRC PORT. При прохождении НАТ это значение сохранится (как правило) или назначится другое уникально.
С DNS делать ничего не надо будет. Надо будет написать небольшой модуль, который будет отслеживать ресолвы и создавать/удалять записи в НАТ трансляции.