Охрана и безопасность
General Category => Техническая поддержка => Тема начата: Вето от Января 20, 2013, 13:21:16
-
Доброго времени суток! Подскажите существует ли возможность удаленного подключения Дежурного оператора к контрол центру не в локальной сети.
-
Доброго дня. Меня тоже интересует этот-же вопрос пытаюсь заменить Феникс ЦППС на удаленые пульты ничего не получается тех подержку наверно уже задолбал и сам уже устал по сети работает без проблем, а за 40 км(другой провайдер) не работает использую VPNN-подключение может настроино не правильно уже и не знаю.
-
Если VPN настроено не правильно, то вы не подключитесь к удаленной сети. Если подключились, значит все правильно.
Нужно только в программах дежурный оператор и администратор в настройках прописать ip адрес компьютера с центром управления и ip адрес компьютера с sql сервером, ну и логин и пароль и базу данных от sql сервера.
И все будет работать.
-
У меня по VPN подключению IP адрес сервера 10.10.10.2 IP клиента 10.10.10.3 в сети 192.168.0.143 как должно быть правильно?
-
Может кто поможет у кого получилось помогите мой ящик bezpeka2@mail.ru
-
когда ты создаешь vpn подключение у тебя указывается в подключении внешний ip адрес сервера. соответственно на сервере должен быть настроен vpn и быть внешний ip адрес. без внешнего ip адреса ничего работать не будет.
серверная часть vpn настраивается на виндоусе серверном или на шлюзе.
-
А если используется открытый интернет то какой порт надо пробросить, я так понимаю феникс работает по 80-му порту?
-
А можно как-то по подробней,ато я чегото не допонимаю
-
Чтобы подключаться ЦУ через Интернет, Ваш сервер должен иметь внешний статический ip адрес, который будет всегда один и тот же при подключении сервера к Интернету. Тогда Ваш сервер будет "видет" в Инете и к нему можно будет подключиться.
Либо можно использовать программы типа Хамачи для создания закрытой локальной сети в Инете.
-
Сделал впн подключение прошло все нормально опросы проходят но через 20-30 мин выскакивает потеря связи с центром управления нажимаю ок делаю опрос проходит итак целый день, оно так и должно работать? может кто настроил давайте сверимся с откр портами может я какой-то не открыл хотелось убрать феникс цппс и перейти на удаленый пульт но ничего не получается, тех подержка помогите!
-
Сделал впн подключение прошло все нормально опросы проходят но через 20-30 мин выскакивает потеря связи с центром управления нажимаю ок делаю опрос проходит итак целый день, оно так и должно работать? может кто настроил давайте сверимся с откр портами может я какой-то не открыл хотелось убрать феникс цппс и перейти на удаленый пульт но ничего не получается, тех подержка помогите!
Вам надо обратить внимание на скорость соединения и его пропускную способность. Такие проблемы могут возникать не только на удаленных рабочих местах, но даже в рамках локального компьютера: http://p-sec.eu/forum/index.php?topic=258.msg1773#msg1773 (http://p-sec.eu/forum/index.php?topic=258.msg1773#msg1773)
-
Ну я не знаю может придумайте что-то вроде как раньше Феникс2+Феникс ЦППС работало на ура, а Феникс4+Феникс ЦППС работает плохо особено утром и вечером задержки по сигналам идут в 30мин,с удалеными пультами проблем больше чем Феникс ЦППС, я бы так и оставил но другая проблема наставили Лунь11, а с ЦППС он не работает из-за этого луни11 серии мы стараемся вообще не брать.
-
Ну я не знаю может придумайте что-то ....
Уже придумали. В 22 версии были внедрены так называемые "удаленные пульты". Ни каких задержек по полчаса при их использовании нет. При правильной настройке канала связи между "удаленными пультами" события появляются практически мгновенно, вне зависимости от типа оборудования установленного на объекте.
-
Так вот при правильной настройке, кто настроит? Я настроил, то работае то нет, дайте краткое руководство особено по подключению два разных провайдера какая мин скорость инета должна быть у нас на главном 20мбит на удаленом 512 кбит подойдет или увеличить на удаленом, потому-что пропадает постояно связь.
-
Однако, то же интересно про настройки удаленного доп раб места для феникса gps
-
Так вот при правильной настройке ..... на удаленном 512 кбит ....
Если у Вас удаленное рабочее место работает, но возникают периодически проблемы, то канал скорее всего настроен правильно, но есть проблемы со связью.
Исходя из того что Вы написали можно догадаться, что это у Вас 3G модем. Если так, то наверняка канал асинхронный, то есть на закачку 512 кбит. А на отдачу сколько? Поинтересуйтесь пожалуйста. Вполне возможно, что меньше 32 кбит заявленных, а реальных и того меньше. Какой у Вас пинг? Какой процент потерь? Запустите пинг с параметром "-t" на полчаса, час в момент когда у Вас возникают проблемы.
-
Однако, то же интересно про настройки удаленного доп раб места для феникса gps
Феникс-GPS ничем не отличается от "Дежурного оператора", "Администратора базы данных", "Центра управления". Принцип тот же "клиент-серверный".
Подходов может быть два.
Главное это иметь статические IP-адреса сервера и клиентов.
Первый. На основном компьютере подымаете VPN сервер, а на удаленных рабочих местах создаете VPN соединение к серверу.
В настройках Феникса указываете внутренне IP-адреса Ваших компьютеров.
Второй. Проброс портов программ Феникса, через роутер или сервер интернета, а также открытие их в файрволах и брандмауре для Феникса.
В настройках Феникса указываете внешние IP-адреса Ваших компьютеров.
-
Какие порты нужно пробрасывать на основном пульте при работе"Дежурный оператор"?
-
При открытии портов 5050......5053 пролазят трояны, как только закрываю все ОК, антивир Касперский лицензия
-
Прошу прощения при открытом 1433 порте. Когда закрыл все заработало.
-
Все выше перечисленные проблемы исчезнут и подключение станет на много проще, если использовать "удаленное подключение к рабочему столу". Но..!
Необходимо, чтобы HASP ключ имел сетевой сертификат.
Что скажет по этому поводу Support ?
-
Все выше перечисленные проблемы исчезнут и подключение станет на много проще, если использовать "удаленное подключение к рабочему столу". Но..!
Необходимо, чтобы HASP ключ имел сетевой сертификат.
Что скажет по этому поводу Support ?
Добрый день. На данный момент наши HASP-ключи не поддерживают сетевые лицензии.
-
Самое простое и очевидное решение для подобной задачи я нашел в использовании программы team viewer. Теперь могу управлять пультом удаленно, фактически из любого места. Настраивается в разы проще, да и дежурным спокойнее - теперь карточки редатируются на ходу.
-
Через VPN Hamachi все работает как часы без пробросов и прочих мудростей
-
Какие порты нужно пробрасывать на основном пульте при работе"Дежурный оператор"?
По умолчанию для главного "Центра управления" 5055
Для "Центра управления" 5050
"Дежурный оператор" 5051.
"Администратор базы данных" 5052.
"Феникс-GPS" 5053.
"Заявки Инженеров" 5054
"Конфигуратор" 5050
Для всех программ Феникса должен быть доступен порт SQL сервера. Он может быть статическим 1433 или динамическим. Это можно посмотреть в "Sql Server Configuration Manager". В нем же можно его изменить.
(https://i.imgur.com/so4YOnw.png)
Порты программ ПО "Феникс-4" можно изменить утилитой PortSettings.exe которая лежит по пути \ProtectionAndSecurity\Phoenix4\PortSettings
(https://i.imgur.com/fze0NWx.jpg)
-
Здравствуйте, уважаемая техподдержка.
Прошу вас проинформировать об особенностях реализации механизма контроля состояния канала связи между "Центром управления" и удалённым ПО "Дежурный оператор".
Исходные условия:
1. ПО "ДО" исполняется на Windows10-ПК (далее - клиент).
2. ПО "ЦУ" исполняется на Windows7-ПК (далее - сервер). Версия ПО "Ф4" на сервере и клиенте 1.43.45.1.
3. Канал связи между сервером и клиентом: VPN-PPTP-канал (сервер на роутере - клиент на W10), через Интернет, маршрут-я - в пределах единого (для площадок сервера и клиента) городского провайдера. Пинг между клиентом и сервером стабильный (средний ~5ms, максимальный ~15ms). Процент потерь пинга - менее 0,1%.
4. В настройках ПО "ДО" клиента взведён флажок в радиокнопке: "Настройки"->"Просмотр событий"->"Проверять связь с центром управления".
Проблематика (требующая решения):
5. Периодически (от суток до недели) возникает ситуация, когда клиент начинает "сыпать" сообщениями о потере связи с "ЦУ".
6. В момент возникновения п.5, VPN-канал стабилен. Проверяется пингом постоянно.
7. Ситуация п.5 может разрешиться самопроизвольно, а может и потребовать перезапуска (операционной системы) клиента с переустановкой VPN-соединения и последующим запуском ПО "ДО".
Собственно вопросы:
= Каким механизмом проверяется доступность канала связи между сервером и клиентом?
= Каков действующие критерии (значения счётчиков "ответ\не-ответ"), по которым канал признаётся негодным с генерацией соответствующего уведомления в ПО "ДО" (событие "Нет связи с ЦУ")?
= Существует ли возможность "ослабить" политику контроля канала с целью минимизировать вероятность ложных срабатываний (см.п.5)?
P.S.
В таблице Connections Tracker роутера видно, что между клиентом и сервером на постоянной основе устанавливаются:
8. udp-канал с порта 5051 клиента - на порт 5050 сервера
9. tcp-соединение с порта 56837 (динамический) - на порт 49187 сервера
10. tcp-соединение с порта 56839 (динамический) - на порт 49187 сервера
Периодически наблюдается:
11. udp-активность по портам 5052, 5056 клиента - на порт 5050 сервера.
12. icmp-активность между клиентом и сервером.
Кто что посоветует в данной ситуации?
-
Исходные условия:
В исходных условия отсутствуют очень важные данные, а именно:
- сколько у вас ЦУ
- сколько источников событий в каждом ЦУ
- сколько объектов выходит на каждый источник событий
- нужны данные компьютерах где запущен MS SQL сервер, Центры управления и Дежурные операторы (как технические характеристики, так и сведения об ОС)
На контроль связи с ЦУ влияет и скорость отклика ЦУ на запрос от ДО, то есть, если ЦУ "сильно занят" - в диспетчере задач ЦУ отъедает более 35% производительности процессора, у вас то же будет событие "потеря связи с ЦУ".
Проще связаться с технической поддержкой и разобраться с проблемой.
PS. Сначал обновитесь до версии 49, может само пройдет.
-
Пульт самый заурядный, начинающий, так сказать:
= кол-во ЦУ - 1ед.
= источник событий - 1ед. (открытый Интернет).
= общее кол-во объектов - менее 30шт.
= MS SQL и ЦУ "крутятся" на одном и том же компьютере (под управлением W7Pro-64bit - уже говорил об этом). Аппаратная конфигурация:
- Intel Core i3-6100/8GB озу/ SSD MLC Idnition 4/ резервный HDD/ LAN - Intel интегрированная/ чипсет B250
= клиент - на ноутбуке под управлением W10Home-64bit. Аппаратная конфигурация:
- AMD APU A6- 3GHz/ 4GB озу/ HDD 500GB/ LAN - Realtek
Загрузка процессора на сервере - около 0% - очень низкая. На клиенте - не знаю, но думаю, что справляется.
Обновляться на 49 версию пульт будет, но "попозже" - пока нет резервного железа. А проблема требует решения "щас" ;)
Техподдержку "грузить" не очень хочется, так как проблема возникает эпизодически и сам знаю как тяжело бывает "разруливать" что-либо по "удалёнке". Короче, - всё - как обычно в нашей жизни... Но, "вопрос то, - в другом" (с) - Иван Абрамов.
Давайте, я лучше так сформулирую, а про остальное - я понял:
= канал между ЦУ и удалённым ДО тестируется ping-ом (на это недвусмысленно намекает вышеприведённый скриншот)? Просто ответьте - да или нет.
= какой интервал тестового пинга?
= какой допустимый счетчик "не-ответов" на пинг, прежде, чем ДО "заорёт" о проблеме с каналом?
= какой таймаут ожидания ответа на пинг?
= можно ли теоретически (например, с очередным апдейтом) "ослабить гайку" или реализовать адаптивный алгоритм, наподобие "любое событие считать тестом".
С уважением.
P.S. Очень не хочется отключать контроль связи с ЦУ в ДО. Я не исключаю деградации качества VPN-канала как раз в период времени возникновения проблемы. Но сбрасывать со счетов "странности" реализации алгоритма тестирования канала связи, действующего между программными модулями вашего комплекса, то же будет не правильно. Возможно, он у вас просто "заточен под локалку". Чем больше информации удастся получить от вас по этому вопросу, те легче будет разобраться в проблеме. Собственно, - к вам нет никаких претензий. Простая просьба помочь информацией.
-
И ещё вопросик (склероз).
События "Нет связи с ЦУ" и "Потеря связи с базой данных" - это разные события? Или я нафантазировал и у вас только какое-то одно (не помню точно как называется)?
Просто на "том конце верёвки" (на стороне клиента) сидят девушки-операторы. И в "это время" - не особенно вежливые. У них тогда один ответ - "ничертаниработает".
Так вот, если это - разные события, то через какой временной интервал "Дежурный оператор" генерирует окошко "потеряна связь с БД" после разваливания канала? Извините за сумбурный вопрос, - смоделировать эту ситуацию я не могу.
-
События "Нет связи с ЦУ" и "Потеря связи с базой данных" - это разные события?
"Нет связи с ЦУ" ... В вашей ситуации надо разбираться более детально.
Дежурный оператор по внутреннему таймеру опрашивает ЦУ раз в 30 секунд. То есть может быть, что событие о потере связи может быть сгенерировано и через 1 секунду и через 29 секунд после пропадания связи, а может и при стабильном пинге при потере пакета запроса.
После отправки пакета ждем ответа целых 5 секунд.
"Потеря связи с базой данных" ... Это действительно разные события.
Потеря связи с базой может быть и у ЦУ и у ДО и у АБД.
Быстрее всех потеря связи с базой проявляется в "Центре управления", так как он осуществляет огромный обмен самыми разными данными с сервером базы данных. Счет идет на миллисекунды.
Чуть позже может отреагировать "Дежурный оператор", но и тут счет идет от миллисекунд до нескольких секунд.
"Администратор базы данных" может сообщить о потере связи с базой, только при переключении вкладок и информационных окон.
-
1. Спасибо за информацию.
2. Если я правильно понял, то проверка канала пинг-ом является "глобальной", и предназначена выдавать предупреждение даже в случае, когда в течение интервала пинга (30 секунд) ЦУ не имел событий для отправки удалённому ДО?
Здесь напрашивается прямое решение минимизации ложной тревоги "Нет связи с ЦУ", а именно:
- уменьшить интервал посылки пинга "Дежурным Оператором", например, в два раза (опрашивать раз не в 30 секунд, а в 15);
- реагировать сообщением "Нет связи с ЦУ" не по первому "не-ответу" на пинг, а по второму (т.е. в случае двух подряд неудачных пингов).
При этом, мы сохраним максимальное время реакции системы на аварию канала (не более 30 секунд). Но избавимся от ложных тревог, обусловленных случайными потерями ответов на пинг (вызванными, например, кратковременными флуктуациями канала или "тормознутостью" сетевого процесса на "дальней" машине с ЦУ). Так будет меньше "ложняков".
Верно?
3. Если я правильно трактую взаимосвязи между ДО и ЦУ (см. скриншот), то ДО получает от ЦУ только "флаг" (извещение) о наличии нового события (сокет с рабочих портов 5050 и 5051). В данном контексте не важно, - "запрашивает" ли инициативно ДО Центр управления или наоборот, - ЦО инициативно "информирует" ДО.
А вот "вычитывает" событие, похоже, сам ДО - непосредственно из Базы данных(?).
Или это не соответствует действительности? Иначе, зачем нужны ещё два сокета, открытых непосредственно между приложением ДО и процессом MSSQL (рабочие порты: 56837 - 49187 и 56839 - 49187)?
То есть, событие "Потеря связи с Базой данных" генерируется по результатам действия совершенно другого механизма, нежели пингование IP-адреса машины с ЦУ(?)
Если это так, то в моём случае нужно точно выяснить (у девушек-операторов удалённого ДО), какое именно событие "всплывает" при появлении проблемы:
"Нет связи с ЦУ" или "Потеря связи с БД"
и на основании этого уже двигаться дальше...
Спасибо, ещё раз за помощь.
-
Здравствуйте, уважаемая техподдержка.
Пользуясь последней возможностью «вскочить в вагон уходящего поезда» технической поддержки «Феникс-4» задам вопрос. История такая:
при подключении удалённого рабочего места с ПО «Дежурный оператор» (далее – дальний «ДО») к ПЦН (v49.200) посредством VPN возникает проблема, заключающаяся в том, что лента событий в окне «ДО» не обновляется автоматически. То есть, событие на ПЦН приходит и нормально отображается в локальном «ДО». А в дальнем «ДО» это событие появляется в «ленте» только если нажать кнопку «СБРОС», например. Или переключиться между окнами. Все остальные функции работают быстро и чётко: чтение журнала событий; открытие карточки объекта, и т.п.
Приведу пример для понимания проблемы. На дальнем «ДО» запрашиваем «Отчёт, снятие запрета». На локальном «ДО» при этом мгновенно отображается «Запрос состояния прибора» и его результат. А на дальнем «ДО» – «тишина и мёртвые с косами стоят»… - события появляются только после нажатия кнопки «Сброс».
Создаётся впечатление, как будто IP-адрес клиента с дальним «ДО» исчез из клиентов на ПЦН или зачислен в список «мёртвых». Но адрес есть, события для рассылки назначены и все адреса пингуются с обеих сторон. Причём, «ломается» рабочая схема «на ровном месте»: дальний «ДО» может проработать долго и счастливо (недели), а после очередного переподключения к ЦУ «впасть в кому». Перезапуск ЦУ проблему не решает. Рестарт Виндовс – то же. Ситуация разрешается сама-собой, через длительное время (дни). По этой причине пользоваться этой схемой нельзя. Ошибка эта давняя, но сформулировать её спровоцировало окончание срока поддержки…
Собственно вопросы:
- почему дальний «ДО» может таким образом ломаться?
- каким образом ЦУ производит оптимизацию клиентов, внедрённую ещё в версии 1.43.45.х?
- что посоветуете?
P.S. Ошибка воспроизведена на двух абсолютно разных ПЦН, на разных ПК с дальними «ДО», через разные каналы связи. Перебраны несколько типов VPN. В локальной сети – всё чётко. Проблема наблюдается только через VPN. Все "нужные" соединения между сервером и клиентом устанавливаются, и по ним бегают пакеты... :'(
-
- что посоветуете?
Попробуйте вместо IP адресов использовать имена компьютеров.
И еще. Сравните ping в канале, когда у вас работает корректно и когда пропадает.
-
- что посоветуете?
Попробуйте вместо IP адресов использовать имена компьютеров.
И еще. Сравните ping в канале, когда у вас работает корректно и когда пропадает.
1. Протокол NetBIOS работает в едином широковещательном домене L2. На текущий момент имею PPTP-VPN, который не обеспечивает связности на L2. Кроме того, использование имён NetBIOS предполагает пребывание хостов в адресном пространстве одной и той же подсети, что, с моей точки зрения, не удобно и не по "фэн-шую".
В вашей инструкции разрешено использовать IP-адреса при настройке доступа с удалённых АРМ. Или есть принципиальные различия в функционировании протоколов обмена между сервером и клиентом при использовании IP, либо имён NetBIOS? Может какой-либо процесс протокола обмена требует широковещательный домен? Не всё в протоколе обмена передаётся юникастом? Тогда скажите об этом в инструкции. Я заметил, что простое перемещение клиента с "ДО" (работающего через IP) в LAN (L2-домен) гарантированно восстанавливает работоспособность схемы. Как тогда это объяснить? Как объяснить, что схема, работающая неделями ломается "вдруг". Ни с того, ни с сего. Просто после переподключения к ЦУ престают приходить новые события. А весь остальной функционал работает. Тут без понимания протокола обмена "поломку" не найти.
А что говорят разработчики по этому вопросу?
2. Пинг не меняется и составляет около 2-х мс.
P.S. Не поленился, - поднял между точками EoIP-тоннель, обеспечивающий L2-связность. Стал ходить пинг до сервера (до ПК с ЦУ) по имени NetBIOS. Пока не менял IP-адреса на Net-имена (в ЦУ и клиенте с ДО), ибо "мопед не мой" - доступа к серверу нет. Завтра попробую сделать договориться. Проверил текущее "поведение" клиента ДО. Ситуация никак не изменилась.
-
Докладываю:
- после поднятия EoIP-тоннеля (поверх PPTP-VPN) "подрихтовал" конфигурации роутеров (убрал лишние сущности, лишние маршруты и, главное, поднял значение MTU в тоннеле EoIP) и ... удалённый клиент с "ДО" заработал!
Хоть и рано радоваться, но радуюсь. За последние 2 недели удалённый клиент с "ДО" ни разу нормально запустить не удавалось! После поднятия L2-тоннеля и поднятия MTU c 1280 до 1454 - заработало. Причём, MTU в L3-тоннеле значения не имело.
Т.е. тоннели уровня L3, в частности, PPTP, L2TP и т.п. не обеспечивают стабильного функционирования схемы! Только "хардкор", только L2... ;)
Выводы поспешные, но чувствую, что мы на верном пути.
Спасибо техподдержке за "пинок" в нужном направлении, хоть и случайный. Всё же, настоятельно прошу прояснить этот вопрос со стороны разработчиков (так сказать "добить комара"), дабы получить не только эмпирические результаты.
P.S. Конечно, буду нещадно переподключать клиента с "ДО" и оценивать стабильность этого процесса (минимум несколько недель). В случае успеха или неуспеха отпишусь...