Доброго времени!
Сейчас подключил в LAN сетевой контроллер NAE от Johnson controls, но необходим доступ к нему из WAN. Как решить этот вопрос?

"но необходим доступ к нему из WAN"

..как вариант "пробрасывать" порты на внешний IP/port forwarding, ну или ежели совсем по феншуй на роутере создавать правило транслирования по типу
WAN IP:w_port <-> LAN IP:l_port

Хорошая подсказка - сделаю, однако это половина решения, так как внешний IP+port будут переменными. Суть такова: Вебсервер находится в локалке, а вот клиент - в WAN и вход осуществляется с разных точек мира и устройств.

"так как внешний IP+port будут переменными"

..это у клиентов они IP будут переменные, у вашего сервера он IP должен быть внешним и постоянным, ну либо IP внешний на роутере и через трансляцию любой внешний клиент обратившийся на WAN IP:w_port транслируется на LAN IP вашего WEB-сервера

dyndns, noip и аналоги

буду пробовать, спасибо!

ага, переменный да еще и серый провайдерский - ни dyndns ни noip не помогут....
В общем определитесь сперва что у вас за адрес внешний....

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

самый простой вариант, два штуки.
1 - получить стат.айпи и дальше порты
2 - поставить в локалку комп, на компе поднять любой RDP типа тимвью и т.д. дале все вариантов масса
впн не всякое железо сможет

в любом случае для VPN где-то потребуется держать сервер с реальным прямым IP.

для всего что-нибудь да понадобится

мы себе организовали vpn-сервер с белым ip - не жалеем
несколько объектов к нему подключены

Белый IP + проброс портов сделали свое дело. Теперь возникла следующая задача:
4 обьекта с оборудованием на modBusRtu нужно вывести в одну скаду. Из скад есть навыки только для JCI NAE/NIE контроллеров.
я думаю решается так: установка шлюзов/конвертеров rs485/Bacnet IP на обьектах -> проброс портов-> Ловим данные на NAE.
Будет такая схема работать? Меня еще смущают возможные задержки в передаче данных.

frosteR
Зачем нужны шлюзы, если Modbus можно читать либо самой SCADA, либо посредством OPC серверов с поддержкой Modbus ?

Если выбор SCADA ограничен, тогда да, что даже OPC сервера не понимает, тогда вопрос, зачем такую шнягу выбирали ?

если у меня на обьектах модбас рту то чем мне поможет скада или opc ? мне для начала нужно переслать данные через езернет, а далее уже дело техники. про "шнягу"- это уже политический вопрос- мне предстоит работать с тем, что дано.

frosteR для работы с Modbus RTU через интернет не нужен непосредственно шлюз Modbus TCP - Modbus RTU, нормальная SCADA или OPC сервер умеют работать с Modbus RTU поверх TCP (или даже UDP), для этого достаточно преобразователя Ethernet - RS485.

Шлюз нужен только если у вас ну совсем плохо с ПО, которым пользуетесь.
А просто Ethernet - RS485 хватает, Пульсар, Телеофис (TCP сервера), С2000-Ethernet (Болид, UDP), различные Moxa и так далее...
И их цена ниже, чем на шлюзы.

manjey73, спасибо большое за развернутый ответ. Буду штудировать.

Поспешил рапортовать - "Получилось!". Просканировал открытые порты контроллера, оказался 9910, настроил админ проброс - в НЭТе глухо.Как вычислить причину?

frosteR чтобы проброс порта работал из интернета необходимо одно важное условие - это РЕАЛЬНЫЙ IP адрес вашего узла.
Если вы сидите за NAT провайдера то напрямую вы не попадете никак и никогда.

У вас адрес реальный ?

Какая у вас организация сети, где установлен контроллер ?

Обычно у провайдеров это называется статический или динамический IP адрес в договоре и оплачивается дополнительно.
Динамический необходимо привязывать к службам DynDNS, ipnodns и так далее, но не все устройства умеют работать с именами.
SCADA должна уметь работать с именем, но может и нет.

manjey73, у меня белый статический IP. Я уже пробрасывал шлюз BAC/mod для удаленной настройки через Web-интерфейс и все прошло ОК.

"Суть такова: Вебсервер находится в локалке"
"Просканировал открытые порты контроллера, оказался 9910"

..9910 это что? порт WEB-сервера ПЛК?? странный какой-то
..попробуйте в локалке одключицца к ПЛК и в TCPView посмотрите с каким портом ПЛК соединение появится, мне каж если вы с WEB-сервером соединяетесь то 80 порт стандартный должен быть, соотв его и надо пробрасывать

ktulu ничего странного, запросто может быть web на любом порту, но что-то мне тоже сдается что у ПЛК это не web

"запросто может быть web на любом порту, "

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

все верно, веб -сервер это был шлюз бак в мод, который пробросился успешно через 8080. другое устройство- сетевой контроллер NAE не работает через http, однако соединяется с прогой клиентом через 9910.

Прога клиент не означает, что там web, там может быть свой протокол, который работает на данном порту.

наверняка так и есть, однако это не должно быть причиной отсутствия соединения.

С чего такое мнение ? банально запрос - ответ, если в запросе нет идентификации то и ответа может не быть от ПЛК.

Вы снифер TCP ставили, чтобы посмотреть что клиент посылает получает от ПЛК ? например Wireshark натравить

под идентификацией понимаете информацию, которая позволит серверу отправить сообщение запросившему клиенту? Снифером попробую.

В NAE/NIE имеется Modbus драйвер (ModbusDriver_N40.dll или ModbusDriver_N50.dll). Для его активации нужен лицензионный ключ (покупается в JCI), после чего ваш NAE становится NIE и Modbus подключается прямо к NAE/NIE. Драйвер обеспечивает подключение по Modbus RTU или Modbus TCP.