13.12.2016 10:02
VASExperts 31 14500 Источник
IPv4 позволяет использовать около 4,3 млрд адресов. Однако «мощности» инфраструктуры интернета, которую заложили в 70-х годах XX века, сегодня становится недостаточно, поскольку в то время никто не предполагал такого быстрого роста потребителей. За последние 20 лет число интернет-пользователей выросло практически в 60 раз, во многом благодаря густонаселенным странам — Индии и Китаю. Также этому поспособствовало распространение мобильных устройств.


/ Flickr / Michael Pardo /CC

Управлением адресным пространством и раздачей IP-адресов занимается Администрация адресного пространства интернета IANA и региональные интернет-регистраторы (ARIN, APNIC, AfriNIC, LACNIC, RIPE NCC). В начале 2011 года IANA выделила последние пять из оставшихся блоков адресного пространства региональным операторам.

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

Что делать


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

Другое решение — внедрение системы IPv6, которая представляет собой последнюю версию IP с практически неограниченным количеством адресов (2 в степени 128). Однако здесь возникает определенная сложность, поскольку протокол IPv6 несовместим с IPv4, что замедляет и усложняет переход.

Есть еще третий вариант. Обратиться к трансляции сетевых адресов (Network Address Translation, NAT), преобразующей множество локальных адресов организации в единый внешний. Механизм работы NAT описывается в RFC 1631, RFC 3022.



Выделяют несколько видов NAT. Первый — статический, который преобразует внутренние адреса во внешние «в масштабе» один к одному. Второй — динамический, транслирующий один внутренний адрес на внешний из предоставленного диапазона. Трансляция осуществляется так же, как и в статическом NAT, только внешний адрес выбирается случайным образом из тех, которые были свободны в момент преобразования.

И, наконец, третий вариант — это так называемый перегруженный NAT (NAPT, NAT Overload, PAT) — является формой динамического NAT, в которой несколько внутренних адресов отображаются на один внешний. Именно этот вариант способен помочь при нехватке публичных IP-адресов.

Максимальное число возможных портов составляет 65 тыс., поэтому, в теории, такое же количество локальных адресов может быть отображено на один внешний адрес. Однако NAT обладает рядом недостатков.

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



Что ждет NAT в будущем


А в будущем нас ждет следующий уровень развития NAT — Carrier Grade NAT (CGN/CGNAT). Решение рассчитано на интернет-провайдеров и операторов связи, но также подходит для замены NAT-устройств в корпоративных сетях. CGN позволяет назначать локальные адреса абонентам, централизовано преобразуя их во внешние.



У решения CG-NAT есть несколько достоинств. Оно обеспечивает прозрачный способ использования NAT, благодаря функциям Endpoint Independent Mapping (EIM), позволяющей для каждого сочетания частного IP-адреса и порта клиента гарантировать то же сочетание публичных IP-адресов, Endpoint Independent Filtering (EIF), отбрасывающей пакеты, не предназначенные для внутренних адресов, и Hairpinning, обеспечивающей доступ одной машины к другой внутри сети по внешнему адресу.

Еще одним важным преимуществом CGN является ограничение количества портов TCP и UDP, доступных абоненту. Это дает возможность эффективного распределения портов между пользователями, а также защищает от DDoS-атак с ботнетов.

Переход на IPv6


Многие операторы начинают постепенно переходить на IPv6, поскольку рано или поздно всем придётся его использовать. Смягчить переход от IPv4 к IPv6 способна технология Carrier-Grade NAT. Для этого применяются следующие решения: NAT64, DS-Lite, 6RD и NAT444.



Технология NAT64 позволяет пользователям услуг на IPv6 предоставлять доступ к ресурсам с адресами IPv4, транслируя адреса нового протокола в адреса старого.



Технология DS-Lite DS Lite использует IPv6-соединение между провайдером и клиентом. Пакет IPv4 от клиента, направляющийся во внешнюю сеть, инкапсулируется в IPv6 для передачи с помощью сети провайдера, а затем преобразуется обратно в IPv4 при переходе в публичный интернет. В этом случае оператор может развернуть у себя сеть IPv6, но продолжать предоставлять услуги подключения для клиентов по IPv4.

