Доброго всем дня!
Прошу помочь разобраться в проблеме. Думаю, эта тема с каждым днем будет все актуальней, решение пригодиться многим инсталляторам «несисадминам»
Квартира. KNX <->интерфейс АВВ IPS/S <-> домашняя LAN (роутер ASUS RT-n16) <-> локальная сеть провайдера <-> интернет. Мой IP(роутера) динамический, настроенa служба DNS от ASUS(типа DynDNS) . Доступ осуществляется через нее.
Провайдер – билайн(корбина), техподдержка провайдера говорит, что все порты открыты(в т.ч. 3671 для KNXnet/IP). Роутер помогали настраивать два сисадмина со стажем. Проброс портов сделан. Из домашней LAN интерфейс коннектиться к KNX, все видно, работает, настраивается. На компе настроен удаленный доступ через VPN и отдельное подключение к KNX, к роутеру подключаюсь удаленно через VPN – сетевой диск видно, а интерфейс нет.
При прохождении теста пинг проходит, а Unicast тест – нет.
На компе win7, файерволы отключены и на роутере и на компе и у провайдера. Весь инет перерыл, в т.ч. и немецкий форум. Пробовал всякие настройки для аналогичных устройств(IPR/S ABB, для юнга, для прочих) – не помогает.
Кто сталкивался с таким – помогите! Если можно – в картинках

Тоже пытался решить эту же проблему. Мне кажется, что проблема здесь в динамическом IP и скорее всего из "серого" диапазона. пинг тест проверяет пинг не с KNX-роутером, а в таком случае с сервером DNS. Добейтесь "белых" IP, лучше статических, и проверьте. Если пинг не будет очень большим (более 200мс), то должно заработать. Время ожидания отклика в ETS не настраивается.

С провайдером разговаривал - они могут зафиксировать мой "внешний" IP, но он как был серым, так им и останеться - мой роутер в его локальной сети(в веб морде роутера видно два адреса - один внешний "типа белый", второй 10......., т.е внутренний), порты НЕ закрыты(со слов провайдера). В инструкции по настройке "удаленный доступ с NAT" от weinzielerl указан способ - проброс портов. это сделано.
трассировка ниже, вроде все нормально

ПыСы. к сетевому диску в локалке то я подключаюсь! т.е. моя удаленная машина получается как бы внутри моей домашней LAN. Я так подозреваю ключевое слово в проблеме "Unicast тест не пройден" - как шлюз KNX-IP его осуществляет?

выкладываю инструкцию по настройке. гляньте - может что не так перевел?

еще есть вот это:
В настройках ETS теперь задаем IP-адрес удаленного роутера (через который подлючена удаленная KNX инсталляция) и вновь делаем тест связи. Прошли все тесты - все ОК, можно работать. Нет - читаем дальше!
Опять может возникнуть проблема - не проходит последний тест (Unicast тест). Возникает из-за NAT. Имеем - Проблема 2.
Решение нашлось на немецком форуме www.eib-forum.de- программка EIBnetIP_NAT_Support_Setup

... не помогло (

Не хватает информации...
1. IP-адрес АВВ IPS/S
2. IP сети провайдера клиента
3. IP-адрес вашего компа
4. IP сети вашего провайдера
и еще... вывод команд "ipconfig /all" и "route print" с вашего компа, когда он подключен к роутеру клиента.

Подключил статический IP - барышня в техподдержке заверила, что будет "прямое" подключение... Обманула.. Тот же серый, только теперь месяц не будет меняться.

1. IPS/S 192.168.168.4
2.4. роутер в моей локальной / в локальной провайдера / внешний - 192.168.168.1 / 10.29.31.1 / 95.31.35.82
3. мой комп 192.168.168.3
5. если правильно понял - это выполнение команд при подключении моего компа к инету через мой роутер

трассировки без роутера(кабель в комп напрямую) слева, с роутером справа , делал несколько раз, картина практически не меняется.
команды как выше

IP компов и шлюза в моем роутере прописаны на постоянную в обход DHCP

Нет. Команды нужно выполнить при поднятом VPN-соединении.
Т.е. в том состоянии компа, в котором нужно добиться работы ETS с АВВ IPS/S.

Проблема в том, что адреса в сети клиента и в вашей сети в одном диапазоне (192.168.168.0/24). Для полной уверенности нужен вывод этих команд, как я написал выше.

п.с. назначьте своим роутеру и компу адреса из другого даипазона (например: 192.168.0.0/24).

Проблема в том, что адреса в сети клиента и в вашей сети в одном диапазоне (192.168.168.0/24). Для полной уверенности нужен вывод этих команд, как я написал выше.

п.с. назначьте своим роутеру и компу адреса из другого даипазона (например: 192.168.0.0/24).
[/quote]

Я где-то встречал предупреждение о возможном конфликте при совпадении адресов в локальных сервера и клиента, поэтому назначил своему роутеру 192.168.168.1 а не 192.168.1.1 как по умолчанию- думал этого достаточно.
Попробую, лег GSM модем, не могу пока сделать "удаленное подключение".

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

Полазил по форумам, вконец запутался.
У меня складывается ощущение, что вся проблема в железе, а именно в разнице между IP интерфейсом и IP роутером. Как понял(если простым языком), IP интерфейс только перепаковывает телеграмму из IP в KNX и обратно и соответственно пересылает туда/обратно - туннелинг в пределах одной сети, как правило LAN. А IP роутер кроме того же самого еще и содержит таблицы маршрутизации. Т.е. как только между шлюзом IP/KNX и клиентом появляется хотя бы одно промежуточное звено - например Ethernet, то все, IPинтерфейс уже не канает, только IPроутер. Пока IP интерфейс и комп, на котором стоит ETS находятся в одной LAN - все нормально, как только в телеграмме меняются адреса отправителя/получателя, IPинтерфейс уже не может их переслать/принять, т.к. в нем нет таблицы по которой он может сопоставить адреса.
У буржуев такая проблема возникала еще с 2007года(вроде), но они ее обошли с помощью поддержки NAT(та самая программка NAT_Support)но как говориться есть одно но - у них распространен широкополосный доступ через DSL модемы, а они как я понял, подключены к интернет напрямую, т.е. им надо преодолеть только NAT своего роутера, ито, если он есть. Получается так: VPN туннель - роутер, поддержка NAT-IP интерфейс. А у меня широкополосный доступ другой-провайдер предоставляет доступ в интернет через Ethernet(свою LAN), т.е. туннель VPN заканчивается на их маршрутизаторе, а не на моем.

Сумбурно конечно, на както так(не пинайте, я просто электрик))) Если не прав - поправте плз.

