Как узнать тип NAT, за которым стоит данный интерфейс

Я хотел бы узнать тип NAT (FullCone, Restricted Cone, Port Restricted cone, Symmetric), за которым находится данный сетевой интерфейс.

Я тестировал разные инструменты ( http://freshmeat.net/projects/jstun/, http://code.google.com/p/boogu/), но они сообщают о разных результатах для одного и того же интерфейса.

Я ищу точный ответ в Python (или других языках, 2-й вариант - Java, если больше ничего не доступно).

Источник

3 ответа

Второй ответ от @S.Lott: Невозможно использовать STUN (или любой другой протокол), чтобы со 100% уверенностью определить, за каким типом NAT вы находитесь.

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

Когда вы думаете об этом, то, будучи зависимым от адреса, означает, что когда вы отправляете пакеты из одного сокета на клиенте за NAT на два разных сервера, тогда NAT создаст два пользовательских общедоступных адреса: кортежи портов для каждого из серверов. В моем случае эти привязки казались совершенно случайными, но если диапазон был небольшим, иногда случалось, что эти кортежи были фактически равны! Что смутило тест.

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

Это случилось со мной на мобильном устройстве со словацким Telekom, компанией, в основном принадлежащей Deutsche Telekom, поэтому я думаю, что проблема будет, по крайней мере, по всей Европе.

Я бы сказал, что правило здесь таково: если тест STUN говорит вам, что вы находитесь за Symmetric NAT, чем это имеет место, но если он говорит вам об обратном, вы не можете быть на 100% уверены.

И последнее замечание: простой способ проверить поведение вашего NAT в отношении TCP - это ввести в Google "какой у меня IP-адрес", а затем открыть сначала (скажем) пять страниц. Если страницы не соответствуют вашему IP-адресу, поведение NAT зависит от адреса или от адреса и порта (симметрично). Но опять же, если они соответствуют, вы просто не можете быть уверены.

Источник

http://en.wikipedia.org/wiki/STUN

Устройства NAT реализованы в нескольких различных типах схем адресов и портов. STUN не работает правильно со всеми из них.

Это достаточно определенно? Это всего лишь цитата из Википедии, но, похоже, ваш запрос физически невозможен.

Источник

Как говорит @S.Lott, STUN - ваш протокол выбора.

И потом, STUN - это просто протокол. Вот мой совет:

1 STUN теперь имеет две версии: старая версия RFC3489 - это упрощенный протокол, который позволяет приложениям обнаруживать наличие и типы NAT и межсетевых экранов между ними и общедоступным Интернетом (так что это в основном и только для определения типа NAT); и новая версия RFC5389 - это инструмент для других протоколов в работе с обходом NAT.

2 Также имеется расширение реле для STUN с именем TURN RFC5766. TURN позволяет хосту управлять работой ретранслятора и обмениваться пакетами со своими одноранговыми узлами, используя ретранслятор. TURN отличается от некоторых других протоколов управления ретрансляцией тем, что он позволяет клиенту обмениваться данными с несколькими узлами, используя один адрес ретрансляции.

Инструменты:

Примечание. Поскольку TURN является расширением новой версии STUN, сервер TURN также поддерживает новый запрос STUN по RFC5389 .

Источник
Другие вопросы по тегам