Full cone nat что это такое

Страничка VOIP Инженера

Это скромная попытка поделится с миром жизненным опытом

Типы Network Address Translation (NAT)

Рубрики Типы NAT в Янв.26, 2009

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

Cone NAT

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Любой пакет с внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210

Address-Restricted cone NAT или Restricted cone NAT.

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Пакет с любого порта внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210 только в случае, если 192.168.0.2:2210 предварительно посылал пакет на этот внешний хост.

Port-Restricted cone NAT

Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Внешний хост (1.1.1.30:1234) модет послать пакет на 192.168.0.2:2210 через 1.1.1.2:8801 только в случае если ранее 192.168.0.2:2210 слал пакет на 1.1.1.30:1234

Symmetric NAT

Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт. Соответственно, пакет с одного и того-же внутреннего адреса:порта, но посланный на другой внешний хост или порт после трансляции будет иметь другой внешний адрес-порт. Внешние хосты могут послать обратный пакет только на те хосты:порты откуда они получили пакеты.

Еще одна, часто встречающаяся особенность NAT, так называемый port preservation, такой гибрид Port-Restricted и Symmetric NAT, будет рассмотрен в другой статье.

17 Комментариев к “Типы Network Address Translation (NAT)”

1. illiginorb Написал:
   Февраль 3rd, 2009 | 15:58 Отличный пост, прочитав несколько статей на эту тему понял, что всё таки не посмотрел с другой стороны, а пост как-то очень заинтересовал.
2. river Написал:
   Февраль 26th, 2009 | 08:47 Спасибо, особенно за картинки
3. phantom Написал:
   Март 9th, 2009 | 22:48 Достаточно однобокий пост. Смысл-то в чем? Все равно 3-мя картинками для понимания принципов и проблем не обойтись.
   Да и картинок-то хватает в инете.
   Например, есть хорошие статейки:
   http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml
   http://www.cisco.com/web/about/ac123/ac147/ac174/ac182/about_cisco_ipj_archive_article09186a00800c83ec.html
4. aoz Написал:
   Март 10th, 2009 | 09:32 phantom,
   если бы у всех стояли циско роутеры с ios-овской реализацией connttrack,
   данная статья бы, не имела бы смысла для практических инженеров. А на предмет картинок. Так вот, вменяемых картинок с объяснением алгоритмов NAT на середину 2008 года в интернете не было.
5. phantom Написал:
   Март 10th, 2009 | 10:04 Немного непонятно, при чем все-таки тут конкретные реализации connttrack? Речь шла о базовых принципах работы. в статья же (к сожалению на буржуйском) рассмотрены эти механизмы, а также сопутствующие проблемы, знание которых и позволяет адекватно понимать «а что такое модули connttrack и для чего нужно их использовать». Или я не прав?
   Кстати в статьях есть интересные ссылки на доп ресурсы
6. aoz Написал:
   Март 10th, 2009 | 10:38 Мы вообще о разных вещах говорим. Дело в том, что под connttrack модулями имелись ввиду абсолютно безупречные connttrack модули для VOIP протоколов от циско. Встроенные в IOS и осуществляющие абсолютно корректную трансляцию не только заголовков пакетов, но и тела самого пакета. Если бы то же самое делали остальные производители, то данная статья имела бы чисто академический интерес,
   поскольку никаких настроек там нет. IOS достаточно умный, чтобы все исправить самостоятельно. А когда приходится разбираться с тем, почему после прохода NAT от производителя из Шанхайского подвала, происходит та или иная проблема с VOIP, без моих картинок ой как тоскливо.
7. Yur4 Написал:
   Июнь 2nd, 2009 | 20:31 Спасибо. полдня читаю про типы NAT уже крыша едет. еще б статью дополнить как протестить какой тип NAT в конкретном случае. Что типа вывода утилитки stun.
8. aoz Написал:
   Июнь 2nd, 2009 | 21:36 Если читаете как пользователь, для вас моя же статейка:
   http://aoz.com.ua/2009/02/06/sipovernat/
   то есть по простому:
   1.Обрубаете __все__ связанное с nat traversal,
   если интернет между вами и провайдером нормальный и провайдер правильный.
   2. Если интернет иногда уходит в полочку, надо позаботится о sipping с вашей стороны.
   3. Если провайдер не правильный идите к нормальному. Ну а если сами провайдер или админ сети тогда читайте, бог в помощь. А на предмет stun, забудьте как про страшный сон. Толку от нее, если симметричный nat без помощи провайдера не пробить.
9. maxi_funy Написал:
   Июнь 21st, 2009 | 21:15 Хорошая статья в картинках
   Кому надо — тот конечно и на цискоком посмотрит, но итак всё вроде понятно
10. chs Написал:
    Август 20th, 2009 | 16:11 Хороший пост, очень понятные и информативные рисунки, довольно доходчиво. Я только начал разбираться с типами NAT-ов и после прочтения поста мне все же не понятно чем Port-Restricted cone NAT отличается от Symmetric NAT. Рисунки иллюстрирующие эти два типа NAT-ов, если я не ошибаюсь, отличаются только красной надписью вверху
11. aoz Написал:
    Август 21st, 2009 | 08:38 chs, При симметричном NAT: Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт, В отличие от Port Restricted, где все SIP устройства из-за NAT видны с одним и тем же портом. Если уже по по цветам это синенкая рамочка снизу
12. Владимир Написал:
    Февраль 21st, 2010 | 07:56 Благодарю Вас за то, что не поленились поделиться добытыми знаниями!
13. ArmA Написал:
    Февраль 14th, 2012 | 14:31 Спасибо за внесённую ясность. Особенно за картинки — словами гораздо дольше и туманнее. А по картинке можно сразу рассмотреть варианты и разобрать, что к чему.
14. Владислав Написал:
    Март 16th, 2013 | 19:29 Спасибо большое!
15. Necro Написал:
    Июнь 1st, 2013 | 09:31 Роутер Асус, с кастомной прошивкой от Padavan,
    столкнулся с настройкой classical linux hybrid nat в выборе модели НАТ.
    Уважаемые, не подскажете — что из себя представляет данный вид модели?
16. aoz Написал:
    Июнь 1st, 2013 | 11:01 В iptables симметричный NAT с попыткой сохранить порт src клиента (если он свободен)