Все это конечно так... есть проблемы с НАТом, только не в случае VPN-соединения.
Как только комп подключается через VPN, он тут же "становится своим" для сети, к которой он подключился... со всеми вытекающими (IP-адрес из той же сети и все такое). И в этом случае нет никаких промежуточных звеньев между VPN-клиентом (читай - комп с ETS) и IP-интерфейсом KNX. Ибо оба находятся в одной сети и в этом случае проблемы могут быть только в корректной работе VPN-сервера (читай - роутера клиента).

п.с.
"route print" так и не увидел... оба файла с одинаковым содержимым.

п.с.с.
абсолютно идентичный случай: (дом с KNX) --- (шлюз-LM2) --- (роутер-1) --- (интернет) --- (роутер-2) --- (комп с ETS)
соединяюсь через VPN c роутером-1... все замечательно работает.

блин, не то скопировал. теперь уже завтра, с работы сделаю.
Только насчет тунеля не совсем понял. Сегодня делал удаленное подключение из офиса, и точно помню, что в локальной офиса IP компа был 192.168.1.9 , а роутер у меня сконфигурирован 192.168.0.1 и в домашне сети у него адрес обычно 192.168.0.106(если по вайваю соединяюсь).

У вас интернет через DSL модем, или как у меня, через лан провайдера?
какой интерфейс(ЛМ2 - что это)?
получается, что подсоединяясь к свой лан через VPN, у моего компа два IP? -один внутри домашней сети, второй в той, из которой я соединяюсь?

именно... адрес в сети офиса может быть любым... при поднятии VPN-соединения компу назначается еще один адрес - выдаваемый VPN-сервером (как правило из диапазона, в котором находится сам VPN-сервер).

ipconfig как раз и показывает какие где адреса назначены, а route print покажет какие маршруты в системе в этот момент...

если с компа (с поднятым VPN) попинговать ABB, все проходит?


ethernet у меня (LAN)
ЛМ2 - логик машин 2 (evika)

как сделать пинг на шлюз?
если я сейчас из своей лан запущу впн, команда принт роут пройдет?

ping IP_адрес_ABB
да

ping 192.168.0.21
пингуется, 4 пакета отправлено, 4 получено, потерь 0

значит должна и ETS работать

роуте принт


так в том и фишка), она работает, пока я в своей сети сижу. хотя юникаст тест все равно не проходит. подключения нет из чужих сетей или при подключении через gsm модем.

так... давайте сначала... подключения нет в такой же конфигурации? с поднятым VPN к роутеру клиента?

интересно, посмотрел таблицу маршрутов - что это за адрес 127.0.0.1? этот адрес попадался в программке суппорт_мануал от немчуры))
хотя я и этот вариант пробовал.


не совсем понял "нет подключения". сейчас етс не запужена. в инсталяции только один шлюз.

LM2 - это как раз роутер, а не интерфейс!

127.0.0.1 - адрес localhost

"нет подключения" - это как я понял когда ETS не может к ABB прицепиться.

п.с. мозг уже спит )))

тады отбой, выходной все таки. в любом случае спсибо. если есть аналогичное моему устройству шлюз(именно интерфейс, а не роутер) - попробуйте через него у себя.
кстати, при поднятом впн из чужой сети шлюз АВВ вроде не пинговался. завтра проверю.

При поднятом VPN с удаленного компа(из чужой LAN) ping к шлюзу IPS/S проходит.

роуте принт с удаленного ПК

опачки...)) вроде заработало.

