Я не уверен, подходит ли этот вопрос больше для stackoverflow или serverfault. Если вы считаете, что это больше подходит для stackoverflow, дайте мне знать, и я удалю это и перенесу.
У меня есть реализация STUNT. Если вы не знаете, что такое STUNT, это протокол, используемый для прямого TCP-соединения между двумя одноранговыми узлами за отдельными NAT. Я дам краткий обзор, хотя мой вопрос не имеет прямого отношения к протоколу.
Это делается с помощью третьей стороны, чтобы предсказать, какой порт NAT каждого из узлов сопоставит их следующее исходящее соединение. Затем третья сторона сообщает каждому партнеру предсказанный порт другого, и они оба пытаются подключиться друг к другу на предсказанных портах. Когда они отправляют друг другу свои SYN-пакеты, это открывает «дыру» в NAT на этом порту, что позволяет проходить SYN-пакету и устанавливать соединение.
Один из моих коллег предложил, чтобы одноранговый узел, который инициирует попытку соединения STUNT, отправлял пакеты SYN на предсказанный порт, а также на следующие четыре порта, в случае, если предсказанный порт используется другим приложением (или даже нашим приложением) до того, как наш попытка подключения, но после того, как были сделаны прогнозы.
Примером этого может быть прогноз, что другой одноранговый узел будет подключаться к нам через порт 80, но затем другое приложение в конечном итоге использует порт 80, так что соединение фактически исходит из порта 81; но отправляя SYN-пакеты на пять разных портов, мы (теоретически) добились бы успеха, если бы они приходили с 80, 81, 82, 83 или 84.
Однако это не так; при тестировании только первый пакет SYN имеет шанс на успех. Даже если первый SYN-пакет отправлен на неправильный порт, но один из следующих четырех отправляется на правильный порт, все они автоматически отбрасываются; нет ответа, просто время ожидания попытки подключения.
Быстрый пример:
Узел A инициирует соединение STUNT с узлом B.
Предполагается, что одноранговый узел A подключится к одноранговому узлу B через порт 1000.
Предполагается, что одноранговый узел B подключится к одноранговому узлу A через порт 2000.
Сервер отправляет 1000 партнеру B и 2000 партнеру A.
Другое приложение на компьютере Peer B устанавливает новое соединение, занимая порт 2000.
Другое приложение на компьютере Peer A устанавливает новое соединение, занимая порт 1000.
Узел A одновременно пытается подключиться к узлу B через порты 2000, 2001, 2002, 2003 и 2004; попытки подключения поступают с портов 1001, 1002, 1003, 1004 и 1005.
Узел B пытается подключиться к узлу B через порт 1000; попытка подключения идет с порта 2001.
В NAT узла A и узла B создается дыра на портах 1001 и 2001 соответственно; он должен пропускать SYN-пакеты.
Я считаю, что происходит то, что NAT узла B не пропускает пакет SYN узла A через порт 2001, потому что он ожидал, что соединение будет исходить от 1000, но оно пришло от 1002. Это наводит на мысль, что NAT проверяет источник пакет SYN.
Однако из того, что я читал, один недостаток STUNT заключается в том, что при создании соединения возникает окно уязвимости, в котором соединение может быть перехвачено другим источником. Если проверка источника входящего соединения для NAT является стандартным поведением, то я не понимаю, как может существовать это окно уязвимости.
Обратите внимание, что моя реализация не ошибочна. Если один из предсказанных портов верен, соединение будет успешным; проблема возникает, когда оба предсказанных порта неверны, и он пытается использовать несколько портов одновременно.
В качестве примечания для всех, кто знаком с протоколом, я использую метод, который включает отправку SYN, который, как я ожидаю, будет молча перед попыткой фактического подключения. Я не использую реализацию с низким TTL.
Мой NAT отклоняет пакеты SYN, потому что они не приходят из ожидаемого порта, или что-то другое отклоняет их? Если это мой NAT, это ожидаемое / стандартное поведение? Обратите внимание, что под отклонением я подразумеваю «тихое отключение», поскольку RST или какой-либо ответ вообще не возвращается, соединения просто истекают по таймауту.
РЕДАКТИРОВАТЬ: Речь идет о маршрутизаторах, которые вы бы купили в Walmart для домашнего использования, а не о том, что используют крупные компании.
Краткий ответ: Да - ваш NAT отклоняет пакеты, потому что они не совсем то, что он ожидает. Это будет варьироваться от реализации NAT к реализации NAT.
От редакции: я раньше не слышал о STUNT ... (STUN, да - не STUNT). Ох, ох ... что за взлом. Это заставляет меня плакать, что Интернет превратился в парк трейлеров NAT и что мы прибегаем к подобным взломам.
После прочтения бумага Я понимаю, что они делают. По сути, это STUN с добавленным битом перехвата пакетов на каждой «конечной точке», чтобы обнюхивать исходные порядковые номера и передавать их через стороннюю организацию в сети, которая может принимать произвольные входящие TCP-соединения. На самом деле, это милый трюк.
Такого 100% надежного общения вы никогда не получите. Я вижу, что у исследователей, которые изначально это реализовали, есть результаты теста которые выглядят довольно хорошо при прогнозировании портов, хотя ... Это на самом деле очень интересная, хотя и плотная, маленькая диаграмма. В статье более подробно рассматриваются все вопросы прогнозирования и приводятся некоторые процентные показатели успеха. На самом деле меня шокирует, что они так хорошо справились.
Любая разумная реализация NAT будет использовать, как минимум, исходный IP-адрес, IP-адрес назначения, протокол, порт источника протокола и порт назначения протокола для идентификации «соединений». (Надеюсь, они также отслеживают порядковые номера / номера подтверждений.)
Если ваш SYN не совсем соответствует комбинации этих атрибутов, хранящихся в таблице NAT устройства, реализация NAT действительно должна молча отбросить его. Я ожидал такого поведения.