Nat Traversal, сверстники не могут общаться

В настоящее время я работаю над проектом, который требует обхода NAT, но, похоже, у меня возникают трудности. У меня для тестирования запущена следующая установка:

• R1, маршрутизатор Verizon Fios подключен к Интернету.
• R2, маршрутизатор Belkin подключен через свой WAN-порт к коммутатору R1 через Ethernet.
• i, вводный сервер, подключенный через Ethernet к R1. R1 перенаправляет порт 6666 на i.
• A и B, компьютеры с клиентским программным обеспечением, подключенные к R2 через Wi-Fi.

Введение в описание сервера и клиента:

Когда A и B запускают своего клиента, клиент отправляет «HelloPacket» на внешний адрес R1 (72.82.59.10) через порт 6666.

После получения HelloPacket сервер сначала проверяет, видел ли он ранее адрес источника и идентификатор порта источника.

• В противном случае он сначала отправляет каждую запись в своей таблице идентификаторов одноранговых узлов (исходный ip / порт) узлу, от которого он получил HelloPacket, а затем сохраняет это как новую запись в своей таблице одноранговых узлов.
• Если да, то он сбрасывает тайм-аут одноранговых узлов, чтобы знать, что нужно продолжать отправлять этот идентификатор одноранговым узлам одноранговым узлам, которые подключаются в будущем.

После того, как клиент изначально отправляет HelloPacket на сервер Intro, он может ожидать получения от сервера пакетов, называемых IntroPackets, если есть одноранговые узлы, которые уже представились серверу. Эти IntroPackets содержат как внешний, так и внутренний IP / порт однорангового узла.

Теперь, когда одноранговый узел знает о существующих одноранговых узлах, он должен отправить HelloPacket существующим одноранговым узлам, чтобы сообщить им о его существовании. Вот где у меня проблемы.

У меня недостаточно репутации, чтобы публиковать изображения, но вот диаграмма, которую я нарисовал: http://i.stack.imgur.com/7E5I8.png

Вот порядок событий и проблема, с которой я столкнулся:

1. Начальный сервер запускается и прослушивает UDP-пакеты типа "HelloPacket".
2. Узел A запускает своего клиента, который, в свою очередь, отправляет HelloPacket на сервер Intro по адресу / порту: 72.82.59.10, 6666
3. Вступительный сервер получает HelloPacket и добавляет запись в свою таблицу и не отправляет IntroPackets одноранговому узлу A, поскольку в его таблице нет других одноранговых узлов. Запись в таблице для однорангового узла A выглядит следующим образом: IP: 72.82.59.10, порт: 1024
4. Узел B запускает своего клиента, который, в свою очередь, отправляет HelloPacket на вводный сервер.
5. Вступительный сервер получает HelloPacket и добавляет запись в свою таблицу. Затем вводный сервер отправляет IntroPacket новому подключенному партнеру, который содержит адрес и порт партнера А. Таблица вводного сервера на этом этапе выглядит следующим образом:

Партнер A: 72.82.59.10, 1024

Партнер B: 72.82.59.10, 1025

6. Узел B получает IntroPacket, а затем пытается отправить пакет приветствия узлу A.

Шаг 6 - вот где мой дизайн терпит неудачу. Одноранговый узел A никогда не получает HelloPacket от узла B. Насколько я понимаю, когда маршрутизатор получает пакет с портом назначения 1024, он сопоставляет его с внутренним адресом и портом, используя его NAT. Это верно?

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

Я также знаю, что мне следует попытаться подключиться к внутреннему адресу и порту, чтобы увидеть, находятся ли клиенты за одним и тем же NAT, и планирую реализовать это в будущем.

Кроме того, вся связь осуществляется надежно с использованием Go-Back-N как в клиентском, так и в серверном коде.

Вопросы:

1. Я упускаю из виду что-то важное в своем дизайне или просто не понимаю прохождение NAT с помощью UDP?
2. По каким причинам узел A сможет получить пакет от сервера, но не узел B? (Поскольку одноранговые узлы могут получать пакеты обратно с сервера)
3. Учитывает ли NAT адрес источника?

Любой вклад очень ценится !! Спасибо!