17. олег Написал:
    Ноябрь 12th, 2014 | 05:31 iptables ето открывание портов для атс а как с оконечниками с ихними дивайсами за натом со своими фаерволами и случей когда нужные порты уже чемто заняты ето целая наука затрагующая всю цепочку начиная с провадера интернета и заканчуя телефонным апаратом и единого решения нет разные дивайсы раздают интернет какие поддерживают одни функции какие другие про dsl -модемы ничего не сказано а ето часто реально прблема со своими фаерволами и качеством про keep-Alive не увидел так что только тиория хотя грамотно,считаю что только в практике абон обслуживания и подключения начинаеш пониать чтотакое нат и как можно его обойти а если нат двойной и пару свичей в сетке да еще и какойто хаб полностью забитый абонами рвет пакеты при передаче что факс уже не отправиш а как правило что ето хаб какойто тупое устройство все портачит подумаеш в последнюю очередь у того торент качает тот в скайпе сидит у того вирусняк какойто у того комп гадит в сетку чемто и в таких условиях абон требует чтобы факсы бегали и качество связи было идеальным потомучто ему обеснили поопулярно что ето цыфра и качество будет клас ни еха тибе ни ободраных фраз атличный дуплекс оба слышат друг друга так что нат пройти бывает надо постараца даище и в обе стороны поетому становишся сетевым спецом широкого профиля чтобы абона подключить зайдеш на роутер порты нужные пробросить а там прошивка 8-летней давности так что и обновить приходится короче по возится а он если че ему говориш нада роутер по соврименей купить а он мне раньше все работало а вы полезли и поломали мне там чета короче весило а мне начальство пришол включил и ушол любой справится наверно чтобы зарплату не подымать за обем который не обсуждался при устройстве на роботу раз 50 ситуации разные происходят начинаеш сразу оприделять что может быть нат фаервол или ище чета так что нат бывает так потра-шся а кажется зашол включил и ушол а включаеш а а порты открыть не выходит ну тоесть ты все сделал как надо везде галочки стоят где надо порты открыты а всерамно однастороняя связь услуга куплиная не полноценная и все проблема типа пришлите мне спеца по компитентней тебя нет два года наты проходиш так что подключив ну там шлюз например напрямую в роутер изернетавский и ето единственое что на роутере висит успешно прходиш нат стандартно и пишиш красивую научно популярную статью как ето делается а на прктике та не так совсем а вариант поиграйся там тем тем ну типа по порамитрам погуляйпоминяй попробуй так тотом так занимает много времени и производит впечетление что чиловек не знае что он делает особенно с приложениями на айфон или андройд я раз так попал с айпадом что только не пробывал голос не ходит и все а оказался нат а ета настройка фиг знает где оказалась в сетевых настройках тольконастройка в настройкеслучайно практически на нее попал тоже с натом связанная я оп поменял моментально все заработало звук голос посли етого зойпер стал моим любимым приложением а все потому что в нем шире придставлины настройки нат есть че выбрать а в сипсемпле например воще ети настройки отсутствуют и ету проблему победить не возможно не чем ну раз нет етих настроек значит и ненадо думаеш а они надо потомушто голс не ходит и регистрацие отваливается периодически не дороботаное приложение простинькое хотя много где работает и в 3Сх нет зойпер самое полное ну конечно можно сехать у вас кодека 729 нет ево надо докупать мы мол придуприждали вася абон плату платит а поговорить не может а ето походу НАТ всего навсиго порты режит кроет верно настроеный нат снимае ети вопросы но он сеть поминяет там может другой вариант работает надо заходить менять если есть на что минять а если нет чувак кодек купил а прблемы ето не решило начинается ваша связь ху—ня верните деньги а ето нат порты вот и все и галимое приложение так что нат для voip имеет решающее значение часто так что на ету тему надо писать обсуждать варианты настроек обговаривать много головных болей пройдет и качество и надежность ай-пи телефонии подымит ну как-то так извените за то что наваял тут дофига просто нужная тема и у меня тоже есть по поводу нат мнение спосибо досвиданье кстати ма с вами знакомы лично так что я знаю чтовы сделали построли целого воип оператора

Оставить Ответ

Работа

