LINUX.ORG.RU

История изменений

Исправление 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 и куда и как его проксировать. с броадкастом в этом плане работать легче, и если софт его умеет - не стоит усложнять.

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