Я провел некоторое исследование по обмену p2p без базового сервера и пришел через STUN. Из того, что я прочитал, STUN - это способ NAT "Hole Punching", который не требует, чтобы одноранговый порт был перенаправлен в порт для подключения. Правильно ли это, и что именно означает пробивка отверстий? Все это кажется очень уязвимым, поскольку он проходит через брандмауэр, если он не требует перенаправления портов, и я не совсем понимаю, что делает STUN. Можно ли использовать STUN в программе p2p на Java или на другом языке, таком как клиент чата, который отправляет сообщения через порты TCP/UDP партнеру БЕЗ базового сервера или БЕЗ, требуя от пользователя перенаправления?
Что такое STUN и нужен ли ему сервер с переадресацией портов?
Ответ 1
Рассмотрим задачу двух машин, которые хотят общаться друг с другом. Если две машины подключены напрямую к общедоступному Интернету (не за маршрутизатором), то эти две машины просто отправляют пакеты друг другу в открытый IP-адрес. Как правило, машины находятся за одним или несколькими маршрутизаторами. Чтобы упростить задачу, мы предполагаем только один уровень маршрутизаторов.
Обход NAT решает проблему маршрутизаторов, переводящих исходящий номер порта пакетов во что-то другое (например, вы отправляете запрос от порта X, маршрутизатор переводит пакет так, как если бы он ушел из порта Y вместо). Если маршрутизаторы перенаправляют порт, то маршрутизатор фактически не выполняет никакого перевода (порт X- > X). Однако большинство домашних/корпоративных/и т.д. Маршрутизаторов не являются переадресацией портов, и, таким образом, NAT-переходы вступают в игру. См. NAT traversal и различные типы NAT.
Рассмотрим брандмауэр маршрутизатора, который выполняет любые переводы, не связанные с переносом портов в вышеупомянутой статье (например, полный конус). Если маршрутизатор получает какой-либо пакет в порт X, но маршрутизатор не отправил никаких пакетов из порта Y, он упадет пакет (в конце концов, кому был пакет, маршрутизатор не знает!). Только тогда, когда какая-то частная машина отправляет пакет, а маршрутизатор делает перевод для переноса порта X с этой частной машины на внешний порт Y, внешние пакеты в порт Y отправляются на частную машину.
Обход STUN
Для того, чтобы два клиента, A и B, оба за брандмауэрами через Интернет, чтобы напрямую общаться, они должны каким-то образом знать картографирование маршрутизатора. Общее решение - использовать сервер STUN для определения их сопоставления портов. Машина A отправляет пакет X формы пакета в STUN. Маршрутизатор перевел порт в Y, и сервер STUN видит это и отвечает А, сообщая ему, что такое внешний порт. B делает то же самое. Затем A и B обменивают свои переведенные порты (используя какой-то другой центральный сервер... для упрощенного примера у Skype может быть центральный сервер входа, где A и B сообщают серверу Skype их переводы на порт, а Skype сообщает A и B соответственно о сопоставлениях портов). Затем B отправляет пакет в открытый IP-адрес с использованием порта Y, а не X. Машина A "пробивает" свой брандмауэр, позволяя ему принимать пакеты из внешнего порта Y.
Secure?
Вы упомянули о безопасности: происходит ли пробивание отверстий в сети до нарушений безопасности? Потенциально... Я не изучал эту тему, но рассматриваю полный конус NAT. После создания сопоставления ЛЮБАЯ внешняя машина может отправлять пакеты на машину. Маршрутизатор и A получат пакеты, даже если A никогда не отправил пакет на какую-то вредоносную машину Z. Машина Z, конечно, должна была бы как-то обнаружить отображение, В некоторых статьях в Википедии на диаграмме показаны только все кодовые NAT, обладающие этой уязвимостью, но не задумывайтесь об этом. Судя по количеству приложений, использующих перфорирование отверстий (Skype, xbox live,...), казалось бы, сети полагаются на защиту брандмауэра приложений и системного уровня в дополнение к мерам брандмауэра маршрутизатора.
В приведенной ниже статье Ford упоминается безопасность: "Вопреки тому, что может предложить его название, перфорация отверстий не ставит под угрозу безопасность частной сети". Казалось бы, сети используют брандмауэры на системном уровне больше, чем брандмауэры маршрутизатора.
Симметричные NAT и обход TURN
STUN не всегда работает: некоторые маршрутизаторы "ведут себя плохо". Машина A может отправить два пакета из порта X, один в stackoverflow.com и один на facebook.com. Маршрутизатор сопоставляет пакет stackoverflow.com FROM port Y и пакет facebook.com FROM port Z (даже если машина A отправляет оба пакета из внутреннего порта X). Это симметричный NAT. Эти NAT являются проблематичными, поскольку вышеупомянутое соединение STUN/Skype не будет работать. Замените stackoverflow.com на STUN и facebook.com на машине B (человек, с которым вы пытаетесь связаться с Skype). К сожалению, STUN может найти сопоставление NAT для пакетов, отправленных в STUN, но пакеты, отправленные в B, используют совершенно другое сопоставление. В общем случае невозможно (без возможности отслеживать исходящие пакеты маршрутизатора) для определения сопоставлений портов для симметричных NAT. Таким образом, для общения клиентов требуется центральный сервер маршрутизации, но это побеждает всю точку p2p. См. TURN.
Можем ли мы использовать это в программе чата Java?
Любой язык с поддержкой сетевой библиотеки (Java, C и т.д.), где вы можете отправлять пакеты с произвольных портов, может использовать STUN для обхода NAT (пока это не симметричный NAT и т.д.). В общем, всегда нужен центральный сервер (в данном случае два: STUN и сервер входа в систему). Сервер входа в систему используется, как описано в примере Skype; когда два клиента знают свои сопоставления портов, они должны сообщать об этом друг другу как-то до начала обмена p2p (см. курица или яйцо). Но как только A и B узнают друг друга об общедоступных IP-адресах и NAT-адресах, они могут общаться напрямую.
Caveat
Хотя я не могу перечислить все предостережения об обходе NAT, одна важная концепция остается в живых: как только маршрутизатор выполнил сопоставление портов, как долго это будет продолжаться? Скажем, я подключился к STUN-серверу, а затем подождите 10 минут, чтобы B послал мне пакет, как только я скажу ему сопоставление. Маршрутизатор, скорее всего, сбросил отображение (маршрутизаторы должны регулярно очищать старые сопоставления, чтобы освободить место для новых и минимальную попытку безопасности). Я не могу найти свою ссылку, и я думаю, что она зависит от TCP и UDP-пакетов, но приложения, с которыми я знаком, отправляют пакет keep-alive каждые ~ 60 секунд или меньше, чтобы гарантировать, что маршрутизатор не потерял отображение. После того, как маршрутизатор сбросит отображение и машины, пытающиеся отправить пакеты, пакеты будут удалены (что приведет к часам путаницы для меня...).
Статьи
Последняя статья - отличное введение во многие идеи для маршрутизаторов и обхода NAT в жанре. Я прочитал это некоторое время назад, когда я реализовал некоторые процедуры сервера/клиента TURN, и авторы действительно знают, о чем они говорят!