• IP телефония или VOIP. Проблемы и решения.
  • NAT traversal
    • NAT traversal в сети правильного провайдера.
    • Open SBC
    • Типы NAT

    Техподдержка 3CX отвечает: настройка маршрутизатора для VoIP-сервера АТС

    Если вы планируете подключить к системе 3CX SIP-транки от операторов связи или удаленных пользователей, и ваша АТС расположена в частной сети — на сетевом экране должна быть выполнена статическая публикация («проброс») портов.

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

    Проблема VoIP с симметричным NAT (Symmetric NAT)

    

    При использовании симметричного NAT, пограничное сетевое устройство динамически изменяет номер порта, на который принимается аудиопоток. Например, при исходящем вызове через SIP-транк оператора, 3CX сперва делает STUN-запрос для определения своего внешнего IP-адреса и текущего номера порта. Затем этот адрес и порт передаются SIP-серверу оператора для взаимных коммуникаций. Но в это время ваш сетевой экран динамически закрывает этот порт (который уже был передан оператору — указан в заголовке INVITE). Возникает сбой передачи аудио. Очевидно, что из-за этой особенности невозможно обеспечить надежную работу VoIP. В руководствах по настройке сетевых экранов такая технология называется симметричный NAT (Symmetric NAT).

    Решение проблемы с односторонней слышимостью в VoIP — Full Cone NAT

    

    Для решения проблемы с односторонней слышимостью (или полной «тишиной») следует настроить так называемый конический NAT (Full Cone NAT), который также известен как NAT «один-в-один». В нем нужные порты на внешнем адресе маршрутизатора маппируются (или «пробрасываются») на определенный внутренний адрес (номер порта сохраняется). Внешний хост обменивается RTP-пакетами с внутренним хостом, отправляя их сперва на внешний адрес маршрутизатора и внешний (маппированный) порт.

    На самом деле, подавляющее большинство сетевых устройств поддерживают этот режим. Как правило, он называется «Static port mapping». Статическая публикация гарантирует, что определенный порт всегда остается открытым и никогда не изменяется сетевым экраном. Некоторые очень дешёвые маршрутизаторы некорректно реализуют эту функцию, но большинство, как было сказано, позволяют нормально настроить «проброс» портов. В конце статьи приводятся примеры соответствующей настройки различных сетевых устройств.

    Проверка корректности работы сетевого экрана сервисом 3CX Firewall Checker

    Хороший способ проверки конфигурации сетевого устройства (выяснения, не находитесь ли вы за Symmetric NAT и других проблем с настройкой) — использование сервиса 3CX Firewall Checker.

    3CX Firewall Checker позволяет заранее проверить, что ваше пограничное сетевое устройство корректно обрабатывает VoIP-трафик от SIP-операторов, мостов 3CX, внешних SIP-клиентов и подключений по технологии 3CX Tunnel. Рассмотрим на простом примере, как использовать этот сервис. Для примера примем, что сервер 3CX имеет адрес 192.168.0.100, тестирование проводится на порту 9500, а внешний адрес вашей сети 11.22.33.44.

    Как было сказано, корректная публикация порта означает, что любой исходящий пакет UDP от сервера АТС с адресом источника source IP::Port — 192.168.0.100::9500 должен дойти до получателя (обычно это SIP-сервер оператора связи, удаленный IP-телефон или другая АТС 3CX) с «переписанным» адресом источника source IP::Port — 11.22.33.44::9500. Несмотря на то, что происходит трансляция адреса (которая необходима для маршрутизации пакета в публичной сети WAN), порт пакета не изменяется. Кроме того, любой UDP пакет, приходящий из WAN, с адресом получателя destination IP::Port — 11.22.33.44::9500 должен достигнуть сервер 3CX с адресом destination IP::Port — 192.168.0.100::9500. 3CX Firewall Checker как раз и используется для проверки корректного преобразования адресов, а также выясняет другую важную.

    Для запуска 3CX Firewall Checker зайдите в интерфейс управления 3CX > раздел Главная > секция Состояние АТС > нажмите Сетевой экран > Запустить.

    

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

    Внимание: Запуск 3CX Firewall Checker останавливает некоторые сервисы 3CX, поэтому в период тестов АТС будет недоступна. Если тестирование порта прошло успешно, оно занимает 1 сек. Неуспешное тестирование порта растягивается на 5-10 сек. По умолчанию, тестируются порты в диапазоне 9000 – 10999. Если изначально все настроено корректно, тестирование займет не более минуты. Если возникнут проблемы — тестирование затягивается на 4-9 мин. Однако в любой момент можно остановить тест.

    Сервис использует STUN-сервер компании 3CX, который должен быть установлен в разделе Параметры > Сеть > Публичный IP. Некоторые сетевые экраны эту проверку могут ошибочно квалифицировать как сканирование портов. Если это происходит, 3CX Firewall Checker сообщает о проблеме в самом начале тестирования. Поэтому в сетевом экране следует отключить проверку на сканирование перед началом тестирования.

    Тесты 3CX Firewall Checker

    Утилита проверяет корректность настройки оборудования, делая различные запросы к STUN-серверам. Проводятся два теста.

    Доступность Интернет

    Этот тест проверяет доступность серверов STUN с проверяемых портов сервера 3CX. Также проверяется работа DNS (STUN-серверы в 3CX указаны по FQDN).

    Если этот тест не пройден, возможны следующие проблемы:

    • Общая проблема доступа в Интернет. Если на сервере установлен браузер, попробуйте просто зайти на какой-то сайт. Возможно, вам нужно открыть доступ с сервера АТС в интернет по портам, указанных в этом руководстве.
    • Тест может не пройти, если STUN-сервер недоступен. Проверьте настройки в разделе Параметры > Сеть > Публичный IP или используйте резервный сервер.
    • Проверьте, какой порт указан для STUN (по умолчанию 3478)
    • Убедитесь, что сетевой экран на самом сервере 3CX, например брандмауэр Windows, разрешает подключение на тестируемые порты. Антивирусы или другие программы безопасности также могут блокировать порты. Отключите или даже полностью удалите их с сервера на время тестирования (простое отключение не всегда помогает).
    • Блокировать порты могут также на стороне вашего интернет-оператора — стоит исключить эту возможность.

    Корректность публикации портов (Full Cone NAT)

    Этот тест проверяет способность сервера, находящегося в Интернет, коммуницировать с сервером 3CX во внутренней сети. Тестируется настройка трансляции портов «один в один» (Full Cone NAT).

    3CX Firewall Checker отправляет запрос на STUN-сервер с (номера) порта, который проверяется, и запрашивает STUN-сервер создать соединение с сервером АТС по этому порту с внешнего IP-адреса. Если второй тест не прошел, проверьте следующие настройки:

    • Ваш сетевой экран должен иметь статическое правило публикации портов «один в один». Недорогие устройства, как правило, предлагают только такой тип правил.
    • Для некоторых портов требуется правило как для TCP, так и для UDP трафика. См. список портов, необходимых для работы 3CX.

    Результаты теста / сообщения об ошибках

    Перечислим результаты теста и ошибки, которые возвращает Firewall Checker.

    Success – Port forwarding is correctly implemented for this port. VoIP can work. This configuration is supported (Успех — публикация порта выполнена корректно. VoIP-коммуникации будут работать. Данная конфигурация поддерживается 3CX).

    Все тесты успешно пройдены. Ваше пограничное устройство разрешает трафик в интернет с тестируемого порта и корректно выполняет преобразование портов один в один. Конфигурация поддерживается.

    STUN server has no second address (STUN-сервер не имеет второго адреса).

    Сообщение появляется, если в интерфейсе 3CX некорректно настроен STUN-сервер. STUN-сервер должен иметь два адреса. В разделе Параметры > Сеть > Публичный IP укажите следующие STUN-серверы: stun-eu.3cx.com, stun2.3cx.com, stun3.3cx.com.

    Failed – No response received or port mapping is closed. Port forwarding not configured correctly (Неуспешно — ответ не получен или порт закрыт. Некорректная настройка публикации порта).

    Некорректно настроена публикация проверяемого порта. В этом случае VoIP-операторы и удаленные IP-телефоны не будут работать. Настройте публикацию портов по этим руководствам.

    Failed – Firewall check failed. Some errors were detected. Please check your firewall configuration and try the test again (Неуспешно — проверка сетевого экрана не удалась. Обнаружены ошибки. Проверьте конфигурацию сетевого экрана и попробуйте снова).

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

    Failed – Malformed response received – (aka Symmetric NAT). Port forwarding not correctly implemented (Неуспешно — получен некорректный ответ (возможно, симметричный NAT). Некорректно настроена публикация портов).

    Ответ говорит о том, что у вас некорректно работает Full Cone NAT.

    STUN server did not answer or port forwarding is not configured on your firewall (STUN-сервер не ответил или не настроена публикация портов на сетевом экране).

    Ваш STUN-сервер не отвечает. Возможные причины:

    • STUN-сервер недоступен с сервера 3CX.
    • STUN-сервер в данный момент отключен.
    • Не настроена публикация портов.

    Не удалось определить IP-адрес STUN-сервера по его имени. Это может говорить о проблемах с вашим DNS-сервером, но также и о том, что данный STUN-сервер навсегда прекратил работу.

    Failed – Malformed or no response received from configured STUN servers. Check your internet connection, DNS settings, or change STUN servers from Settings → Network → External IP Configuration section (Неуспешно — получен некорректный ответ от настроенных STUN-серверов. Проверьте подключение к Интернет, настройки DNS или используйте другой STUN в разделе Параметры → Сеть → Внешний IP).

    Ответ говорит, что публикация портов выполнена корректно или ваш сетевой экран блокирует пакеты.

    Failed – Port is in use by another application on this computer ИЛИ SIP port is in use by process . The 3CX Firewall checker requires the SIP port to be free (Неуспешно — порт используется другим приложением на этом сервере ИЛИ SIP-порт используется процессом . Сервису 3CX Firewall checker необходим свободный порт SIP.

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

    netstat -ano | findstr /I /C:»PID» /C:»:9500″

    где 9500 — номер порта. В колонке PID вы увидите ID процесса. Используете Диспетчер задач для идентификации процесса. Также можно выполнить команду

    tasklist /fi «pid eq 4»

    где 4 — ID процесса.

    STUN servers are not reachable. Cannot perform Firewall check. This configuration is not supported (STUN-серверы недоступны. Невозможно выполнить проверку сетевого экрана. Конфигурация не поддерживается).

    Недоступны STUN-серверы, настроенные в интерфейсе 3CX. Как правило, это связано с проблемами с доступом в Интернет. В разделе Параметры > Сеть > Публичный IP укажите следующие STUN-серверы: stun-eu.3cx.com, stun2.3cx.com, stun3.3cx.com.

    Дополнительная информация

    • 3cx
    • stun
    • firewall checker
    • full cone nat
    • symmetric nat
    • проблемы
    • односторонняя слышимость
    • маршрутизатор
    • сетевой экран
    • публикация портов

    Реализация Full Cone NAT

    Для тех кто не в курсе, -j SNAT это Source NAT и к Full Cone NAT отношения не имеет.

    

    Nuclerdragon
    22.02.16 19:16:42 MSK

    

    Для тех кто не в курсе, -j SNAT это Source NAT и к Full Cone NAT отношения не имеет.

    Лол, ну ищи патч тогда, да. Коллега.

    Jameson ★★★★★
    ( 22.02.16 19:20:59 MSK )

    Шта? Тебе DNAT, может?

    A full cone NAT (also known as a one to one NAT) is the only type of NAT where the port is permanently open and allows inbound connections from any external host. A full cone NAT maps a public IP address and port to a LAN IP and port. Any external host can send data to the LAN IP through the mapped NAT IP and port.

    blind_oracle ★★★★★
    ( 22.02.16 19:23:41 MSK )
    Ответ на: комментарий от blind_oracle 22.02.16 19:23:41 MSK

    

    Ему на самом деле нужны оба, но он не понимает как работает iptables и полон ЧСВ.

    Так что пусть погуглит сам, блок схему прохождения пакетов через iptables найдет и распечатает например.

    Jameson ★★★★★
    ( 22.02.16 19:28:04 MSK )

    

    iptables -t nat -A POSTROUTING -o extIF -j SNAT --to-source ext.ip iptables -t nat -A PREROUTING -i extIF -j DNAT --to-destination local.ip 

    или для целой сети:

    iptables -t nat -A POSTROUTING -o extIF -j NETMAP --to ext.net/mask iptables -t nat -A PREROUTING -i extIF -j NETMAP --to local.net/mask 

    CFA ★
    ( 22.02.16 19:57:53 MSK )

    

    патч нужен, установка командой man.

    upcFrost ★★★★★
    ( 22.02.16 22:11:59 MSK )
    Ответ на: комментарий от CFA 22.02.16 19:57:53 MSK

    

    iptables -t nat -A PREROUTING -i extIF -j DNAT —to-destination local.ip

    В терминологии обычного (например настольного маршрутизатора) это называется DMZ, и отношения к Full Cone NAT это не имеет.

    Вот это уже теплее но немного не то.

    Nuclerdragon
    ( 23.02.16 08:36:06 MSK ) автор топика
    Ответ на: комментарий от Nuclerdragon 23.02.16 08:36:06 MSK

    

    В терминологии нормальных людей ты называешься дебилом, и к специалистам отношения не имеешь. Тебе уже объяснили про dnat и snat, но ты похоже понять не способен что тебе говорят

    no-dashi ★★★★★
    ( 23.02.16 08:43:14 MSK )
    Ответ на: комментарий от CFA 22.02.16 19:57:53 MSK

    

    iptables -t nat -A PREROUTING -i extIF -j DNAT --to-destination local.ip

    хорошо, это частный случай full cone nat, для одного IP, нужно для любых, именно для любых а не для заданной сети, сетей может быть много и добавляются они динамически.

    Вот пример правила full cone nat, которое работает на маршрутизаторе на чипсете brodcom (сборка iptables от Broadcom):

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE --mode fullcone

    стандартный iptables не понимает опции —mode
    Nuclerdragon
    ( 23.02.16 12:38:05 MSK ) автор топика

    Даже интересно стало. Найдете решение, напишите.

    anc ★★★★★
    ( 23.02.16 20:41:58 MSK )

    Это теперь через tc делается, если нужен one-to-one NAT. что-то типа:

    # input packets tc qdisc add dev eth1 ingress handle ffff: tc filter add dev eth1 parent ffff: handle . protocol ip prio 10 u32 . match ip dst 1.1.1.1/32 action nat ingress 1.1.1.1/32 10.0.0.1 # output packets tc qdisc add dev eth1 root handle 1:0 htb default 1 r2q 1 tc filter add dev eth1 parent 1: handle . protocol ip prio 10 u32 . match ip src 10.0.0.1/32 action nat egress 10.0.0.1/32 1.1.1.1 

    Мутновато, конечно, как и всё связанное с tc, но работает отлично. Можно ещё NOTRACK заюзать, чтобы conntrack не забивался говнами.

    Stanson ★★★★★
    ( 23.02.16 21:37:30 MSK )
    Ответ на: комментарий от Nuclerdragon 23.02.16 12:38:05 MSK

    

    нужно для любых, именно для любых а не для заданной сети, сетей может быть много и добавляются они динамически.

    Именно так iptables не умеет. Я был подключен к провайдеру, у которого была похожая схема — клиенту выдавался частный адрес, но каждый клиент натился на уникальный «белый» адрес, который мог меняться, если от клиента долгое время не было трафика. И это был не просто NAT, а тот самый Full Cone NAT. И это было какое то жутко энтерпрайзное за много-много денег.

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE --mode fullcone

    MASQUERADE просто прозволяет не указывать —to-source, адрес подхватиться с интерфейса сам, и будет корректно работать если адрес меняется. Как работает —mode fullcone не понятно, если за роутером несколько клиентов, а «source» адрес только один? А Full Cone NAT подразумевает, что для каждого адреса за NAT, был свой собственный «внешний» адрес. У тебя в наличии больше одного «белого» IP? Или натятся вообще частные адреса?

    CFA ★
    ( 23.02.16 21:44:09 MSK )
    Ответ на: комментарий от CFA 23.02.16 21:44:09 MSK

    А Full Cone NAT подразумевает, что для каждого адреса за NAT, был свой собственный «внешний» адрес.

    Я так понял, что Full Cone отличается от обычного, симметричного ната тем, что будет принимать обратные пакеты с любого хоста, а не только с того, на который был запрос. Т.о. для каждого клиента не обязателен свой адрес.

    Не могу пробить NAT, UDP создает канал

    Добрый день!
    Проблема частая, но я попытаюсь все описать подробно-подробно. К тому же маюсь я с ней уже несколько месяцев.
    Есть сервер с белым IP, и есть клиент за NAT-ом и роутером. Клиент и сервер создают сокеты на UDP, клиент отправляет пакет на сервер, сервер его успешно получает, вычисляет его обратный адрес и порт, отправляет на него ответ. Все прекрасно работает, пакеты летают, обмен идет.
    Проблема возникла, когда я решил подключить второго клиента к первому, т.е. чтобы второй клиент мог отправить пакеты первому.
    На сокет первого клиента (который за NAT-ом) доходят пакеты ТОЛЬКО с сокета сервера, на который этот первый клиент первоначально сбрасывал пакет.

    Т.е. ситуация полностью выглядит так:
    1. На сервере с белым IP создаю 2 сокета UDP, которые слушают разные порты, например 35000 и 36000

    Socket udp35000, udp36000; ***** udp35000 = new Socket( AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); IPEndPoint ClientEP1 = new IPEndPoint( IPAddress.Any, 35000); udp35000.Bind( ClientEP1); udp36000 = new Socket( AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); IPEndPoint ClientEP2 = new IPEndPoint( IPAddress.Any, 36000); udp36000.Bind( ClientEP2);

    2. На клиенте создаю 1 сокет UDP, отправляю пакет на первый сокет сервера.

    Socket udp_; ***** udp_ = new Socket( AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); IPEndPoint localIP = new IPEndPoint( IPAddress.Any, 27015); udp_.Bind( localIP); string message = "ready_message"; byte[] _data = Encoding.ASCII.GetBytes( message); EndPoint remotePoint = new IPEndPoint( IPAddress.Parse( "тут адрес сервера"), 35000); udp_.SendTo( _data, remotePoint);

    3. Сервер получает пакет, вычисляет его обратный адрес и отправляет ответ:

    byte[] data = new byte[256]; int bytes = 0; //узнаем адрес, с которого пришли данные EndPoint remoteIp = new IPEndPoint( IPAddress.Any, 0); while ( udp35000.Available > 0) < bytes = udp35000.ReceiveFrom( data, ref remoteIp); // получаем данные о подключении IPEndPoint remoteFullIp = remoteIp as IPEndPoint; //отправляем ответку string message = "it's ok"; byte[] _data = Encoding.ASCII.GetBytes( message); EndPoint remotePoint = new IPEndPoint( remoteFullIp.Address, remoteFullIp.Port); udp35000.SendTo( _data, remotePoint); >

    4. Сообщения с этого сокета ДОХОДЯТ.
    5. Пытаюсь отправить со второго сокета сервера сообщения на этот адрес — они не приходят.

    udp36000.SendTo( _data, remotePoint); udp36000.SendTo( _data, remotePoint); udp36000.SendTo( _data, remotePoint);

    — пакеты отправляются, но не доходят.

    Как преодолеть этот NAT и почему пакеты не доходят, хоть я и шлю их на внешний адрес и порт клиента. И что вообще делать?

    Как это работает: когда вы шлете что-то из-за NATа по UDP, вам выделяется на время внешний порт на роутере, который связывается с внутренним портом на вашем компе. На этот порт вам могут слать все что угодно. Связка портов держится некоторое время после того, как ей последний раз воспользовались. В зависимости от настроек роутера, от 20 минут, до 4х часов.
    Однако, можно так настроить роутер, чтобы он запоминал, куда была первая передача, и принимал встречные посылки только из этого адреса. По умолчанию они обычно настроены так, чтобы принимать из любых адресов.

    Т.е. доходить должно.
    П.С.2
    На клиенте я заранее забиндил неслучайный порт для сокета (27015), если этого не сделать — система выделит свободный:

    IPEndPoint localIP = new IPEndPoint( IPAddress.Any, 27015); udp_.Bind( localIP);

    Так вот, если так делать, то на сервере функция ReceiveFrom(data, ref remoteIp) определяет, что обратный порт, с которого пришел пакет — 27015. И так при каждом запуске. Закрадываются мысли, что это не внешний порт, но ведь пакеты с сокета udp35000 как-то доходят до клиента, даже с этим портом.
    П.С.3 На другом форуме сказали, что NAT запоминает куда я отправил и получает ответ только оттуда. И как тогда половина сетевых программ функционирует? Или все 100% пересылают через выделенные сервера?

    Рад любому пояснению или примерам, лучше на C#, но сгодится любой язык.

    #1
    18:46, 3 дек 2017

    Сначала узел А пошлет пакет с порта 200 посреднической службе с IP-адресом
    4.6.5.10 (узел П), сообщая, что хотел бы зарегистрироваться в роли сервера. Когда
    пакет попадет на маршрутизатор NAT А, он создаст запись в своей таблице NAT
    и изменит пакет, заменив адрес отправителя своим глобальным IP-адресом, а порт
    отправителя — случайным числом, в нашем примере 60000 . Затем маршрутизатор
    NAT А отправит пакет узлу П. Узел П примет пакет и узнает, что игрок А, играю-
    щий на узле А с адресом 18.19.20.21:60000 , желает зарегистрироваться как сервер
    многопользовательской игры.
    Затем узел Б пошлет узлу П пакет, сообщающий, что игрок Б хотел бы подклю-
    читься к игре игрока А. Когда пакет попадет на маршрутизатор NAT Б, тот создаст
    запись в своей таблице NAT и изменит пакет, подобно тому как это сделал марш-
    рутизатор А. Затем измененный пакет будет отправлен узлу П, который узнает
    из пакета, что узел Б с адресом 12.12.6.5:62000 хотел бы соединиться с узлом А.
    В этот момент узел П уже знает глобальный адрес маршрутизатора NAT А, а также
    порт получателя, через который маршрутизатор NAT А перешлет пакет узлу A.
    Узел П мог бы послать эту информацию узлу Б в пакете ответа и потребовать,
    чтобы узел Б попытался использовать ее для соединения. Но не забывайте, что
    некоторые маршрутизаторы проверяют происхождение входящих пакетов, чтобы
    гарантировать, что эти пакеты ожидаются с указанного адреса. Маршрутизатор
    NAT А пока ожидает получить только пакеты от узла П. Если узел Б сейчас по-
    пытается подключиться к узлу А, маршрутизатор NAT А заблокирует пакет, потому
    что он не ожидает получить ответ от узла Б.
    К счастью, узел П также знает глобальный IP-адрес маршрутизатора NAT Б и но-
    мер порта, через который можно отправить пакет узлу Б. Поэтому он посылает
    данную информацию узлу А. Маршрутизатор NAT А пропускает эту информацию,
    потому что в его таблице NAT есть запись, сообщающая, что узел А ждет ответа от
    узла П. Затем узел А посылает пакет узлу Б, используя информацию, полученную
    от узла П. Может показаться странным, что сервер пытается соединиться с клиен-
    том, тогда как обычно все делается наоборот. Еще более странной данная ситуация
    будет выглядеть, если вспомнить, что маршрутизатор NAT Б не ожидает получить
    пакет от узла А и потому просто не пропустит его. Зачем тогда напрасно посылать
    пакет? Таким способом узел А вынуждает маршрутизатор NAT А создать запись
    в своей таблице NAT!
    Пакет, отправленный узлом А узлу Б, попадет в маршрутизатор NAT А. Маршрути-
    затор обнаружит, что адрес узла А 192.168.1.2:200 уже есть в таблице с внешним
    портом 60000 , поэтому он выберет этот порт для исходящего пакета. Затем создаст
    еще одну запись в таблице, указывающую, что с адреса 192.168.1.2:200 отправлен
    пакет на адрес 12.12.6.5:62000 . Эта дополнительная запись является ключевой.
    Пакет почти наверняка никогда не достигнет узла Б, но после его отправки узел П
    сможет послать ответ узлу Б, сообщая, что тот может подключиться непосред-
    ственно к узлу А по адресу 18.19.20.21:60000 . Узел Б так и поступит, и когда пакет
    достигнет маршрутизатора NAT А, тот увидит, что это действительно ожидаемый
    входящий пакет с адреса 12.12.6.5:62000 . Он изменит пакет, подставив адрес полу-
    чателя 192.168.1.2:200 , и отправит его узлу А. С этого момента узлы А и Б смогут
    взаимодействовать непосредственно друг с другом, используя глобальные IP-
    адреса и номера портов, которыми они обменялись.

    #2
    19:32, 3 дек 2017

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

    #3
    20:18, 3 дек 2017

    Самый простой вариант — заиспользовать UPnP на стороне клиента за NAT’ом. Поищи либу для этого. Когда клиент пробросит порт, нужно будет этот порт переслать через сервер другому клиенту и тот сможет открыть соединение.

    #4
    20:21, 3 дек 2017

    Zab
    Нет-нет, на клиенте только 1 сокет и порт, мне не нужно больше. Я успешно соединяюсь с одним сокетом сервера, и тот нормально принимает-отправляет пакеты от клиента. Другие, даже другой сокет сервера не может пробиться к клиенту.

    Или тут о каких-то других портах речь?

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

    Когда
    пакет попадет на маршрутизатор NAT А, он создаст запись в своей таблице NAT
    и изменит пакет, заменив адрес отправителя своим глобальным IP-адресом, а порт

    И вот как узнать, я же получаю неизмененный пакет, похоже, хоть и IP внешний.
    В общем, я на функцию RecieveFrom грешу.

    #5
    21:05, 3 дек 2017

    PANDA
    Сейчас, похоже, у меня одна проблема — узнать внешний порт, с этим и стандартные средства должны справиться. Да и внешний сервер есть. А что за либы и зачем, если UPnP стандартные сокеты С# держат, вроде.

    #6
    22:26, 3 дек 2017

    Ramm
    > Сейчас, похоже, у меня одна проблема — узнать внешний порт
    Это во многих случаях тебе никак не поможет. Короче, читай UPnP и поймешь, что и зачем. Если у тебя нет полного понимания, как работает NAT и какие бывают нюансы на разных роутерах, то пытаться самому пробивать его — глупая затея.

    #7
    8:47, 4 дек 2017

    PANDA
    > Если у тебя нет полного понимания, как работает NAT и какие бывают нюансы на
    > разных роутерах, то пытаться самому пробивать его — глупая затея.
    Да вроде не все так сложно. Роутер тоже должен уметь делать свой NAT. Например, к роутеру подключены 5 устройств и все дружно лезут в браузер по 80-му порту, роутер не может обслуживать их всех, поэтому выделяет для каждого пользователя свой порт (из числа свободных) и посылает трафик дальше. Запоминая какой порт и для кого он выделил. На выходе NAT провайдера, и там та же самая ситуация, выделяет свободные порты, запоминает что и для кого выделил, и посылает пакеты дальше. Сервер получает пакеты от самого последненго адреса и порта и шлет ответы на них. NAT ответные пакеты он пересылает обратно на нужные порты, а те переходят по иерархии еще ниже.

    Если роутер не умеет так делать, то это вообще не моя проблема и UPnP не поможет. Куча тем в инете, где люди не могут поиграть в нормальные игры вместе с «модель роутера что делать». У меня почти все получается, только какая-то фигня с определением внешнего порта. Все должно работать и со стандартными сокетами.
    PANDA
    > Короче, читай UPnP и поймешь, что и зачем.
    Кроме сторонних библиотек по запросу «C# upnp» и вопросов о том, как их использовать, а так же граблей и костылей, я ничего толкового не нашел.

    #8
    9:57, 4 дек 2017

    Ramm
    > все дружно лезут в браузер по 80-му порту, роутер не может обслуживать их всех
    Это сервер сидит на 80 порту. А клиенты подключаются с любого, который пожелает браузер. Почитай про UDP hole punching и TCP hole punching. Особенно в каких условиях оно может работать, а в каких нет. Может дойдет наконец. В том треде, в котором ты отписался ответ на вопрос был. Но зачем читать, если можно не читать? Намекну. Симметричный нат, фулл кон, рестриктед кон, порт-рестриктед кон.

    Еще статья про UPnP. Она к твоему вопросу вообще никаким боком не относится. Как и вообще UPnP. Но для общего развития сойдет.
    https://habrahabr.ru/post/279969/

    #9
    10:32, 4 дек 2017

    Dampire
    > Это сервер сидит на 80 порту. А клиенты подключаются с любого, который пожелает
    > браузер.
    Я для примера, но перед этим загуглил, какой обычно порт использует та же Мозила.
    Dampire
    > Но зачем читать, если можно не читать?
    Обижаете, начальник))) Все прочитал. И для «пробивания» NAT я использую свой сервер с белым адресом, по рекомендации Zab

    Zab
    STUN пробивает нат для клиента. Ему покласть на остальных. Он не регистрирует заявки, он ничего не фиксирует. Он всего-лишь пробивает порт и сообщает реальный адрес тому-же серверу, с которого пришел запрос на пробитие, после чего благополучно все забывает. Я че-то протупил этот момент.
    St1G
    Забей на всю эту ерунду и сделай свой мастер сервер, который будет запоминать пробитые порты для адреса, а затем либо реинвайты кидать, либо гонять траффик через себя. Либо унификация портов, которые кстати могут быть заняты какой-нибудь другой дрянью. Все остальные варианты будут работать без гарантий.

    Похоже я себе не очень хорошо представлял что такое stun-сервер. Он действительно не коллекционирует адреса, и не сообщает их никому, помимо инициировавшего соединение. Но тогда нафиг он нужен? А он и не нужен, и не используется почти нигде.

    Требуется средство сообщить одному клиенту адрес и порт другого. И это средство — не stun-сервер. Пробить NAT конечно надо, но это можно сделать отослав сообщение на любой внешний IP, не нужно специальное средство для таких целей. Через что сообщаем свой адрес — через то и пробьем.

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

    Или без стороннего STUN никак не обойтись?

    Может дойдет наконец.

    Блиииин. А что я не так-то делаю.

    #10
    10:40, 4 дек 2017

    Я не просто так выделил разные типы натов. И в цитате от Zab есть пометка про Full Cone. И я не просто так отметил про Resticted и Port-Restricted Cone. Может стоит все же почитать что это такое? Как только узнаешь что это, то я тебе подскажу как с этим бороться, если сам не дойдешь в процессе.

    #11
    11:17, 4 дек 2017

    Dampire
    Спасибо огромное, что ткнули носом, но сейчас я буду отнимать чье-то время.
    Вики говорит:

    Симметричный NAT (Symmetric NAT) — Трансляция, при которой каждое соединение, инициируемое парой «внутренний адрес: внутренний порт» преобразуется в свободную уникальную случайно выбранную пару «публичный адрес: публичный порт». При этом инициация соединения из публичной сети невозможна.

    Cone NAT, Full Cone NAT — Однозначная (взаимная) трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любой внешний хост может инициировать соединение с внутренним хостом (если это разрешено в правилах межсетевого экрана).

    Address-Restricted cone NAT, Restricted cone NAT — Постоянная трансляция между парой «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любое соединение, инициированное с внутреннего адреса, позволяет в дальнейшем получать ему пакеты с любого порта того публичного хоста, к которому он отправлял пакет(ы) ранее.

    Port-Restricted cone NAT — Трансляция между парой «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт», при которой входящие пакеты проходят на внутренний хост только с одного порта публичного хоста — того, на который внутренний хост уже посылал пакет.

    Symmetric NAT. До недавнего времени это была наиболее распространённая реализация. Его характерная особенность – в таблице NAT маппинг адреса IL на адрес IG жёстко привязан к адресу OG, то есть к адресу назначения, который был указан в исходящем пакете, инициировавшем этот маппинг. При указанной реализации NAT в нашем примере хост 192.168.0.141 получит оттранслированные входящие UDP-пакеты только от хоста 1.2.3.4 и строго с портом источника 53 и портом назначения 1053 – ни от кого более. Пакеты от других хостов, даже если указанные в пакете адрес назначения и порт назначения присутствуют в таблице NAT, будут уничтожаться маршрутизатором. Это наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети, но в некоторых случаях сильно усложняющая жизнь системных администраторов. Да и пользователей тоже.

    Full Cone NAT. Эта реализация NAT – полная противоположность предыдущей. При Full Cone NAT входящие пакеты от любого внешнего хоста будут оттранслированы и переправлены соответствующему хосту в локальной сети, если в таблице NAT присутствует соответствующая запись. Более того, номер порта источника в этом случае тоже не имеет значения – он может быть и 53, и 54, и вообще каким угодно. Например, если некое приложение, запущенное на компьютере в локальной сети, инициировало получение пакетов UDP от внешнего хоста 1.2.3.4 на локальный порт 4444, то пакеты UDP для этого приложения смогут слать также и 1.2.3.5, и 1.2.3.6, и вообще все до тех пор, пока запись в таблице NAT не будет по какой-либо причине удалена. Ещё раз: в этой реализации NAT во входящих пакетах проверяется только транспортный протокол, адрес назначения и порт назначения, адрес и порт источника значения не имеют.

    Address Restricted Cone NAT (он же Restricted NAT). Эта реализация занимает промежуточное положение между Symmetric и Full Cone реализациями NAT – маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае 1.2.3.4), но номер порта источника при этом может быть любым.

    Port Restricted Cone NAT (или Port Restricted NAT). То же, что и Address Restricted Cone NAT, но в этом случае маршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.

    Предположим, мой внутренний адрес 192.168.0.1, внешний адрес 46.46.128.128.
    Если у меня Symmetric NAT, я создаю сокет с портом 27015, отправляю его на IP X с портом 35000, NAT не изменит порт, сервер получит пакет, определит его как от 46.46.128.128:27015, и ТОЛЬКО ОН МОЖЕТ ОТПРАВИТЬ ОТВЕТ. БЕССМЫСЛЕННО ПЕРЕДАВАТЬ 46.46.128.128:27015, Т.К. ДОСТУЧАТЬСЯ ДО НЕГО СМОЖЕТ ТОЛЬКО Х:35000, ОСТАЛЬНЫЕ БУДУТ ОТБРАСЫВАТЬСЯ. Даже если я создам второй сокет на сервере, с портом 36000 — пакет уничтожится.

    Если бы у меня был Full Cone NAT, то после отправки первого пакета на сервер Х:35000, я мог бы передавать этот адрес 46.46.128.128:27015 кому хочу, а они могли бы отправлять с любого адреса и порта сообщения, которые доходили бы.

    При Address Restricted Cone NAT, мой второй сокет на сервере, с портом 36000 смог бы законнектится к клиенту, а вот другие клиенты, с других IP — нет. Опять же, бесполезно передавать им адрес клиента (46.46.128.128:27015), т.к. отправлять может лишь адрес Х.

    При Port Restricted Cone NAT важен лишь порт источника, т.е. я бы мог заранее сказать, что моя прога использует порт 27015, и клиент, и сервер отправляют пакеты только по этому порту — и все работало бы, но второй сокет на сервере с портом 36000 не достучался бы до клиента с портом 27015, как и первый сокет, с портом 35000. Пришлось бы исправить его на 27015.

    Итак, что мы имеем, порт клиента, внутренний, который я забиндил — 27015, при этом внешний сервер его и получает, т.е. NAT его не меняет. До клиента за натом может достучаться только тот, до кого достучался клиент, пакеты от других адресов или портов не доходят.
    У меня симметричный НАТ.
    Я не представляю, как организовать прямую связь. Единственная возможность, которую я вижу, пересылать все пакеты клиентов через сервер.
    Dampire
    > Как только узнаешь что это, то я тебе подскажу как с этим бороться
    Я ГОТОВ! Как бороться с таким натом?

    #12
    11:29, 4 дек 2017

    Ramm
    > Да вроде не все так сложно. Роутер тоже должен уметь делать свой NAT.
    > Например, к роутеру подключены 5 устройств и все дружно лезут в браузер по
    > 80-му порту, роутер не может обслуживать их всех, поэтому выделяет для каждого
    > пользователя свой порт (из числа свободных) и посылает трафик дальше. Запоминая
    > какой порт и для кого он выделил. На выходе NAT провайдера, и там та же самая
    > ситуация, выделяет свободные порты, запоминает что и для кого выделил, и
    > посылает пакеты дальше. Сервер получает пакеты от самого последненго адреса и
    > порта и шлет ответы на них. NAT ответные пакеты он пересылает обратно на нужные
    > порты, а те переходят по иерархии еще ниже.
    Не так. Клиент не просится на 80 порт роутера. Он просит переслать пакет с назначением по порту 80 (на какой-то сайт в интернете), а роутер в процессе NAT-а подменяет адрес и порт отправителя так, как-будто это сам роутер отправил запрос на тот сайт.
    Потом сайт отправляет ответ на исходящий порт роутера, а роутер у себя хранит табличку мапинга и преобразует обратно и отправляет ответ клиенту.
    Если клиент пытается послать запрос напрямую другому такому же клиенту за NAT-ом, то роутер другого клиента станет преградой, т.к. никакого маппинга нет. Есть разные способы это обойти путем посылания пакетов друг другу в надежде, что маппинг сохранится и удасться создать линк, но это все работает не на 100%. Чтобы работало на 100% есть готовые технологии, типа UPnP. Клиент просто говорит своему роутеру, что ему надо пробросить порт наружу и весь трафик, который идет на этот порт роутера автоматически пересылать клиенту. После того, как твоя программа пробросила порт все работает элементарно. Единственное ограничение: роутер должен уметь UPnP (сейчас все практически умеют) и он должен быть включен (проблема самого клиента, с которой он может справиться).

    #13
    11:55, 4 дек 2017

    Ramm
    > При Port Restricted Cone NAT важен лишь порт источника, т.е. я бы мог заранее
    > сказать, что моя прога использует порт 27015, и клиент, и сервер отправляют
    > пакеты только по этому порту — и все работало бы, но второй сокет на сервере с
    > портом 36000 не достучался бы до клиента с портом 27015, как и первый сокет, с
    > портом 35000. Пришлось бы исправить его на 27015.
    Полная фигня или ты плохо объясняешь. Ты стукнулся на сервер 123.123.123.123:1234 с 10.10.10.10:5555 (внешний адрес уже рассматриваем). И теперь сервер может отвечать тебе на 10.10.10.10:5555 только со своего порта под номером 1234. Если он будет слать тебе данные с 123.123.123.123:1235, то пакеты будут просто игнорироваться. То есть. Если в Restricted Cone — ограничение по IP, к которому ты стучался, то в Port-Restricted Cone — ограничение по IP и по порту. Капиш? Теперь понятно почему у тебя ничего не работает? У тебя либо Port-Restricted Cone, либо Симметричный. Это к вопросу о твоей проблеме.

    А теперь приходим к решению. Если у тебя оба клиента будут на симметричном или пара симметричный/port-restricted — хрен ты их соединишь через панчинг. Это просто невозможно (или я не знаю как). Тут только различные UPnP технологии применимы или прокси/туннели.
    Если у тебя есть хоть один клиент, который ты нормально запанчил (то есть открылся порт наружу для всех в режиме Full Cone), то решение по-моему очевидно. Мастер-сервер должен сообщить всем проблемным клиентам «а вот стукнитесь на этот адрес и порт, вас там ждут». Также есть несколько менее очевидных техник, как одновременная отправка пакетов (с предварительным согласованием с мастер-сервером). То есть допустим у тебя 2 port restricted клиента. Чтобы пробить нат, то ты кидаешь «одновременно» по переданным мастер-сервером портам. Разумеется скорее всего эти пакеты не дойдут, но дырки уже пробиты и следующие пакеты проходить будут.
    Детальнее:

    client1->master [listening on addr1:port1] client2->master [listening on addr2:port2] client2->master [need link to client1] master->client2 [client1 is on addr1:port1] master->client1 [requested by client2 on addr2:port2] client1->client2 [sending packet to addr2:port2] // вот тут пробивается пара client2->client1 [sending packet to addr1:port1] // на клиенте1 и на клиенте2. эти пакеты не дойдут, но это и не нужно. // дальше идет общение напрямую

    В твоем случае — мастер должен попросить клиента стукнуться на udp36000, после чего канал будет пробит и все будет работать. Заодно по номеру порта определишь — симметричный у тебя нат или просто порт-рестриктед (что более вероятно).

    #14
    12:06, 4 дек 2017

    PANDA
    > проблема самого клиента, с которой он может справиться
    Прокинуть порты он тоже может, так что NAT это в целом проблема пользователя. UDP панчинг работает достаточно неплохо, если уметь определять типы натов. Не 100% конечно, но шансы высокие даже на ISP (который 146% не будут работать с UPnP).

    Похожие публикации:

    1. Как войти в компанию
    2. Как узнать itemid zabbix
    3. Как узнать внешний ip адрес роутера mikrotik
    4. Когда появится цифровой рубль