Что такое STUN и нужен ли ему сервер с перенаправлением портов?

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

обход NAT решает проблему маршрутизаторов, переводящих количество исходящих портов пакетов во что-то иначе (например, вы отправляете запрос из порта X, маршрутизатор переводит пакет, чтобы действовать так, как если бы он ушел из порта Y). Если маршрутизаторы являются переадресацией портов, то маршрутизатор фактически не выполняет никакого перевода (порт X->X). Однако большинство маршрутизаторов home/corporate/etc не являются переадресацией портов, и поэтому в игру вступает NAT traversal. См.NAT traversal и различные типы NATs.

рассмотрим брандмауэр маршрутизатора, который выполняет любую из не-переадресацию портов переводы в вышеуказанной статье (e.г. полный конус). Если маршрутизатор получает какой-то пакет на порт X, но маршрутизатор не отправил никаких пакетов из порта Y, он отбрасывает пакет (в конце концов, кому предназначался пакет? маршрутизатор понятия не имеет!). Только когда какая-то частная машина отправляет пакет, и маршрутизатор делает перевод для сопоставления порта X с этой частной машины на внешний порт Y, внешние пакеты на порт Y будут перенаправлены на частную машину.

электрошокеры обход

In заказ для двух клиентов, A и B оба за брандмауэрами через Интернет, чтобы общаться напрямую, они должны каким-то образом знать отображение маршрутизатора. Общее решение-использовать сервер STUN для определения их сопоставления портов. Машина A отправляет порт формы пакета X для оглушения. Маршрутизатор перевел порт на Y, и сервер оглушения видит это и отвечает на сообщение ему, что внешний порт был. Б делает то же самое. Затем A и B обмениваются переведенными портами (используя некоторые другие центральные сервер...для упрощенного примера Skype может иметь центральный сервер входа, где A и B сообщают серверу Skype свои переводы портов, а Skype сообщает A и B соответственно о сопоставлениях портов). Затем B отправляет пакет на общедоступный IP-адрес A, используя порт Y, а не X. Машина A "пробила" его брандмауэр, позволяя ему получать пакеты от внешнего порта Y.

безопасное?

вы упоминаете безопасность: пробивание отверстий открывает сеть для нарушений безопасности? Потенциально...Я не изучил предмет, но рассмотрим полный конус NAT. Как только сопоставление выполнено, любая внешняя машина может отправлять пакеты на маршрутизатор машины A, и A получит пакеты, даже если A никогда не отправлял пакет какой-либо вредоносной машине Z. машина Z, конечно, должна была бы каким-то образом обнаружить сопоставление. В некоторых статьях Википедии диаграмма показывает только полные конусы, имеющие эту уязвимость, но не верьте мне на слово. Судя по количеству приложений, использующих дырокол (Skype, xbox live, ...), казалось бы, Сети полагаются на защиту брандмауэра на уровне приложений и системы в дополнение к мерам брандмауэра маршрутизатора.

в статье Ford ниже кратко упоминается безопасность: "вопреки тому, что может предложить его название, пробивка отверстий не ставит под угрозу безопасность частной сети."Казалось бы, Сети полагаются на брандмауэры системного уровня больше, чем брандмауэры маршрутизаторов.

симметричные Натс и поворот обхода

STUN не всегда работает: некоторые роутеры " ведут себя плохо."Машина A может отправить два пакета из порта X, один в stackoverflow.com и один к facebook.com - ... Маршрутизатор сопоставляет stackoverflow.com пакет из порта Y и facebook.com пакет из порта Z (даже если машина A отправляет оба пакета из внутреннего порта X). Это симметричный NAT. Эти NATs проблематичны, так как вышеуказанное соединение оглушения/Skype не будет работать. Заменить stackoverflow.com с оглушением и facebook.com с машиной B (человек, с которым вы пытаетесь связаться по Skype). К сожалению, STUN может найти сопоставление NAT для пакетов, которые A отправляет STUN, но пакеты, отправленные B, используют совершенно другое сопоставление. В общем, невозможно (без возможности отслеживать исходящие пакеты маршрутизатора) определить сопоставления портов для симметричных NATs. Таким образом, центральный сервер маршрутизации необходим для связи клиентов, но это побеждает весь смысл p2p. См.поворот.

можем ли мы использовать это в программе чата Java?

любой язык с поддержкой сетевой библиотеки (Java, C и т. д.), Где вы можете отправлять пакеты из произвольных портов, можно использовать STUN для обхода NAT (если это не симметричный NAT и т. д.). В общем, один всегда нужен центральный сервер (в данном случае два: STUN и A логин сервер). The логин сервер используется, как описано в Примере Skype; как только два клиента знают свои сопоставления портов, они должны как-то сообщить об этом друг другу до Р2Р общение началось (см. курица или яйцо). Но как только A и B знают публичные IPS и NAT-сопоставления друг друга, они могут напрямую общаться.

предостережение

хотя я не могу перечислить все предупреждения об обходе NAT, одна важная концепция-сохранить жизнь: как только маршрутизатор сделал сопоставление портов, как долго это будет продолжаться? Скажем, я подключаюсь к серверу STUN, а затем жду 10 минут, пока B отправит мне пакет, как только я скажу ему сопоставление. Маршрутизатор, вероятно, будет иметь отбросил сопоставление (маршрутизаторы должны регулярно очищать старые сопоставления, чтобы освободить место для новых и для минимальной попытки безопасности). Я не могу найти свою ссылку, и я думаю, что она зависит от пакетов TCP vs UDP, но приложения, с которыми я знаком, отправляют пакет keep-alive каждые ~60 секунд или меньше, чтобы маршрутизатор не отбрасывал сопоставление. Как только маршрутизатор отбросит сопоставление и машины, пытающиеся отправить пакеты, пакеты будут отброшены (что приведет к часам путаницы для мне...).

статьи

• RFC 5389 STUN
• RFC 5766 ПОВОРОТ
• одноранговая связь через переводчики сетевых адресов. Б. Форд и др.

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