если там мультикаст - так и гугли, «openvpn multicast». ну и еще - мультикаст может не пускать скажем не ovpn, а что-то еще, например роутер

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

хмммм выяснил что broadcast работает в моем случае через openvpn - удалось включить рабочий комп за шлюзом debian, командой «broadc myworkpcmacaddress 192.168.1.255 1». Ну а если работает broadcast то следовательно работает и multicast... Логи мессенджера нормальные, нет ошибок отправки широковещательных пакетов в подсети... Проблема должна быть в IGMP...

Ну а если работает broadcast то следовательно работает и multicast

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

а чем снять трафик со шлюза? объясните пжлст ка проверить multicast-трафик между двумя клиентами по разные стороны шлюза...

смотря что за шлюз. если линукс - tcpdump или вообще wireshark (если гуй есть). если что-то еще - надо смотреть. на крайний случай можно проверить умеет ли он port mirror и если нет - воткнуть промежуточный свитч чисто под это дело с разными вланами на разные порты. но это совсем крайний случай

wireshark попробую, сервер debian с gui)). В настройках мессенджера есть опции Multicast address 239.255.100.100, udp port 50000, tcp port 50000, которые можно изменять, есть поле для добавления broadcast списков, добавлял/изменял на наш 192.168.1.255 - не катило...((( Можно ли пробовать добавить строку «broadcast 239.255.100.100» в /etc/network/interfaces?

Можно ли пробовать добавить строку «broadcast 239.255.100.100» в /etc/network/interfaces?

этого делать точно не следует имхо...

wireshark попробую, сервер debian с gui)) Multicast address 239.255.100.100

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

ну взял WiresharkPortable для винды, выбрал нужные интерфейс, гляжу сижу на строки, сюда тоже гляжу https://wiki.wireshark.org/Multicast_streams... а дальше то что? как узнать что что-то куда-то не идет? в логах мессенджера ошибок нет... вижу в логах что видит других клиентов но не может обновить список контактов...

прописал клиенту наш 192.168.1.255, ищет и находит клиентов по одну (эту) сторону шлюза, но не добавляет в список контакты по другую сторону шлюза... непонятная проблема... разрабам написал неизвестно когда ответят...

думаю не проходят UDP бродкасты через шлюз... стоит ли поиграться с igmpproxy?

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

ну взял WiresharkPortable для винды, выбрал нужные интерфейс, гляжу сижу на строки, сюда тоже гляжу https://wiki.wireshark.org/Multicast_streams... а дальше то что?

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

прописал клиенту наш 192.168.1.255 ... не проходят UDP бродкасты

так все-таки там броадкаст или мультикаст? это немного разные вещи. броадкаст можно аналогичным образом увидеть в wireshark. я кстати хз если честно умеет ли линух в качестве шлюза directed broadcast. все что вижу в сети на эту тему относится к эпохе 2.4, т.е. лет 8-10 назад (тогда не умел).

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

скорее дело в броадкасте. когда мессенджер запускается получает бродкасты от других мессенджеров - Binding UDP listener to port 50000 Joining multicast group 239.255.100.100 on interface D-LINK Starting TCP server UDP datagram received from 192.168.1.42 Мультикаст упоминается только при включении и выключении. В основном в логах бродкасты. Покурю IGMP...

nmap -sU -p 50000 192.168.1.205

Starting Nmap 6.47 ( http://nmap.org ) at 2016-12-27 17:16 +05 Nmap scan report for 192.168.1.205 Host is up (0.024s latency). PORT STATE SERVICE 50000/udp open|filtered unknown MAC Address: 00:FF:9E:5D:E4:23 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

видно что клиент опена за шлюзом виден.

встречал такое понятие как проброс порта... может надо в iptables пробросить Multicast address 239.255.100.100 (и/или192.168.1.255), udp port 50000, tcp port 50000 на рабочий порт OpenVPN-сервера 1194 ?

http://lanmsngr.sourceforge.net/forum/viewtopic.php?f=6&t=952

это вот этот мессенджер? если да - у них на форуме много вопросов по аналогичной теме. вроде как все что нужно - разрешить прохождение directed broadcast через шлюз и добавить удаленную подсеть в конфиг. правда если vpn и локальные клиенты в одной подсети то может возникнуть путаница

там был, цитата с последнего коммента - Maybe, your hardware firewall is blocking the WAN broadcast traffic as well? You may want to check the logs in your firewall. Вот я тоже думаю что это из-за портов... с клиента сделал nmap -sU -p 50000 192.168.1.205 на другого клиента - идет, тоже самое за шлюзом в локалку - доступно...

http://portscan.ru/portscanner.html дает открытые порты 53, 3128, 10000. Какой сервис сканирует ВСЕ порты? погуглю...

Помни что у тебя броадкаст. В плане - так как на L2 нет прямой маршрутизации, роутер должен делать retransmit vpn-клиентам. Как это сделать - надо гуглить

nmap -p «*» 192.168.1.1

Starting Nmap 6.47 ( http://nmap.org ) at 2016-12-27 20:37 +05 Nmap scan report for 192.168.1.1 Host is up (0.000027s latency). Not shown: 4235 closed ports PORT STATE SERVICE 53/tcp open domain 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 631/tcp open ipp 3000/tcp open ppp 3128/tcp open squid-http 10000/tcp open snet-sensor-mgmt

nmap -sU 192.168.1.1

Starting Nmap 6.47 ( http://nmap.org ) at 2016-12-27 20:56 +05 Nmap scan report for 192.168.1.1 Host is up (0.000031s latency). Not shown: 992 closed ports PORT STATE SERVICE 53/udp open domain 67/udp open|filtered dhcps 111/udp open rpcbind 137/udp open netbios-ns 138/udp open|filtered netbios-dgm 631/udp open|filtered ipp 5353/udp open|filtered zeroconf 10000/udp open|filtered ndmp

непонятно, openvpn работает на порту 1194 но этот порт не открыт в iptables... если openvpn работает на порту 1194, то как пустить по tap0-интерфейсу широковещательный сигнал по порту 50000? т.е. если проверка адреса клиентом на 2ip.ru дает адрес шлюза то весь трафик идет как бы внутри моста tap0, значит надо как-то внутри этого моста tap0 тоже открывать порты, н-р 50000...

возможно виноват nat маскарадинг?))

конфиг igmpproxy -

phyint tap0 upstream ratelimit 0 threshold 1 phyint br0 downstream ratelimit 0 threshold 1

ошибка в /var/log/syslog

There must be at least 2 Vif's where one is upstream. хотя читал что интерфейсы можно не указывать когда одна подсеть, если ставлю altnet 192.168.1.0/24 то пишет Unknown token 'altnet' in configfile

ни igmpproxy ни udpxy не помогли... возможно дело в оптороутере? придется звонить провайдеру...

возможно виноват nat маскарадинг?))

