Децентрализованное приложение через NAT - PullRequest
0 голосов
/ 20 мая 2019

В настоящее время я пишу приложение P2P, используя golang.Для этого я выбрал Noise , поскольку он предоставляет простой в использовании сетевой стек.

Мое приложение предоставляет REST API, к которому можно получить доступ через localhost.Данные, которые отправляются на локально предоставленные конечные точки, будут затем передаваться всем подключенным одноранговым узлам, которые затем распределяют данные по своим подключенным одноранговым узлам для синхронизации сети.

До сих пор я добился успеха с моей реализацией, однако этоработает только для публично представленных узлов или узлов в одной и той же сети.

Я бы хотел максимально упростить использование моего приложения, в том числе для пользователей в частных сетях.Поэтому я хочу избежать ручной настройки (т. Е. Переадресации портов в настройках маршрутизатора).Если это вообще возможно, я также хотел бы избежать использования центрального сервера для NAT-Traversal, поскольку моя цель - создать действительно децентрализованное приложение.

Я понимаю, что существует несколько методов NAT-Traversal, таких каккак STUN и TURN , наряду с другими, и я знаю, что Noise уже предлагает NAT-PMP и UPnP , но как-то не могуОбдумайте, как именно они работают.

Я знаю, что некоторые VoIP-сервисы или службы общего доступа к файлам используют NAT-PMP и, похоже, работают практически во всех сетях без какого-либо взаимодействия с пользователем.Это просто кажется мне немного странным, и я застрял.

Как такое возможно, что мое приложение просто волшебным образом изменяет некоторые конфигурации маршрутизатора для приема входящего трафика?Мне кажется, что это огромный риск для безопасности, особенно если пользователь моего приложения даже не знает об этом.Также я понял, что не каждый маршрутизатор поддерживает NAT-PMP и UPnP.Что если у моих пользователей есть один из них?

Ответы [ 2 ]

1 голос
/ 20 мая 2019

Как это возможно, что мое приложение просто волшебным образом изменяет некоторые конфигурации маршрутизатора для приема входящего трафика? Мне это кажется огромным риском для безопасности, особенно если пользователь моего приложения даже не знает об этом.

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

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

Если ваше P2P-приложение не имеет открытого порта, оно все равно будет устанавливать исходящие соединения с различными узлами в P2P-сети, и если один из них является вредоносным и ваше приложение уязвимо, его можно использовать.

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

Кто-то все равно должен открыть свои порты, иначе никто в Интернете не сможет ни с кем разговаривать.

В конце концов, гораздо важнее сосредоточиться на усилении сетевого стека приложений, которые должны быть подключены к Интернету.

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

NAT-PMP и аналогичные, с другой стороны, существуют, чтобы позволить вам создать необходимую поверхность атаки просто потому, что приложения не могли функционировать иначе без возможности использования сети.

Кроме того, я понял, что не каждый маршрутизатор поддерживает NAT-PMP и UPnP. Что если у моих пользователей есть один из них?

UDP дырокол - это стратегия обхода NAT, которая не требует взаимодействия с маршрутизатором.

Кроме того, вы можете попросить пользователей настроить свои брандмауэры / правила переадресации портов вручную.

Но если все стратегии обхода nat терпят неудачу, то следующий вопрос заключается в том, необходимы ли прямые одноранговые соединения для работы вашего протокола. Например, в bittorrent их нет, в этом случае достаточно сформировать связный граф, а не полностью связный граф. Подобные вещи могут работать для групповых чатов.

Для связи один на один у вас есть возможность либо сообщить пользователю, что его сеть блокирует соединение, либо использовать альтруистические (или платные) узлы, предоставляющие услуги ретрансляции данных.

0 голосов
/ 20 мая 2019

Без общедоступного центрального сервера каталогов это невозможно.У сверстников нет возможности идентифицировать друг друга.Это не означает, что сервер должен участвовать в какой-либо одноранговой связи.Я просто разрешаю обнаружение точки входа в сеть p2p.

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

...