История изменений
Исправление upcFrost, (текущая версия) :
возможно виноват 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% случаев ни каким боком тут не замешан
все, выдохнул.
Исходная версия upcFrost, :
возможно виноват 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 и куда и как его проксировать. с броадкастом в этом плане работать легче, и если софт его умеет - не стоит усложнять.
все, выдохнул.