Технология 6RD реализует предоставление услуги IPv6 клиентам через существующую сеть IPv4. IPv6-адреса выделяются из подсети, которая закреплена за провайдером интернет-услуг. 6RD-узел, желающий отправить IPv6-пакет по сети, инкапсулирует его в пакет IPv4 и проводит проверку того, находится ли получатель в том же сегменте.

Если это так, то IP-адрес получателя формируется путем дополнения префикса IPv4 битами из IPv6 адресата, не входящими в 6RD-префикс. Если же получатель находится в другом сегменте, то пакет оправляется на шлюз провайдера, который извлекает пакет и затем уже передает его дальше по IPv6-сетям. Механизм описан в RFC 5969.



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

Для реализации любой из этих технологий необходимо либо использовать специальное оборудование для преобразования адресов или туннелирования (A10 Thunder, F5 BIG-IP Carrier-Grade NAT), либо модернизировать имеющиеся сетевые устройства дополнительными сервис-модулями.



Реализовать все это позволяет многофункциональное устройство, например DPI (Deep Packet Inspection) и Carrier-Grade NAT. Такие решения априори рассчитаны на работу с огромными нагрузками при анализе трафика, поэтому легко справятся с трансляцией адресов (функция NAT).
Поделиться с друзьями
-->

Комментарии (31)


  1. ifaustrue
    13.12.2016 13:15
    #9961050
    +4

    Да, жизнь будет всё сложнее, если мир пойдёт по пути NAT'изации всего трафика.
    Хуже если для выхода в интернет нужно будет использовать прокси сервер.
    Прям вспомнились нулевые.


    1. bodqhrohro
      13.12.2016 20:13
      #9962174

      А что нулевые? В организациях такое до сих пор часто встречается.


      1. ifaustrue
        13.12.2016 21:02
        #9962252

        одно дело «злые админы\руководители\нормы\порядки» в организации, другое дело поголовное использование. Когда вообще не будет возможности прямого коннекта между двумя ПК через публичные сети.


        1. Saffron
          15.12.2016 19:55
          #9966894
          +1

          Чиновники просто плясать будут от счастья. Они давно мечтают запретить интернет. Разделить интернет на «серверный» с белыми IP, и регуляцией вусмерть, и «клиентский» — без IP и возможности хостить сайты — просто подарок.

          И без того дело к этому идёт, если смотреть со стороны законодательных инициатив. А если им ещё и технические ограничения помогут, совсем счастье будет.


  1. ef_end_y
    13.12.2016 14:08
    #9961240

    Зато нат частично выполняет функции фаервола — клиент не смотрит в мир всеми своими открытыми портами


    1. Zolg
      13.12.2016 14:38
      #9961340
      +3

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


      1. ef_end_y
        13.12.2016 15:36
        #9961514
        +3

        Т.е извне можно через достучаться до открытых портов компа? Если в большинстве случаев нельзя, то, что это не как частичное выполнение функций фаервола?


        1. Zolg
          13.12.2016 17:47
          #9961858

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


          1. ef_end_y
            13.12.2016 19:58
            #9962148

            Безопасность сети вполне волнует админов ибо, скажем, из-за мусорного трафика некоторые сервисы в нете спокойно могут забанить ip провайдера. Да и изоляция компов абонентов между собой вполне реальный кейс — ну… например, чтобы минимизировать риск перепродажи трафика. Сейчас это не так актуально, а всего несколько лет назад еще было. Изоляция может быть на физическом уровне (виланами) или программном (пппое). В целом это немного улучшает безопасность сети. Немного, да, но я и не говорил, что полностью.


    1. Prototik
      13.12.2016 14:39
      #9961342

      Функции фаерволла должен выполнять грёбанный фаерволл (хотя бы на пограничном оборудовании), а никак не NAT.


      1. ef_end_y
        13.12.2016 15:33
        #9961506
        +3

        Это бонус. Я не говорю, что он должен заменять фаервол, я говорю по факту, что есть и польза от ната — скажем, домашний комп не смотрит в мир «голой задницей»


        1. ksenobayt
          13.12.2016 19:07
          #9962078

          Если вы выходите с домашнего компа в инет, воткнув кабель от провайдера напрямую в машину — у меня для вас плохие новости. Достаточно вспомнить изкоробочный Teredo в последних Windows.


          1. ValdikSS
            13.12.2016 20:48
            #9962220
            +3

            В Windows по умолчанию запрещены все входящие подключения через Teredo. Роутер, к слову, ситуацию с Teredo никак не изменяет и не изменил бы.


  1. miksoft
    13.12.2016 14:22
    #9961280

    Максимальное число возможных портов составляет 65 тыс., поэтому, в теории, такое же количество локальных адресов может быть отображено на один внешний адрес.
    Не могу согласиться с этим утверждением.
    Если локальные адреса будут обращаться к разным адресам во внешней сети (как оно обычно и бывает), то это ограничение не сработает. Проблема случится только когда будет установлено 65 тыс. соединений с внутренних хостов на один порт внешнего ip-адреса. Вот тогда — да, портов не хватит, т.к. удаленный хост может различить соединения только по порту.
    P.S. Тут я не учитываю возможные ограничения конкретных реализаций NAT-а.


    1. miksoft
      13.12.2016 14:53
      #9961396

      Подумалось… Возможно, при использовании протоколов, не использующих UDP или TCP, проблемы могут начаться и раньше, т.к. не во всех протоколах есть понятие порта или его аналог.


      1. Bozaro
        13.12.2016 15:12
        #9961456

        Например: GRE не использует порты.


  1. Kop3t3
    13.12.2016 15:14
    #9961464

    Вот объясните вообще зелёному новичку в сетях:

    OFFTOP
    Есть 2 питон-скрипта. Один — UDP сокет-сервер, второй — то же самое, только клиент.
    Клиент шлёт серверу некоторые данные (допустим, содержимое файла, разбитое на пакеты).
    Внутри локальной сети всё работает.
    Усложним задачу. Теперь сеть выглядит так:
    [сервер] -> [usb модем] -> [провайдер 3g] -> [ИНТЕРНЕТ] -> [провайдер проводной] -> [роутер] -> [клиент]
    или даже так:
    [сервер] -> [Android tethering] -> [провайдер 3g] -> [ИНТЕРНЕТ] -> [провайдер проводной] -> [роутер] -> [клиент]
    т.е. у каждого получается по 2 nat'a. (роутер+провайдер)
    Что должны делать стороны, чтобы сервер продолжил получать данные в такой сети?
    Причём, объясните «для чайников».
    Пробовал:
    Сервер открывает сокет, и отправляет пакет «третьей стороне» с белым ip.
    Третья сторона передаёт ip и порт сервера клиенту.
    Клиент шлёт данные на эти ip и порт.
    Если я правильно понял, то так работает udp hole punching, но в моём случае данные не доходят.
    PS:
    Про то, что можно заставить 3-ю сторону быть ретранслятором я знаю, но интересно именно прямое подключение. 3-я сторона может передавать данные для подключения, например, ip и порты.
    Клиент и сервер (в моём случае) могут влиять на свои роутеры, но вот как открыть порт в случае андроид-тетеринга я не знаю.


    1. Prototik
      13.12.2016 15:31
      #9961502

      А нельзя просто развернуть схему, и поставть сервер за проводной интернет с белым адресом, а клиента — за 3g?


      1. Kop3t3
        13.12.2016 21:11
        #9962268

        Можно, но у проводного интернета адрес ни разу не белый. Белый у 3-й стороны, которую трогать нежелательно.


    1. Bozaro
      13.12.2016 15:49
      #9961544

      В общем случае — проковырять дырку нельзя.
      Могу порекомендовать посмотреть в сторону:



    1. ef_end_y
      13.12.2016 15:50
      #9961550

      Попробуйте залочить номер исходящего порта так чтоб он был таким же как и входящий. Когда udp-пакет проходит через нат, последний запоминает связку «src-ip, dst-ip, src-port, dst-port» и временно разрешает «обратные» пакеты. По идее вы можете даже обойтись без 3й стороны. Я такой эффект наблюдал, когда был админом сети — валил (вероятно вирусный) udp трафик на клиента, при этом клиент довольно долго запросы не делал


      1. Kop3t3
        13.12.2016 21:13
        #9962270

        Можно поподробнее, что значит «залочить»?


        1. ef_end_y
          14.12.2016 01:13
          #9962568

          Когда система создает соединение, она в качестве src-port выбирает рандомный не занятый в данный момент порт. Ответ приходит именно на этот порт. Допустим вы создаете 2 соединения (что не совсем корректно звучит в рамках udp, но все же) на один и тот же хост. Как удаленный хост будет различать пакеты с вашего ip? Правильно, по src-port. Это так, для понимания процесса рассказал. Залочить порт — это сделать чтоб src-port был фиксированным. Я не знаю есть ли либы для питона, которые могут такое делать. Хотя сам в основном программирую на питоне, но для таких вещей использую перл)


          1. Zolg
            14.12.2016 01:50
            #9962604

            Уверен, что либ, позволяющих 'зафиксировать' src порт на NAT'е не существует ни для питона, ни для перла.
            А от фиксированности и известности src-порта на хосте за натом в общем случае толку мало.


            1. ef_end_y
              14.12.2016 02:44
              #9962644
              -1

              Знаете, перл может кем-то и считается некрасивым языком, но говорить, что он чего-то не может — это опасно:

              use IO::Socket::INET;