с чем и поздравляю

п.с. таки проблема была в одном IP-диапазоне... имхо

п.п.с. еще один нюанс... в настройках IPS, в поле default gateway надо вбивать внутренний IP-адрес роутера (который смотрит на IPS).

Полтергейст какойто)) к шине подключаюсь, программирование устройств проходит, читать/писать телеграммы можно, а юникаст тест при этом НЕ ПРОХОДИТ!
жду пока какой нить датчик сработает, чтоб убедиться что отсылка происходит реально. ребенок спит еще, будить жалко)))


в настройках интерфейса только одно! изменяемое поле - получить IP автоматически через DHCP. если поставить в "ручное", тогда выпадает окно, где надо ввести IP вручную. и все.

Да, рботает, но как то странно. Подключаю VPN, запускаю ETS, выбираю интерфейс, проверяю тест - юникаст не проходит - ОК, запускаю групповой мониторинг, все нормально - телеграммы читаются/пишуться, устройства программируются. Запускаю мониторинг шины - не работает, после этого сбой группового мониторинга, все перезапускаю - нормально.
И еще один момент. Такое ощущение, что если какое то время не происходит удаленных чтения/записи, то интерфейс "засыпает". Т.е. какое то время нет телеграмм в шине и я на удаленном компе уже не получаю телеграмм, даже если кто то жмакает на кнопки. Стоит только произвести удаленное чтение или запись и все нормализуется.
Фигня какаято.

Если проблема в пересечении адресов IP, тогда получается, что если я подключусь из сети(например по вайваю из какого нибудь кафе), в которой опять совпадут адреса - надо будет по новой их переназначать у себя?
Это я чему - например, у пользователя устройство с возможностью удаленного доступа, например айфон, захотел он посмотреть что твориться дома - а подключиться не получается, потому как пересеклись адреса.
Такое возможно?

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

Хотя сейчас сеть у меня не загружена (все работает в ручном режиме), только датчик наружной температуры циклически отсылает телеграммы с интервалом мнут 15 вроде, не помню. Но тем не менее вероятность такой ситуации есть, хотелось бы ее утранить.

Александру Алферову отдельное спасибо за участие и помощь!

Может кому пригодиться. В английском не силен, может кто объяснит об чем идет речь ))

Эксперименты продолжаются))) Похоже, что все таки у меня связь говно.. Соединение со шлюзом разоравлось, пинг га роутер - половина пакетов потеряна. Через некоторое время пинг нормальный, подключаюсь, все работает))

Да. Придется переназначать. Кстати... существует несколько диапазонов "серых" IP, которые принято (так исторически сложилось) применять в частных сетях. Помимо 192.168.*.*, есть еще более широкий диапазон - 10.*.*.*
Я рекомендовал бы использовать его. Конечно на 100% исключить вероятность совпадения невозможно, но можно хотя бы снизить эту самую вероятность. Я стараюсь использовать адреса, близкие к крайним значениям... например: 10.254.254.* (маска 255.255.255.0).
Очень небольшая вероятность, что где то существует настолько большая "частная" сеть, использующая такие адреса... все таки админы в большинстве случаев начинают адресацию с начала диапазона, а не с конца.


постоянно сталкиваюсь с той же проблемой... разбираться некогда... просто забил... перезапуск мониторинга помогает.

проконсультировался с сисадмином, он сказал то же самое. надо будет переназначить. на 10.*.*.* начинается лан провайдера, к которой подключается мой роутер. там может быть такая же ситуация?

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

Вряд ли у провайдера есть адреса типа 10.254.254.*
В любом случае, у провайдеров сеть большой емкости - нонсенс... любой сисадмин знает, что такое широковещательный трафик, и как он укладывает сеть ))) Думаю, там все поделено на небольшие сегменты. Можно смело ставить себе 10.254.254.0/24, и голову не забивать.

что такое в адресе ****/24?

если грубо - это "размер" сети. ))
/24 - соответствует маске подсети 255.255.255.0
т.е. в сеть 10.254.254.0/24 (маска подсети 255.255.255.0) входят адреса от 10.254.254.1 до 10.254.254.254 (255-й используется для широковещательной рассылки).

если вам это нужно, то стоит наверн почитать соответствующую документацию

п.с.
С одной стороны где IP-сети, и где KNX... а с другой стороны, постепенно идем к одному - все начинает работать, что называется - over-IP.
Для упрощения, без глубокого понимания принципов, можно использовать вот эту софтину - http://lantricks.com/lancalculator/

да, нагружать больше не буду. книжка у меня умная есть(Нигматулин по KNX).
Если интересно, результатыэкспериментов выложу.
Цикл чтения из KNX уже 10 мин, пока все стабильно. Хотя в интервале 30-60 сек были пропуски и повторы телеграмм. Наверное из-за сбоев в связи. У нас очень хреновый интернет, после 5-7 прыжков "превышен интервал времени ожидания"

Гы)))))))))
Сижу, ковыряюсь, телеграмки туды/сюды бегают.
Звонок... Ребонок в ужасе: "Папа, твой умный дом с ума сошел"