Так ли страшен Symmetric NAT

    Задача прямого соединения машин, находящихся за NAT'ом стара как мир и я думаю, что многие слышали про UDP Hole Punching. Когда я только начинал интересоваться вопросом, я утвердился во мнении, что symmetric nat пробить невозможно и пытаться даже не стоит. Однако совсем недавно мне попалась статья в которой утверждалось, что симметричный нат — это не приговор.

    Давайте разберемся.

    Типы NAT


    Традиционно во многих статьях в Интернете все NATы делят на четыре типа:
    • Full-cone NAT;
    • Address-restricted cone NAT;
    • Port-restricted cone NAT;
    • Symmetric NAT

    На самом деле это неверно. Точнее не совсем верно. У любого NAT’a есть две основных характеристики:

    1) фильтр входящих пакетов;
    2) правило маппинга портов.

    Первая характеристика как раз описана в большинстве статей и означает, какие входящие пакеты передавать машине за NAT’ом: все (no filter – Full cone), с конкретного адреса (address-restricted) или с конкретного адреса и порта (port-restricted).

    Вторая характеристика же присуще только симметричному НАТ’у, так как первые три типа пытаются сделать отражение один в один. Например, если клиент посылает пакет с внутреннего адреса 192.168.10.24:62145, то от роутера пакет пойдет с адреса 1.2.3.4:62145. Причем вне зависимости от адреса получателя.

    Symmetric NAT


    А теперь детальнее про симметричный NAT. Сразу оговорюсь, что фильтры входящих пакетов тоже могут быть любые (no filter, address-restricted или port-restricted). И единственное отличие этого типа NAT’a от предыдущих как раз в выборе исходящего порта на роутере, он почти наверняка будет отличаться от исходного порта на клиенте. Вернувшись к предыдущему примеру отражение может быть таким: 192.168.10.24:62145 -> 1.2.3.4:1274.

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

    • Порт может оставаться всегда одним и тем же, в не зависимости от получателя (cone);
    • Порт может оставаться одним и тем же для конкретного адреса получателя (address);
    • Порт может оставаться одним и тем же лишь для конкретного адреса и порта получателя (port);


    При этом есть еще и правила для выбора следующего порта:
    Это может быть какая-то дельта (+1/-1 или +10/-10) или вообще каждый раз случайно.
    Кроме того видел один NAT у которого каждый последующий порт отстоял от предыдущего на случайное число, но всегда кратное 4096.

    Вместо заключения


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

    Ну что же мы подобрались к сути и цели статьи. Ответу на вопрос

    «Можно ли определить правило распределения портов и дельту, находясь за NAT’ом?»

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

    И тут я призываю хабрасообщество мне помочь со статистикой. На просторах Интернета был найден простенький stun клиент, немножко допилен кувалдой и вот что получилось:

    Исходник

    Пользователи Линукса прекрасно знают как это скомпилировать.
    Вот так
    gcc -lpthread -o stun stun.c


    Под винду отлично компилится студией, вот тут бинарник, если студии под рукой нет.

    Да простит меня stun.counterpath.net за хабра эффект :)

    Вот мои результаты, но у меня не симметричный НАТ и не интересно:

    Results
    tests: 1010
    NAT present: 1
    first preserved port: 1
    preserves port: 0
    type: Port restricted NAT
    mapped ports: 55907 55907 55907 55907


    Всем спасибо за помощь!

    udp: Оставляйте, пожалуйста, ваши результаты в комментариях, даже если НАТ не симметричный. Ведь в любом случаю важно знать распиновку по типам.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 11

      0
      Выбирается тот самый порт случайно (ну или не случайно, а по очереди, но это не важно, так как повлиять на его выбор извне мы не можем). Но есть определенные правила, они похожи на фильтр входящих пакетов:

      Порт может оставаться всегда одним и тем же, в не зависимости от получателя (cone);
      Порт может оставаться одним и тем же для конкретного адреса получателя (address);
      Порт может оставаться одним и тем же лишь для конкретного адреса и порта получателя (port);


      Если не секрет, где в природе можно встретить symmetic наты, которые по разному назначают порты в зависимости от адреса (и) порта получателя? Это какие-то программные решения, или может есть конкретные физические модели с такими настройками?
        0
        ну вот тот единственный который у меня знакомый делает именно так.
        Я завтра уточню что за железо (я только удаленно видел).
          0
          «именно так» — это какой вариант из трех, если не секрет?
            0
            вот именно тот нат, который на каждое новое соединение выбирал последующий порт таким образом, что тот отстоял от предыдущего на случайное число, но всегда кратное 4096.

            то есть фактически это симметричный нат с входящим фильтром по порту (Port-restricted), с port-dependent mapping и псевдослучайным выбором исходящего порта.
        0
        Вопрос. А если за НАТом много разных клиентов сидит, у которых много разных аппликух, открывающие много разных портов в единицу времени (ну, например, какие нить торренты). То как тогда? Ведь насколько я понял пробить NAT таким образом можно лишь в идеальных условиях — в течение некоторого времени только наша программа пытается пробиться наружу, и другие программы не мешают ей вычислять дельту перехватом портов из-под носа. Нет?
          0
          Вопрос справедливый. Разумеется за то время пока мы узнали внешний порт и отправили первый пакет пиру может случиться коннект. Для этого пиру предлагается не только «следующий» порт, а, скажем, 10 «следующих» портов, вот тут вероятность попасть выше.
          0
          Гадание на кофейной гуще? В чём прфит исследования?
            0
            вот цель как раз и понять гадание или нет.

            Интерес набрать реальных примеров из жизни, а не синтетических из статей. Вот к примеру тот нат, что я описал, ни в одной заметке не приводился и глянув лишь на 4 порта из результатов я бы решил, что они выбираются просто случайно, а сейчас знаю, что бывает и так и его, пожалуй, тоже реально пробить.
            +1
            FreeBSD (ipfw):
            Results
            — tests: 1010
            NAT present: 1
            first preserved port: 1
            preserves port: 0
            type: Port restricted NAT
            mapped ports: 62251 62251 62251 62251

            RouterOS (Mikrotik RB433):
            Results
            — tests: 1010
            NAT present: 1
            first preserved port: 1
            preserves port: 1
            type: Port restricted NAT
            mapped ports: 52219 52219 52219 52219
              0
              Вот тут давно все описано для общего случая, когда порт случаен или псевдослучаен, но от этого не легче

              yourcmc.ru/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B4%D0%BE%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D1%80%D1%8C%D0%B5%D1%80%D0%B0_%D0%B8%D0%B7_%D0%B4%D0%B2%D1%83%D1%85_%D1%81%D0%B8%D0%BC%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%87%D0%BD%D1%8B%D1%85_NAT

                0
                Провел эксперимент (что называется на коленке), в котором роль посредника (хоста3) взял на себя, т. е. по указанному алгоритму «подглядел» снифером нужные величины и вбил их в соотв. скрипты. Первый «пробой» симметричного НАТ-а (в сторону оператора мобильной связи) произошел через 8 часов после начала перебора (скорость перебора со сменой порта источника за НАТ устройством была обеспечена в 5 пакетов в секунду с помощью специфичных настроек UDP-генератора). Факт пробоя зафиксировался на сером ип хоста с 3G модемом. С наступлением ночи пробои участились, следующий был через 3 часа, еще два с разницей в час.

              Only users with full accounts can post comments. Log in, please.