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

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

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

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

15.12.2008 20:53:50
3 ОТВЕТА

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

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

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

3
15.12.2008 21:25:30

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

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

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

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

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

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

0
12.03.2012 06:38:37

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

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

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

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

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

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

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

3
17.09.2013 20:38:06