Как пакеты выходят даже за брандмауэром или NAT с некоторым приложением?

Question

Например, Skype / Team viewer / Logmein и т. Д., Которые отправляют аудио / видео за NAT (за брандмауэром). Но когда я создал маленькое крошечное приложение, которое отправляло текст в другое местоположение NAT, оно не могло сделать то же самое.

Example: 

Sender: 
-> Public ip: 91.1.2.3 My lan ip is: 192.168.1.2 with port 14446 udp
-------> Data format: RTP packets
Receiver:
<------- Data received: 0 packets
-> Public ip: 92.1.2.3 Friend lan ip is: 10.0.0.2 with port 14446 udp

* same in both way

Как другие это делают? Как можно выполнить одноранговую разработку приложений для преодоления проблем NAT? У нас всегда есть публичные IP-адреса, и в основном у них есть проблемы с NAT.

Но как же тогда работает Skype в таких случаях? У нас есть диапазон аудио / видео портов для UDP или всегда UDP открыт от чего-либо? Но мой не работает выше портов диапазона для UDP, я также пытался. В чем секрет? это делает меня любопытным !!.

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

Answer 1

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

См. Статью Википедии о NAT *

Для большинства NATSTUN позволит вам открыть порты и выяснить, какой порт вы открыли (может отличаться от порта, с которого вы отправили).В SIP и RTSP вы обычно предоставляете внешний IP-адрес и порт, определенные STUN, для другого конца.

Полностью симметричный NAT означает, что STUN не позволит вам использовать сторонний сервер для поддержки портов через STUN, поэтому вам придется использовать UPnP (если включено) или сопоставлять порты в маршрутизаторе (или настроить триггеры), или вам придется играть в злые игры, чтобы заставить обе стороны думать, что они инициировали соединение.(Не легко и не гарантировано.)

См. Спецификации ICE & TURN (RFC) от IETF для подробных механизмов для прохождения NAT - хотя обратите внимание, что в некоторых случаях вы должны использовать внешний прокси для пересылки пакетов.

Answer 2

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

Answer 3

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