Одноранговая связь в сложной локальной сети с несколькими подсетями
Мы разрабатываем приложение P2P и застряли на части установления связи между двумя одноранговыми узлами, которые находятся в одной локальной LAN, но в двух разных подсетях.
Мы знаем, что во многих случаях 2 определенных компьютера в одной локальной сети определенно «не могут быть подключены» из-за настроек некоторых маршрутизаторов. Мы просто пытаемся разобраться в ситуации и выяснить все, что мы можем сделать. (с нашими ограниченными знаниями в области сетей и вашей помощью)
Рассмотрим ЛВС со структурой, показанной на следующем рисунке. Предположим, что локальная сеть разработана нашим клиентом, а мы ничего не знаем. Мы просто наблюдаем за ЛВС с точки зрения ПК, на котором установлена наша программа. Таким образом, все, что мы знаем, это наш localIP / subnetMask и общий общедоступный IP-адрес всей локальной сети. (Остальное неизвестно и отображается в виде облака)
У нас есть несколько вопросов, на которые мы очень готовы ответить:
Предположим, что когда ПК1 выполняет многоадресную рассылку пакета, пакет каким-то образом достигает ПК2. Какой IP-адрес будет видеть ПК2 для отправителя пакета: локальный IP-адрес ПК1 (как на рисунке 192.168.1.111) или внешний IP-адрес Router_A_1 или Router_A?
После №1, если ПК2 ответит другим пакетом (одноадресная передача) на IP-адрес, который ПК2 видит в №1, дойдет ли пакет до ПК1?
В глобальных случаях № 2 какой IP-адрес может быть подходящим, который ПК1 и ПК2 используют для отправки пакетов другому? (Или это то же самое, что мы делаем через Интернет с двумя компьютерами за NAT-маршрутизаторами: upnp, перфорация или промежуточный суперузел?)
Есть ли случай, когда ПК1 и ПК2 назначаются с одним и тем же IP-адресом? Если это правда, то:
- а. Это «юридический» случай?
- б. Что насчет IP-адреса отправителя, который ПК2 видит в №1 и отвечает на №2?
Обновить дополнительный вопрос:
- Верно ли, что если 1 одноранговый узел многоадресной рассылки и пакет может достичь другого однорангового узла, тогда 2 ПК являются «одноадресными» - и если многоадресный пакет не может достичь другого однорангового узла, тогда 2 ПК обречены? Верно ли это для «одноадресной рассылки -> многоадресной рассылки»?
Я написал несколько одноранговых приложений и могу сказать вам, что доступность одноранговых узлов является основной проблемой для таких приложений. Вот несколько указателей:
если вы используете TCP, ваша единственная надежда - UPnP. Однако нельзя предполагать, что он всегда доступен. Фактически UPnP (а) в основном поддерживается домашними сетевыми маршрутизаторами (б) он часто отключается, поскольку люди не видят в нем особой ценности или не видят в нем никакой ценности, поэтому его поддержка носит спорадический характер. Ваши шансы еще меньше, если ваши клиенты находятся за 2-мя уровнями маршрутизаторов, каждый из которых выполняет свой собственный NAT. Но если вы можете сказать своим клиентам включить UPnP или указать UPnP в качестве предварительного условия для вашего приложения, тогда это правильный путь.
Другой вариант - использовать UDP и пробить отверстие в маршрутизаторе, но вам понадобится внешний агент, который отслеживает адрес узла и сопоставляет идентификатор хоста с глобально доступным IP-адресом (в вашем случае он, вероятно, будет развернут в «Неизвестном»). Обратите внимание, что TTL отверстий для контактов UDP обычно очень короткое (по моим оценкам, от 20 секунд до 5 минут), поэтому вам придется часто пинговать своего агента. Другая проблема с UDP заключается в том, что вам может потребоваться реализовать собственный протокол управления потоком, если ваше приложение обменивается битами данных, размер которых превышает 1 пакет.
Надеюсь это поможет.
Вы не сказали, но ..
Если вы используете традиционную 24-битную маску подсети (т. Е. Обе сети - 192.168.1.0/24), то эти машины никогда не смогут обмениваться данными, потому что по определению они будут пытаться разрешить MAC-адрес посредством широковещательной рассылки вместо того, чтобы переходить к шлюзу для маршрутизация, поскольку предполагается, что машина находится в локальной сети.
Вы можете исправить это, назначив ПК1 адрес в другой сети.
СО ПК1 = 192.168.2.111
В этом случае, пока промежуточные маршрутизаторы имеют правильные записи в таблице маршрутизации и разрешают многоадресную рассылку и разрешают любой порт / протокол, который вы пытаетесь использовать, он должен работать.
Топология вашей сети в лучшем случае ненадежна и сложна в обслуживании.
Рассмотрим это (при условии / 24 подсети): ПК1 (192.168.1.111) пытается отправить пакет на ПК2 (192.168.1.22). Почему Router_A_1 (или даже Router_A) должен пересылать этот пакет через «неизвестное» облако в другую подсеть? Что касается маршрутизаторов "A", пакет уже находится в подсети, которой он принадлежит. Возможно взломать некоторые таблицы маршрутизации в маршрутизаторах для пересылки определенных адресов - но вы обнаружите, что именно отсюда возникает «ненадежная и сложная» часть (и может быть даже непрактичной в зависимости от того, что находится в «неизвестном» облаке).
Есть ли причина, по которой вы не можете просто выделить другой / 24 для подсетей маршрутизатора "B"? Например 192.168.2.0/24?