ну вот теперь совсем все в одну кучу смешалось.

для начала - как работает мессенджер? как я понял - он умеет мультикаст для локальной подсети (подсети, не сети), и directed broadcast для удаленной.

далее - vpn-клиенты и локальные клиенты сидят в одной подсети. вообще это не слишком хорошая ситуация, и далеко не факт что в ней будет работать directed broadcast. Можно попытаться отключить мультикаст вообще и прописать всем клиентам (и локальным и vpn) броадкаст на их подсеть. Но лучше просто разделить сети и привести сеть в более упорядоченный вид, после чего vpn-клиентам прописать броадкаст на локальную подсеть, а локальным - на vpn-подсеть.

далее - надо посмотреть умеет ли роутер пропускать directed broadcast. для одной подсети - не факт что он умеет такую ретрансляцию. для двух - скорее всего, но надо смотреть.

далее - по поводу ната. нат должен быть настроен только там, где он нужен. для vpn-клиента, который стучит в локалку, никакой нат не нужен в 99% случаев.

далее - по поводу портов. «порт открыт на роутере» - есть правило forward/input с результатом Accept. «порт открыт» - значит «порт открыт на роутере», открыт на конечной машине (аналогично) и конечная машина его слушает каким-либо приложением.

далее - по поводу nmap. получить статус порта для udp - не самая простая задача, т.к. udp по определению не будет посылать SYN/ACK как это делает tcp. Если очень хочется - можно открыть netcat на двух машинах (сервер на роутере, клиент на машине) и посмотреть есть ли связь.

далее - внешний порт-сканнер вообще не должен ничего видеть, это ж блин локальная сеть. если нет завершающего правила drop - значит что-то в этой сети не так.

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

далее - про провайдера. если уже есть vpn - провайдер в 99% случаев ни каким боком тут не замешан

все, выдохнул.

ответ от разработчика BeeBEEP (Secure Lan Messenger)

«hello! I have an idea. Probably your openvpn server can forward just one port of the first client connected.»

Почему, так ли, интересно? Это про тот мессенджер, который способен бить через мост tap0 OpenVPN, но там проблема передачи файлов - клиент, который первым запустил у себя этот мессенджер, способен отправлять файлы через мост OpenVPN другому клиенту, который запустил свой мессенджер после первого клиента...

Неужто такое может быть что OpenVPN может работать только с одним портом одновременно?

Сейчас на вирт.машине и физич.компе запущу Qualia LAN Messenger для анализа логов на предмет подключений, бродкаста, мультикаста.

Могу прислать на мыло Вам для анализа работы этого мессенджера.

на модеме зюхель клиентов опена шел адрес 192.168.1.0, когда клиент подключался к опену их комп как бы не замечал смены сети... и соответственно была проблема с прохождением трафика через опен. На модеме сменил сеть на 192.168.0.0 и больше проблем не было.)

на модеме зюхель клиентов опена шел адрес 192.168.1.0, когда клиент подключался к опену их комп как бы не замечал смены сети... и соответственно была проблема с прохождением трафика через опен. На модеме сменил сеть на 192.168.0.0 и больше проблем не было.)

ок, но почему было бы не сменить на, скажем, 192.168.123.0? чтоб подсети не пересекались?

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

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

Решение лежит здесь)))

OpenVPN-сервер на отдельном компьютере (комментарий)