$| = 1;
$socket = new IO::Socket::INET (
PeerHost => '127.0.0.1',
PeerPort => '5000',
LocalPort => '5000',
Proto => 'udp',
);
print $socket "test\n";


              Тисипидамплю:

              sudo tcpdump -ilo0 -p -n udp
              Password:
              tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
              listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
              01:41:10.327757 IP 127.0.0.1.5000 > 127.0.0.1.5000: UDP, length 5


              1. ef_end_y
                14.12.2016 02:50
                #9962652

                P.S. Я увидел, что вы имеете ввиду фиксацию порта на нате, я как раз об этом и не говорил


              1. Zolg
                14.12.2016 09:24
                #9962816

                Если ваши религиозные чувства задеты упоминанием перла, то возможно утешением будет отсутствие подобных библиотек не толька для перла с питоном, а и для си, явы, эрланга и всех остальных: ну не можете вы на локальной машине влиять, во что будут транслированы нат'ом ваш адрес и (src) порт.
                Код же, приведенный вами задает src порт на локальной машине (и подозреваю, что нет яп, имеющего средства для работы с сокетами, при этом не умеющего такого "функционала"). Но вот огорчение: снаружи от ната от (номера) этого порта никакой пользы нет, от слова совсем.


                1. ef_end_y
                  14.12.2016 09:59
                  #9962862

                  Честно говоря, я подумал, что вы меня тролите в том, что я не могу создать сокет с заданным src портом и я просто на нем забиндил адрес. А на счет того, что на выходе нат-а будет иной порт — признаю, я почему-то подумал, что речь идет не о симметричном нате и порт не будет подменен. В случае симметричного нат-а, конечно смысла в фиксации порта на клиенте нет смысла. Просто иначе организовать соединения через 2 ната — это уже хакерские фишки со спуфингом ip — видимо из-за этого подумал, что у человека проще условия


    1. Alexeyslav
      13.12.2016 17:19
      #9961756

      Скорей всего на той стороне стоит фаервол который следит за состоянием соединений и просто не может пропустить входящий пакет если на этот адрес/порт не было исходящего — т.е. соединение небыло инициировано изнутри сети. Иногда, эта проблема решается технологией UPNP, когда клиент специальным способом сообщает NAT что он ожидает входящее соединение. По крайней мере, последний uTorrent-клиент каким-то образом это делает. Современные роутеры в режиме NAT поддерживают UPNP, а дальше провайдер и дело за ним…


    1. Zolg
      14.12.2016 02:00
      #9962612

      Что бы работал ваш велосипедный stun необходимо, чтобы src ip и порт в которые нат транслирует внутренний адрес и порт стороны А были одинаковыми как для пакетов к стороне Б, так и для пакетов к третьей стороне. В общем случае это не так.
      В частном — практически наверняка это не так у 3g провайдера. Поэтому совет поменять местами клиента с сервером некоторого смысла не лишен.


  1. ValdikSS
    13.12.2016 16:30
    #9961640
    +3

    А в будущем нас ждет следующий уровень развития NAT — Carrier Grade NAT (CGN/CGNAT).
    Да, вроде как, все постепенно двигаются в сторону 464XLAT и аналогов, чтобы в сети были только IPv6-адреса, а IPv4-трансляции совершались только на NAT64-устройствах. В отличие от DS-Lite, 464XLAT — транслятор, а не туннель, что создает меньшую нагрузку на оборудование, и позволяет передавать большее количество данных в одном пакете.
    Это не панацея, т.к. 464XLAT поддерживается только на мобильных устройствах, да и не на всех, но, например, T-Mobile USA и Orange Poland уже несколько лет используют его для некоторых устройств.