Вот уже несколько лет, как протокол IP версии 6 (IPv6) пытается заменить собой протокол IP версии 4 (IPv4), который обеспечивает на данный момент функционирование всего интернета. Однако, бурно развившись, идея IPv6 так и остановилась на пути к своему реальному воплощению.
Энтузиасты создали стандарт, построили локальные экспериментальные сети на базе нового протокола и на этом практически всё встало. Как оказалось, для внедрения IPv6 потребуется переписывать всё сетевое программное обеспечение, которое существует на данный момент, и стеки TCP/IP всех сетевых операционных систем. Зная, как сложно развивается рынок операционных систем в последнее время, можно предположить, что поддержка IPv6 появится во всех ОС очень и очень нескоро - ведь для этого требуются немалые деньги в виде человеко-часов труда программистов.
Получается, что IPv6 не так уж и необходим, как это декларируют сторонники его внедрения, по крайней мере, целесообразность его внедрения стоит под большим вопросом ввиду огромных накладных расходов.
Основными причинами создания нового стандарта были защита передаваемой информации с помощью шифрования по протоколу IPSec и существенно расширенный диапазон адресов.
Однако протокол шифрования IPSec уже успешно используется и для сетей, построенных на базе IPv4, и любая организация, которая беспокоится о безопасности передачи данных через интернет, может использовать IPSec без каких бы то ни было проблем уже сейчас, не дожидаясь внедрения IPv6.
Вторая проблема заключается в росте сети и непропорциональном распределении адресного пространства между материками, в результате чего в интернете в обозримом будущем просто не останется свободных адресов. Но и у второй проблемы есть хоть и частичное, но решение - это трансляция адресов.
Суть этой технологии заключается в использовании одного IP-адреса для организации доступа в интернет десятков компьютеров. Конечно, назвать такой доступ полноценным нельзя, ведь в таком режиме клиенты, подключенные к интернету, не могут принимать входящие соединения, но, во-первых, подавляющему числу корпоративных пользователей это и не нужно, во-вторых, возможность подключиться к компьютеру клиента является, порой, серьёзной уязвимостью в безопасности, т.е. недостатком.
Технология трансляции адресов (NAT - Network Address Translation) позволяет не только в десятки раз сократить количество адресов, необходимых для организации доступа в интернет корпоративных клиентов, но и позволяет ввести пассивные меры безопасности. Эта технология по определению не поддерживает входящие соединения, т.е. защищает клиента от прямых атак из интернета. Как уже было отмечено, в основном, технологию трансляции адресов используют корпоративные клиенты, т.е. организации, которые подключены к Сети по выделенной линии. Это обуславливается тем, что любая современная компания имеет свою внутреннюю изолированную сеть и пользователей в ней, которые должны иметь безопасный доступ в интернет. Именно между адресами локальной сети и адресами интернета осуществляется трансляция адресов IP-пакетов.
Конек технологии NAT заключается в том, что ни сервер в интернете, ни клиент в локальной сети не знают, что взаимодействуют через трансляцию адресов - они "видят" друг друга напрямую. Работает это так: когда клиент пытается послать IP-пакет в интернет, находясь во внутренней сети, маршрутизатор компании обнаруживает попытку установления сессии из внутренней сети во внешнюю, регистрирует сессию в своей таблице сессий, переписывает обратный адрес данного пакета на интернет-адрес и посылает его серверу назначения в интернете. При этом сервер в интернете получит пакет уже от имени маршрутизатора. Впоследствии, когда марштуризатор примет пакет, адресованный зарегистрированной сессии, он перепишет адрес назначения на адрес клиента из внутренней сети и отправит его клиенту. Клиент же получит пакет от имени сервера в интернет. Таким образом, маршрутизатор совершенно прозрачно переписывает адреса проходящих пакетов, и ни сервер, ни клиент не подозревают о том, что работают через транслятор пакетов.
Другие названия этой технологии - "Маскарадинг" (Masquerading), этот термин использовался, в основном, на Linux, "Трансляция адреса источника" (SNAT - Source Network Address Translation), этот термин использует CISCO Systems, и "Dynamic NAT", который подходит по смыслу.
Как показывает практика, на один публичный адрес можно назначить сессии до 100 внутренних клиентов, что позволяет сэкономить до 99 интернет-адресов. Если клиентов больше 100, может потребоваться выделение дополнительных интернет-адресов, поскольку количество одновременно установленных сессий может превысить лимит, отведённый для одного IP-адреса.
Популярность технологии NAT объясняется её полной прозрачностью для клиента и широчайшим спектром поддерживаемых приложений. Фактически, через NAT может работать любое приложение, не требующее установления входящих сессий со стороны сервера. Правда, существуют реализации NAT, которые поддерживают протоколы более высокого уровня определённых приложений, требующих такую возможность. Например, современные версии ядер для Linux поддерживают трансляцию пакетов для протокола FTP, работающего в активном режиме, а пассивный режим FTP работает и через "классический", т.е. простой, NAT.
Сложность реализации возможности установления входящего соединения со стороны сервера заключается в том, что в этом случае NAT должен следить за содержимым всех пакетов и как бы "предсказывать", что в определённый момент потребуется принять входящее соединение на определённый порт и перебросить его внутреннему клиенту. Помимо сложности разработки таких расширений для NAT, придётся "обучать" NAT тонкостям всех таких протоколов. Это ещё добавит дополнительную нагрузку на процессор маршрутизатора, ибо маршрутизатор будет вынужден просматривать и анализировать содержимое всех проходящих через трансляцию пакетов. Простой же NAT оперирует исключительно с заголовками IP-пакетов и не меняет их содержимого.
Другая практика, которая используется для сокращения числа используемых адресов, как и для обеспечения безопасности внутренних клиентов, - это использование прокси-сервера, что потребует поддержки этой технологии каждой программой, которая будет взаимодействовать с интернетом. На практике технология проксирования используется только для Web- и FTP-соединений, поскольку, во-первых, подавляющее большинство существующих программ это поддерживает, во-вторых, проксируя HTTP протокол (Web), можно вести базу уже загруженных из интернета страниц и не закачивать те же самые страницы повторно. Практика показывает, что за счёт кэширования Web-страниц в локальной базе прокси-сервера можно экономить от 10 до 50 процентов пропускной способности канала в интернете, а это ещё и прямая экономия средств предприятия плюс повышенная безопасность.
Получается, что для решения двух острейших проблем - безопасности и адресного пространства, можно вполне эффективно использовать относительно новые технологии - IPSec и NAT, которые хоть и не являются панацеей, но довольно значительно могут отодвинуть время "Ч", после которого использование IPv4 будет просто невозможным ввиду его ограниченности.
Есть, правда, ещё и третий стимул для внедрения IPv6 - мобильные сети следующего поколения "3G", которые используют IPv6 для коммутации мобильных устройств в информационных сетях. И, как заявляют разработчики систем 3G, каждое мобильное устройство будет требовать свой IP-адрес. В этом случае действительно без IPv6 не обойтись, поскольку, если каждый мобильный телефон стандарта 3G будет иметь свой адрес в интернете, то свободное адресное пространство в IPv4 будет израсходовано с чудовищной быстротой.
Но на данный момент ведущие европейские провайдеры беспроводного доступа один за другим отказываются от планов внедрения 3G-сетей по экономическим причинам, так что и это отодвигает IPv6 всё дальше и дальше.
Что ж, поживём - увидим, что получится у мирового сообщества лучше: оптимизация использования существующего IPv4-адресного пространства или переход на расширенную его версию и огромные накладные расходы.
© 2002 Алексей ГРЕЧАНИНОВ
![Версия для печати Версия для печати](https://www.kv.by/sites/all/modules/print/icons/print_icon.png)
Горячие темы