В наших квартирах все больше и больше появляется разных цифровых устройств — ноутбуков, планшетов и смартфонов. Пока компьютер в квартире был один и подключен напрямую к сети провайдера — не возникало вопросов. А теперь, когда перед Вами встала проблема — как подключить теперь новый ноутбук или планшет к Интернету. Вот тут на помощь и приходит технология NAT . В чем суть технологии NAT?
NAT — Network Address Translation — в переводе на русский звучит примерно так: «преобразование сетевых адресов». NAT - это механизм в сетях TCP/IP, который позволяет преобразовывать IP-адреса транзитных пакетов.
Если выражаться простым языком — то если есть несколько компьютеров в локальной сети, то благодаря технологии NAT все они могут выходить во внешнюю сеть Интернет используя при этом один внешний айпи адрес (IP ).

Что такое IP-адрес?

Маршрутизатор — роутер — работает на третьем уровне системы OSI, соответственно используется протокол IP — маршрутизируемый протокол сетевого уровня стека TCP/IP. Неотъемлемой частью протокола является адресация сети. В соответствии с имеющимися правилами — всем устройствам в сети назначаются IP-адреса (Ай-Пи адреса ) — уникальные сетевые идентификаторы адреса узла. Используется 2 типа IP-адресов — серые и белые . Серые адреса — это часть адресного пространства, выделенная под локальную сеть — подсети IP-адресов 10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16 . Все остальные подсети используются в сети Интернет и являются белыми IP-адресами.

Как обеспечить общий доступ в Интернет для устройств в сети.

Для того, чтобы подключить к Интернет все устройства в локальной сети Вам понадобиться роутер . Роутер — это устройство, которое умеет подключаться через сеть провайдера к Интернет и раздавать его на подключенные устройства благодаря тому, что у него есть как минимум 4 LAN-порта и Wi-Fi модуль . Не путайте роутер с простым Ethernet-свитчем, который по сути является тупым «разветвителем» сети. Благодаря тому, что на роутере установлена операционная UNIX-подобная система, на устройстве можно поднимать различные сервисы, в том числе и сервис NAT . Для этого при настройке роутера ставиться галочка Enable NAT .

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

IP-адреса являются дефицитным ресурсом. У провайдера может быть /16-адрес (бывший класс В), дающий возможность подключить 65 534 хоста. Если клиентов становится больше, начинают возникать проблемы. Хостам, подключающимся к Интернету время от времени по обычной телефонной линии, можно выделять IP-адреса динамически, только на время соединения. Тогда один /16-адрес будет обслуживать до 65 534 активных пользователей, и этого, возможно, будет достаточно для провайдера, у которого несколько сотен тысяч клиентов. Когда сессия связи завершается, IP-адрес присваивается новому соединению. Такая стратегия может решить проблемы провайдеров, имеющих не очень большое количество частных клиентов, соединяющихся по телефонной линии, однако не поможет провайдерам, большую часть клиентуры которых составляют организации.

Дело в том, что корпоративные клиенты предпочитают иметь постоянное соединение с Интернетом, по крайней мере в течение рабочего дня. И в маленьких конторах, например туристических агенствах, состоящих из трех сотрудников, и в больших корпорациях имеются локальные сети, состоящие из некоторого числа компьютеров. Некоторые компьютеры являются рабочими станциями сотрудников, некоторые служат веб-серверами. В общем случае имеется маршрутизатор ЛВС, соединенный с провайдером по выделенной линии для обеспечения постоянного подключения. Такое решение означает, что с каждым компьютером целый день связан один IP-адрес. Вообще-то даже все вместе взятые компьютеры, имеющиеся у корпоративных клиентов, не могут перекрыть имеющиеся у провайдера IP-адреса. Для адреса длины /16 этот предел равен, как мы уже отмечали, 65 534. Однако если у поставщика услуг Интернета число корпоративных клиентов исчисляется десятками тысяч, то этот предел будет достигнут очень быстро.

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

а) пользователи получают постоянный IP-адрес;

б) отсутствует повременная оплата (взимается только ежемесячная абонентская плата).

Пользователи такого рода услуг имеют постоянное подключение к Интернету. Развитие в данном направлении приводит к возрастанию дефицита IP-адресов. Присваивать IP-адреса «на лету», как это делается при телефонном подключении, бесполезно, потому что число активных адресов в каждый момент времени может быть во много раз больше, чем имеется у про­вайдера.

Часто ситуация еще больше усложняется за счет того, что многие пользователи ADSL и кабельного Интернета имеют дома два и более компьютера (например, по одному на каждого члена семьи) и хотят, чтобы все машины имели выход в Интернет. Что же делать - ведь есть только один IP-адрес, выданный провайдером! Решение таково: необходимо установить маршрутизатор и объединить все компьютеры в локальную сеть. С точки зрения провайдера, в этом случае семья будет выступать в качестве аналога маленькой фирмы с несколькими компьютерами. Добро пожаловать в корпорацию Пупкиных!

Проблема дефицита IP-адресов отнюдь не теоретическая и отнюдь не относится к отдаленному будущему. Она уже актуальна, и бороться с ней приходится здесь и сейчас. Долговременный проект предполагает тотальный перевод всего Интернета на протокол IPv6 со 128-битной адресацией. Этот переход действительно постепенно происходит, но процесс идет настолько медленно, что затягивается на годы. Видя это, многие поняли, что нужно срочно найти какое-нибудь решение хотя бы на ближайшее время. Такое решение было найдено в виде метода трансляции сетевого адреса, NAT (Network Address Translation) , описанного в RFC 3022. Суть его мы рассмотрим позже, а более подробную информа­цию можно найти в (Butcher, 2001).

Основная идея трансляции сетевого адреса состоит в присвоении каждой фирме одного IP-адреса (или, по крайней мере, небольшого числа адресов) для интернет-трафика. Внутри фирмы каждый компьютер получает уникальный IP-адрес, используемый для маршрутизации внутреннего трафика. Однако как только пакет покидает пределы здания фирмы и направляется к провайдеру, выполняется трансляция адреса. Для реализации этой схемы было создано три диапазона так называемых частных IP-адресов. Они могут использоваться внутри компании по ее усмотрению. Единственное ограничение заключается в том, что пакеты с такими адресами ни в коем случае не должны появляться в самом Интернете. Вот эти три зарезервированных диапазона:

10.0.0.0 - 10.255.255.255/8 (16 777 216 хостов)

172.16.0.0 - 172.31.255.255/12 (1 048 576 хостов)

192.168.0.0 -192.168.255.255/16 (65 536 хостов)

Работа метода трансляции сетевых адресов показана на нжеследующей схеме. В пределах территории компании у каждой машины имеется собственный уникальный адрес вида 10.x.y.z. Тем не менее, когда пакет выходит за пределы владений компании, он проходит через NAT-блок, транслирующий внутренний IP-адрес источника (10.0.0.1 на рисунке) в реальный IP-адрес, полученный компанией от провайдера (198.60.42.12 для нашего примера). NAT-блок обычно представляет собой единое устройство с брандмауэром , обеспечивающим безопасность путем строго отслеживания входящего и исходящего -трафика компании. NAT-блок может быть интегрирован с маршрутизатором компании.

Мы до сих пор обходили одну маленькую деталь: когда приходит ответ на запрос (например, от веб-сервера), он ведь адресуется 198.60.42.12. Как же NAT-блок узнает, каким внутренним адресом заменить общий адрес компании? Вот в этом и состоит главная проблема использования трансляции сетевых адресов. Если бы в заголовке IP-пакета было свободное поле, его можно было бы использовать для запоминания адреса того, кто посылал запрос. Но в заголовке остается неиспользованным всего один бит. В принципе, можно было бы создать такое поле для истинного адреса источника, но это потребовало бы изменения IP-кода на всех машинах по всему Интернету. Это не лучший выход, особенно если мы хотим найти быстрое решение проблемы нехватки IP-адресов.

На самом деле произошло вот что. Разработчики NAT подметили, что большая часть полезной нагрузки IP-пакетов - это либо TCP, либо UDP . Оба формата имеют заголовки, содержащие номера портов источника и приемника. Номера портов представляют собой 16-разрядные целые числа, показывающие, где начинается и где заканчивается TCP-соединение. Место хранения номеров портов используется в качестве поля, необходимого для работы NAT.

Когда процесс желает установить TCP-соединение с удаленным процессом, он связывается со свободным TCP-портом на собственном компьютере. Этот порт становится портом источника, который сообщает TCP-коду информацию о том, куда направлять пакеты данного соединения. Процесс также определяет порт назначения. Посредством порта назначения сообщается, кому отдать пакет на удаленной стороне. Порты с 0 по 1023 зарезервированы для хорошо известных сервисов. Например, 80-й порт используется веб-серверами, соответственно, на них могут ориентироваться удаленные клиенты. Каждое исходящее сообщение TCP содержит информацию о порте источника и порте назначения. Вместе они служат для идентификации процессов на обоих концах, использующих соединение.

Проведем аналогию, которая несколько прояснит принцип использования портов. Допустим, у компании есть один общий телефонный номер. Когда люди набирают его, они слышат голос оператора, который спрашивает, с кем именно они хотели бы соединиться, и подключают их к соответствующему добавочному телефонному номеру. Основной телефонный номер является аналогией IP-адреса компании, а добавочные на обоих концах аналогичны портам. Для адресации портов используется 16-битное поле, которое идентифицирует процесс, получающий входящий пакет.

С помощью поля Порт источника мы можем решить проблему отображения адресов. Когда исходящий пакет приходит в NAT-блок, адрес источника вида 192.168.c.d заменяется настоящим IP-адресом. Кроме того, поле Порт источника TCP заменяется индексом таблицы перевода NAT-блока, содержащей 65 536 записей. Каждая запись содержит исходный IP-адрес и номер исходного порта. Наконец, пересчитываются и вставляются в пакет контрольные суммы заголовков TCP и IP. Необходимо заменять поле Порт источника, потому что машины с местными адресами 10.0.0.1 и 10.0.0.2 могут случайно пожелать воспользоваться одним и тем же портом (5000-м, например). Так что для однозначной идентификации процесса отправителя одного поля Порт источника оказывается недостаточно.

Когда пакет прибывает на NAT-блок со стороны провайдера, извлекается значение поля Порт источника заголовка TCP. Оно используется в качестве индекса таблицы отображения NAT-блока. По найденной в этой таблице записи определяются внутренний IP-адрес и настоящий Порт источника TCP. Эти два значения вставляются в пакет. Затем заново подсчитываются контрольные суммы TCP и IP. Пакет передается на главный маршрутизатор компании для нормальной доставки с адресом вида 192.168.y.z.

В случае применения ADSL или кабельного Интернета трансляция сетевых адресов может применяться для облегчения борьбы с нехваткой адресов. Присваиваемые пользователям адреса имеют вид 10.x.y.z. Как только пакет покидает пределы владений провайдера и уходит в Интернет, он попадает в NAT-блок, который преобразует внутренний адрес в реальный IP-адрес провайдера. На обратном пути выполняется обратная операция. В этом смысле для всего остального Интернета провайдер со своими клиентами, использующими ADSL и кабельное:оединение, представляется в виде одной большой компании.

Хотя описанная выше схема частично решает проблему нехватки IP-адресов, многие приверженцы IP рассматривают NAT как некую заразу, распространяющуюся по Земле. И их можно понять.

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

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

В-третьих, NAT нарушает одно из фундаментальных правил построения многоуровневых протоколов: уровень k не должен строить никаких предположений относительно того, что именно уровень k + 1 поместил в поле полезной нагрузки. Этот принцип определяет независимость уровней друг от друга. Если когда-нибудь на смену TCP придет ТСР-2, у которого будет другой формат заголовка (например, 32-битная адресация портов), то трансляция сетевых адресов потерпит фиаско. Вся идея многоуровневых протоколов состоит в том, чтобы изменения в одном из уровней никак не могли повлиять на остальные уровни. NAT разрушает эту независимость.

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

В-пятых, некоторые приложения вставляют IP-адреса в текст сообщений. Получатель извлекает их оттуда и затем обрабатывает. Так как NAT не знает ничего про такой способ адресации, он не сможет корректно обработать пакеты, и любые попытки использования этих адресов удаленной стороной приведут к неудаче. Протокол передачи файлов, FTP (File Transfer Protocol), использует именно такой метод и может отказаться работать при трансляции сетевых адресов, если только не будут приняты специальные меры. Протокол интернет-телефонии Н.323 также обладает подобным свойством. Можно улучшить метод NAT и заставить его корректно работать с Н.323, но невозможно же дорабатывать его всякий раз, когда появляется новое приложение.

В-шестых, поскольку поле Порт источника является 16-разрядным, то на один IP-адрес может быть отображено примерно 65 536 местных адресов машин. На самом деле это число несколько меньше: первые 4096 портов зарезервированы для служебных нужд. В общем, если есть несколько IP-адресов, то каждый из них может поддерживать до 61 440 местных адресов.

Эти и другие проблемы, связанные с трансляцией сетевых адресов, обсуждаются в RFC 2993. Обычно противники использования NAT говорят, что решение проблемы нехватки IP-адресов путем создания временной заплатки только мешает процессу настоящей эволюции, заключающемуся в переходе на IPv6. Но если вернутся в реальность, то мы увидим, что в большинстве случаев NAT - это просто незаменимая вещь, особенно для малых офисов с числом компьютеров от нескольких штук до нескольких десятков. NAT можно реализовать собственными силами в OS Linux используя

Что такое NAT

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

Обычно это значит, что компьютер подключен сразу к модему (DSL, кабельному или обычному аналоговому).

За NAT означает, что ваш компьютер подключен не к интернету, а к локальной сети. Тогда у него внутренний IP адрес, из интернета сам по себе недоступный.

Доступ к интернету ваш компьютер получает через NAT - процесс трансляции внутренних адресов во внешние и обратно. NAT-устройство обычно называют раутером.

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

Находим IP адрес компьютера

Run">Откройте диалоговое окно для запуска программ: клик на кнопке Пуск, в меню выберите Выполнить .

В Windows 2000/XP набираем команду cmd /k ipconfig , нажимаем OK и смотрим на результат.

Windows 2000 IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.1.10 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1

Первый из этих адресов - это IP адрес вашего компьютера.

Нaходитесь ли вы за NAT

Три специальных диапазона IP адресов зарезервированы для локальных сетей и в интернете не используются:

10. 0. 0. 0 - 10. 255.255.255 172. 16. 0. 0 - 172. 31.255.255 192.168. 0. 0 - 192.168.255.255

Если IP адрес вашего компьютера находится в одном из этих диапазонов, то есть начинается с 10. или с 192.168. или с 172.nn. (где nn - от 16 до 31) , то это локальный (внутренний) адрес, и вы точно находитесь за NAT.

Если нет, то теперь проверьте, под каким IP адресом вас видят другие компьютеры в интернете. Например на whatsmyip.org ("Your IP Address is x.x.x.x" вверху страницы) или на myipaddress.com .

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

В остальных случаях наверняка сказать нельзя. Возможны такие варианты:

• вы находитесь за NAT, но ваш сетевой администратор выбрал нестандартные внутренние адреса для вашей локальной сети. Найдите его и поинтересуйтесь, зачем так нужно было делать.
• вы выходите в интернет через прокси сервер (тогда whatsmyip.org показал вам адрес этого прокси сервера). Во многих случаях вы можете определить, есть ли между вами и интернетом прокси сервер, пользуясь например lagado.com/proxy-test .

  Подключение через прокси в этом руководстве не рассматривается .

Варианты подключения через NAT

Если вы за NAT, то следующим шагом надо определить, где именно находится NAT-устройство.

NAT провайдера

Тогда говорят, что
• провайдер предоставляет вам интернет через NAT ,
• или что провайдер не дает вам внешний IP адрес ,
• или что вы подключены через локальную сеть провайдера

Проще всего позвонить провайдеру и узнать. Или поинтересоваться у знающих соседей с таким же подключением.

При подключении к интернету через локальную сеть провайдера сделать себе доступный порт нельзя. Если, конечно, провайдер специально для вас не перенаправит определенный порт, что малореально. Или если вы не заплатите дополнительно за услугу, которая обычно называется "внешний" ("белый") IP адрес.

NAT в офисе или многоквартирном доме

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

Кроме того, можно также попробовать UPnP, вдруг в раутере оставили его разрешенным.

NAT ваш собственный

В этом случае вы практически всегда можете его настроить и получить доступный порт.

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

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

/05.07.2004 20:43/

Последние годы среди российских сетевых администраторов стихийно возрастает мода на FireWall и NAT . Моё отношение к этим технологиям пользователи Eserv знают еще с середины 90х годов, но иногда такие вопросы о FireWall / NAT задаются новичками, и приходится повторяться. Поэтому около года назад я написал отдельную статью о FireWall , а сегодня настала очередь NAT.

Эпиграф

Добавлено 28.12.2005 . Хорошее резюме проблемы NAT сделали Google : "NAT devices, increasingly popular in homes and offices, allow multiple machines to share a single Internet address. Consequently, it becomes more and more difficult for applications such as voice chat, which require peers to directly address each other, to make a peer-to-peer connection reliably." (NAT-устройства, популярность которых растет в домах и офисах, позволяют нескольким машинам совместно использовать один интернет-адрес. В результате таким приложениям как голосовой чат, требующим прямой адресации сторон, все сложнее и сложнее создавать надежные соединения точка-точка.)

Оглавление документа

История NAT

Сначала несколько слов об истории появления необходимости в проксировании / гейтировании / туннелировании в интернете, тогда яснее станут возможности разных подходов и их "иерархия". Как известно, нехватка IP-адресов в 4-байтовом адресном пространстве прогнозировалась еще в начале 90х годов (плюс нехватка денег на аренду адресных блоков в некоторых компаниях . Поэтому уже в марте 1994 г договорились об адресном "сегментировании" общего пространства - выделении для локальных сетей отдельных диапазонов IP-адресов и исключение этих IP-адресов из использования в интернете (http://www.ietf.org/rfc/rfc1597.txt March 1994 Address Allocation for Private Internets ; цитата о назначении этого документа "Авторы надеются, что использование этих методов приведет к значительной экономии при выделении адресов"). Это решение позволило выделять компаниям небольшие блоки IP-адресов - для их интернет-серверов, а внутри ЛС IP-адреса для собственных нужд выделялись самими компаниями из диапазонов для локальных сетей. В результате интернет-серверы компаний (почтовые и www/ftp) были легко доступны как из интернета, так и из ЛС, и внутри ЛС компьютеры без проблем связывались по таким же IP-протоколам. Но это решение воздвигло барьер между локальными сетями и интернетом: т.к. один и тот же IP-адрес мог использоваться в разных ЛС, и т.к. по этой причине в интернете перестали маршрутизировать пакеты на адресные блоки, выделенные для ЛС. Т.е. фактически "физический барьер" (без перерубаний проводов, чем развлекались в российских банках после первых взломов, и без установки FireWall , чем увлекаются сейчас). Сети стали изолированными, как изолированы задачи в современных операционных системах - у каждой своё адресное пространство. Этот барьер не представлял проблемы для почты, т.к. почтовые серверы предприятий ставились на границе сетей и были видимы и из интернета, и из ЛС. А вот с доступом из ЛС к внешним ресурсам - к ftp и еще только набирающим в те годы популярность http-серверам начались проблемы. Если раньше с любого компьютера можно было напрямую взаимодействовать с сервером, то теперь эта возможность осталась у компьютеров только с реальными интернет-адресами, т.к. в какую ЛС слать ответ на IP-пакет, у которого в обратном адресе стоит локальный - роутер определить не сможет.

Простейшее решение этой задачи - подмена обратного адреса на границе сетей - лежало на поверхности и не замедлило опубликоваться: в мае 1994 г., т.е. через два месяца после "раздела сетей" предложили спецификацию NAT: http://www.ietf.org/rfc/rfc1631.txt The Network Address Translator (NAT) May 1994 Авторы анонсировали это как "short-term solution", т.е. временное решение указанной проблемы, эдакий "хак", пока не получат распространение нормальные решения. Но, как известно, ничего не бывает столь постояным, как временное IPv6 вопреки ожиданиям быстро не прижился, и все прошедшие 10 лет мы были свидетелями все новых и новых боев на границах ЛС и интернета. NAT получил распространение, т.к. никакого другого приемлемого решения этой проблемы в те годы не было: FTP-клиенты и HTTP-клиенты (браузеры) не успели адаптироваться под под измененную картину мира, не могли работать из ЛС с внешними ресурсами, поэтому чтобы сделать для них границу прозрачной, их просто программно "обманывали" с помощью NAT - все IP-пакеты, адресованные из ЛС наружу, подвергались простейшей обработке на границе: замене обратного IP-адреса на реальный адрес "пограничного" компьютера, и обратной замене во входящих пакетах. Кроме того обычно заменялся и номер порта ЛС-источника, т.к. с разных машин в ЛС пакеты могут исходить с одними и теми же номерами портов. Т.е. транслируются не только IP-адреса, но и номера портов (иногда порт-трансляторы называют отдельной аббревиатурой PAT). В условной классификации NAT подразделяют на "статические, динамические и маскарадинг (masquerading)", но на практике применяется в основном третий тип, он позволяет через один реальный адрес обслуживать тысячи соединений из ЛС (в идеале), трансляция портов при этом используется всегда. На NAT-компьютере или роутере+NAT выделяется диапазон портов, используемых для трансляции, например с номерами больше 60000 (чтобы быстрее отличать эти порты от выделенных под собственные нужды этого компьютера) и динамическая таблица текущих сессий/отображений адресов. Каждый проходящий пакет сверяется с этой таблицей по и порту и производятся соответствующие подстановки. Технология настолько проста, что сейчас уже все реже можно встретить роутер или кабельный модем без встроенного NAT (и FireWall , столь же примитивного как NAT), причем NAT уже можно обнаружить даже в hub"ах c ценами от $40. Не говоря уж о "бесплатном" NAT, входящем в состав нескольких последних версий Windows под именем "connection sharing " и "совместное использование соединения ". Именно доступность, простота понимания/использования и нетребовательность к клиентскому софту, сделали NAT заслуженно популярным.

NAT "глазами" интернет-программ

Если бы на практике все было так просто, то было бы неинтересно Но, конечно, как бывает и с любым другим программным трюком, в NAT сразу же стали вылезать разнообразные неприятные побочные эффекты. На момент появления NAT одним из самых популярных протоколов был FTP, и именно этот протокол стал для NAT первым неперевариваемым протоколом. Это выявило проблему, которая так и не была хоть сколько нибудь успешно решена в NAT за эти 10 лет. И в общем случае она не может быть решена в рамках NAT, могут быть только подгонки под конкретные протоколы, но эти подгонки нельзя считать надежным решением. Проблема эта состоит в том, что в некоторых протоколах, среди которых старейшим является FTP, передается IP-адрес клиентской машины, и этот IP-адрес используется сервером для передачи данных клиенту. Поскольку в случае с NAT клиентская программа, работающая из ЛС "обманута" NAT"ом, она может передать серверу только свой собственный локальный IP-адрес, соединиться с которым внешний сервер не сможет из-за невидимости локальных сетей из интернета. Другими примерами могут служить протоколы ICQ, MS NetMeeting , RealAudio и многие другие протоколы, разработчики которых видимо сидели в сетях без
NAT NAT может предложить только одно решение такой проблемы - основываясь на номерах портов угадать конкретный транслируемый протокол и начать следить за содержимым IP-пакетов. Когда в них встречается FTP-команда PORT, в которой указывается :порт локального клиента (текстовая команда в теле пакета, а не в заголовке IP-пакета), то заменять не только заголовки, но весь пакет, с пересчетом контрольной суммы и организацией прослушки еще одного входящего порта. К сожалению для NAT, TCP-протокол, в котором передаются команды FTP-протокола, является поточным протоколом, организованным над - команда PORT при попадании на IP-уровень может оказаться разбитой на 2 пакета (а то и более, в зависимости от FTP-клиента и буферизации в ОС). Поэтому для надежного обнаружения места подмены NAT"у придется реконструировать исходный TCP-поток, буферизировать и пересобирать пакеты. К "реконструкции протоколов" в NAT мы еще вернемся, а пока просто отметим многоярусный уровень потенциальных ошибок и ненадежностей в этом процессе. На практике это приводит к тому, что стандартный режим FTP с использованием команды PORT через NAT как правило НЕ работает.

Поэтому "проблему NAT" в FTP-протоколе приходится обходить особым образом в FTP-клиентах или в еще одном промежуточном специализированном FTP-прокси. В FTP-клиенте для этого нужно переключиться в т.н. "пассивный режим" - использовать вместо команды PORT команду PASV. PASV просит FTP-сервер открыть дополнительный порт у себя и сообщить клиенту его :порт. Клиент после этого соединяется с указанным (NAT его еще раз обманывает-транслирует) и сессия удается. Кроме необходимости поддержки PASV-режима в FTP-клиенте (в стандартном ftp.exe её нет), при этом требуются и некоторые усилия со стороны администратора FTP-сервера - особенно если он тоже частично загорожен Firewall"ами и NAT"ами (как разработчик FTP-сервера для Eserv знаю эти проблемы не по наслышке). В общем, здесь NAT не помогает соединяться, а мешает.

Теперь о реконструкции протокола внутри NAT для "прозрачного" для клиента обхода проблемы. Те немногие NAT, которые это умеют (хотя на практике тоже скорее декларируют, чем умеют , фактически поднимаются на один сетевой уровень вверх - вместо простейшего форварда пакетов с трансляцией адресов в заголовке они начинают заниматься тем же, чем занимается TCP-стек - сборкой TCP-потока из пакетов. Таким образом они превращаются из переразвитого роутера в недоразвитый прикладной TCP-прокси. В данном случае в FTP-прокси или в FTP-гейт. Недоразвитый потому, что клиент не знает об этом прокси, а NAT в свою очередь продолжает угадывать протокол и заниматься задачей, которая неудобна для решения на его уровне (уровне IP-пакетов).

Намного проще эта задача решается, если вместо NAT или в дополнение к нему сразу использовать специализированный прокси (FTP gate) или универсальные TCP-прокси типа Socks или в крайнем случее httpS (этот крайний случай тем не менее сработает лучше чем NAT). Они изначально работают на TCP-уровне и не обманывают FTP-клиента, а сотрудничают с ним. Отпадают сразу три слоя проблем: FTP-клиент может использовать любой режим - активный или пассивный (в httpS только пассивный, как и в NAT), нет нужды угадывания протокола и двойной сборки TCP . Кроме того, у админа появляется больше возможностей влиять на процесс (об этом позже).

Если клиентская программа не умеет работать через спец-прокси (таких практически не осталось, но будем говорить о худших случаях), то при использовании Socks-прокси работу клиента также можно сделать прозрачной с помощью программ SocksCapture или отечественной FreeCap . Прозрачность границы - это всегда обман, но SocksCapture или FreeCap перехватывают не IP-пакеты, а обращения программы к ОС, поэтому они всегда точно знают, а не вычисляют по потоку пакетов, какое именно действие хочет совершить программа, и соответственно перенаправляют эти действия через Socks-прокси.

NAT vs Socks

Раз уж зашел разговор о Socks, надо сказать несколько слов об этом прокси-протоколе. Тем более что исторически Socks был следующим после NAT средством преодоления границы между ЛС и интернетом: первая обзорная статья "what is socks" была опубликована в октябре 1994 г., вскоре появилась спецификация Socks4 (предыдущие "версии" не применялись ни в каких продуктах) http://www.socks.nec.com/protocol/socks4a.protocol и только к 5й версии в марте 1996 года созрел для публикации в ietf в качестве RFC: http://www.ietf.org/rfc/rfc1928.txt. Есть русская версия этого документа - перевод выполнил Александр Горлач, который тогда (97й и 98гг) работал в нашей фирме и участвовал в создании Eserv /2, см. страницу Socks5.

Socks преодолел все ограничения NAT, плюс добавил как минимум три удобных средства, позволяющих не только "проксировать" практически любой TCP и UDP протокол, но и улучшить контроль над использованием интернета из ЛС:

1. Socks не только обслуживает исходящие соединения, но и позволяет создавать слушающие входящие сокеты на прокси-машине (метод BIND) по запросу прокси-клиента - это требуется как раз для FTP и подобных многосвязных протоколов.
2. Socks4a и Socks5 позволяют снять с клиента задачу разрешения доменных имен на клиенте, а делать это прямо в прокси. Т.е. машине внутри ЛС становится ненужным DNS-сервер или DNS-маппинг (через NAT или спец.UDPMAP), с админа снимается одна "галочка" его забот, плюс за счет кэширования DNS на сервере клиент работает быстрее.
3. Socks5 поддерживает различные варианты явной аутентификации и авторизации клиента. В NAT можно было отличать своих от чужих только по .

Но Socks хоть и повысил удобство работы по сравнению с NAT, остается универсальным "программируемым маппингом". Часть проблем NAT осталось в нем нерешенными. И они не могут быть решены на низком уровне без вникания в детали конкретного проксируемого протокола. Так же как, например, телефон способен передать человеческую речь, но не способен её понять и отфильтровать брань Поэтому те администраторы, которые хотят полного контроля над происходящим в его сети, используют специализированные прокси.

NAT и специализированные прокси глазами сисадмина

Сначала опять небольшой экскурс в историю. Протокол HTTP был разработан в начале 90х (так называемая "версия 0.9"), и к середине 90х стал "killer app" интернета - тем, ради чего к интернету стали подключаться не только ученые и военные, но и "простые коммерсанты и обыватели". Соответственно назрела необходимость стандартизации. В мае 1996 года была выпущена спецификация HTTP/1.0 под знаменательным-победоносным номером RFC:1945. Авторы спецификации уже принимали во внимание новые реалии интернета, в т.ч. необходимость проксирования протокола для ЛС. К тому же на практике HTTP существовал уже не первый год и "опыт проксирования" имел. Поэтому в документе были сделаны необходимые определения и замечания о прокси, шлюзах и туннелях. И фактически там был определен не только сам HTTP-протокол (с точки зрения обычного веб-сервера), но и описаны протоколы HTTP-proxy и HTTPS-proxy. Метод "CONNECT", введенный в протокол HTTP специально для обеспечения возможности соединения с secure HTTP-серверами через прокси, тем не менее позволял не ограничиваться 443м портом, а указывать любой порт для соединения. Таким образом в лице HTTPS прокси мы получаем еще один "программируемый TCP-маппинг" для любого протокола, хотя и с намного более ограниченными возможностями, чем Socks5. Совсем другое дело HTTP proxy для "родного" ему HTTP-протокола. Его он может обрабатывать с полным знанием дела - кэшировать, фильтровать по URL и контенту, ограничивать, маршрутизировать, авторизовать, и т.д. Часто эти действия требуют таких нетривиальных действий на уровне TCP и других компонентов ОС, что практически невозможны на пакетном уровне NAT или слепом отображении Socks.

То же самое с любым другим прикладным протоколом, для которого существуют специализированные прокси - они всегда на порядок более управляемые, чем универсальные низкоуровневые. Например, многие POP3-прокси позволяют фильтровать спам, например PopFile (хотя намного более правильно фильтровать спам не на прокси, а на SMTP-сервере). Socks и NAT для этого потребовались бы особые умения по вниканию в передаваемый протокол, т.е. фактически "эмуляция" POP3-прокси не слишком удобными для этого средствами.

Поэтому использование Socks или NAT для работы с теми протоколами, для которых существуют специализированные прокси (HTTP, HTTPS, FTP, SMTP, POP3, IMAP) или общепринятая архитектура промежуточных серверов (SMTP, POP3, IMAP, DNS) можно считать вынужденным неоптимальным решением. Вынужденным - либо от невозможности использования нужного типа прокси по организационным причинам (некуда поставить нужный вид прокси, или тип подключения не предусматривает наличия ни одного реального IP-адреса, как в случае с интернетом через GPRS или вариантов домовых сетей - в этих случаях NAT или "принудительный HTTP-прокси" уже стоят на стороне провайдера), либо от недостаточной информированности ответственных лиц, в т.ч. админов. Финансовые ограничения не принимаю во внимание, т.к. существует масса вариантов бесплатных или очень дешевых прокси для всех этих протоколов.

В некоторых случаях использование Socks5 вполне оправдано - например, для ICQ и других месенжеров. Для этих протоколов спец-прокси просто не разрабатываются, т.к. они почти незаметны на общем фоне использования сети. При отсутствии в ЛС почтового сервера или pop3/smtp-прокси следующим кандидатом будет также Socks5, хотя его поддержка есть не во всех почтовых клиентах, а в некоторых имеет неочевидные особенности (см. Mozilla ThunderBird).

При переборе вариантов NAT будет "последней инстанцией" - на случай, если не нашлось ничего лучше, или если NAT поставлен провайдером изначально - в кабельном модеме, маршрутизаторе, мобильном подключении (в эти железки ставится именно NAT, а не спец-прокси для популярных протоколов, благодаря предельной простоте его базовой реализации: исходник аналогичного по устройству NAT UDPMAP plugin в Eproxy имеет размер всего 4Кб). Часть протоколов работать не будет, управлять работой будет сложно. Но в таких предельных случаях лучше хоть как-то работать, чем вообще не работать

Вот такое развернутое пояснение к известной моей позиции последних 8 лет - "в Eserv никогда не будет NAT" В подавляющем большинстве случаев NAT либо вам не нужен, либо он у вас уже есть в качестве наказания за выбор провайдера А для ознакомления с NAT можно использовать встроенный в Windows connection sharing, он работает именно как NAT.

См. также "костыль" для NAT на сайте Microsoft: NAT traversal - преодоление NAT путем адаптации приложений , конфигурация NAT/Firewall через UPnP . Если словосочетание NAT traversal вы слышите впервые, то это потому что разработчики предпочитают Socks5 вместо костылей к патчам, и эта инициатива не получила "поддержки кодом". Но статья хороша своими картинками (в отличие от моей и еще одним независимым описанием проблем NAT.

NAT, ICS уже встроен во все новые версии Windows

Во всех версиях Windows, выпущенных с 1999 года, NAT входит в комплект. Сначала под именем ICS (Internet Connection Sharing - общий доступ к соединению), а позже уже под своими именем NAT. Вот диалог включения NAT в Windows 2003 (через "Маршрутизацию и удаленный доступ" system32rrasmgmt.msc).

В Windows XP NAT/ICS включается в свойствах интернет-соединения.

Если выдается сообщение "Не удается разрешить общий доступ. Ошибка: 1722: Сервер RPC недоступен." ("Cannot enable shared access. Error: 1722: The RPC server is not available."), то скорее всего у вас остановлен или запрещен сервис DHCP-клиент, нужно его запустить до включения ICS.

NAT глазами сисадмина провайдерских Linux

(Добавление от 6 июля 2004 - первый отклик на статью. Как и в статье про FireWall , предоставим слово настоящему сисадмину

Цитата Если сравнивать работу через NAT с реальным , то пока проблемы с NAT у меня были только с голосом, видео и передачей файлов в программах типа MSN Messenger. Возможно в каких-то реализациях NAT"а есть также проблемы с активным ftp, соединением с внешними VPN-серверами и т.п., но при работе через NAT в Linux"е (при соответсвующих настройках) с этим проблем нет. Преимущество NAT в данном случае в экономии IP-адресов и файрволе.

Если сравнивать NAT с прокси (как способ выхода в Интернет, т.е. перенаправление запросов, не рассматривая функции кэширования, анализа URL и т.п.), то через NAT работает больше приложений и протоколов (все ); для NAT не требуется специальных настроек со стороны пользователя; прокси более требователен к оборудованию. Прокси обычно не обеспечивают функциональности Destination NAT (DNAT), хотя в Есерве у тебя частичного подобия DNAT можно добиться с помощью tcp/udp-маппинга. Конец цитаты.

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

BackLinks
Articles
FireWall
MxServer
NCSI
WhatIsProxyServer

Интернет -маршрутизатором, сервером доступа, межсетевым экраном. Наиболее популярным является Source NAT (SNAT), суть механизма которого состоит в замене адреса источника (source) при прохождении пакета в одну сторону и обратной замене адреса назначения ( destination ) в ответном пакете. Наряду с адресами источника/назначения могут также заменяться номера портов источника и назначения.

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

На рисунках ниже приведен пример действия механизма NAT .

Рис. 7.1.

Пользователь корпоративной сети отправляет запрос в Интернет , который поступает на внутренний интерфейс маршрутизатора, сервер доступа или межсетевого экрана (устройство NAT ).

Устройство NAT получает пакет и делает запись в таблице отслеживания соединений, которая управляет преобразованием адресов.

Затем подменяет адрес источника пакета собственным внешним общедоступным IP-адресом и посылает пакет по месту назначения в Интернет .

Узел назначения получает пакет и передает ответ обратно устройству NAT .

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

Существует 3 базовых концепции трансляции адресов:

• статическая (SAT, Static Network Address Translation),
• динамическая (DAT, Dynamic Address Translation),
• маскарадная (NAPT, NAT Overload, PAT).

Статический NAT отображает локальные IP-адреса на конкретные публичные адреса на основании один к одному. Применяется, когда локальный хост должен быть доступен извне с использованием фиксированных адресов.

Динамический NAT отображает набор частных адресов на некое множество публичных IP-адресов. Если число локальных хостов не превышает число имеющихся публичных адресов, каждому локальному адресу будет гарантироваться соответствие публичного адреса. В противном случае, число хостов, которые могут одновременно получить доступ во внешние сети, будет ограничено количеством публичных адресов.

Маскарадный NAT (NAPT, NAT Overload , PAT , маскарадинг) – форма динамического NAT , который отображает несколько частных адресов в единственный публичный IP- адрес , используя различные порты. Известен также как PAT ( Port Address Translation ).

Механизмов взаимодействия внутренней локальной сети с внешней общедоступной сетью может быть несколько – это зависит от конкретной задачи по обеспечению доступа во внешнюю сеть и обратно и прописывается определенными правилами. Определены 4 типа трансляции сетевых адресов:

• Full Cone (Полный конус)
• Restricted Cone (Ограниченный конус)
• Port Restricted Cone (Порт ограниченного конуса)
• Symmetric (Симметричный)

В первых трех типах NAT для взаимодействия разных IP-адресов внешней сети с адресами из локальной сети используется один и тот же внешний порт . Четвертый тип – симметричный – для каждого адреса и порта использует отдельный внешний порт .

Full Cone , внешний порт устройства (маршрутизатора, сервера доступа, межсетевого экрана) открыт для приходящих с любых адресов запросов. Если пользователю из Интернета нужно отправить пакет клиенту, расположенному за NAT ’ом, то ему необходимо знать только внешний порт устройства, через который установлено соединение. Например, компьютер за NAT ’ом с IP-адресом 192.168.0.4 посылает и получает пакеты через порт 8000, которые отображаются на внешний IP- адрес и порт , как 10.1.1.1:12345. Пакеты из внешней сети приходят на устройство с IP-адресом:портом 10.1.1.1:12345 и далее отправляются на клиентский компьютер 192.168.0.4:8000.

Во входящих пакетах проверяется только транспортный протокол; адрес и порт назначения, адрес и порт источника значения не имеют.

При использовании NAT , работающему по типу Restricted Cone , внешний порт устройства (маршрутизатора, сервера доступа, межсетевого экрана) открыт для любого пакета, посланного с клиентского компьютера, в нашем примере: 192.168.0.4:8000. А пакет, пришедший из внешней сети (например, от компьютера 172.16.0.5:4000) на устройство с адресом:портом 10.1.1.1:12345, будет отправлен на компьютер 192.168.0.4:8000 только в том случае, если 192.168.0.4:8000 предварительно посылал запрос на IP- адрес внешнего хоста (в нашем случае – на компьютер 172.16.0.5:4000). То есть, маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае компьютер 172.16.0.5:4000), но номер порта источника при этом может быть любым. В противном случае, NAT блокирует пакеты, пришедшие с хостов, на которые 192.168.0.4:8000 не отправлял запроса.

Механизм NAT Port Restricted Cone почти аналогичен механизму NAT Restricted Cone. Только в данном случае NAT блокирует все пакеты, пришедшие с хостов, на которые клиентский компьютер 192.168.0.4:8000 не отправлял запроса по какому-либо IP-адресу и порту. Mаршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом должен быть 4000. Если клиент отправил запросы во внешнюю сеть к нескольким IP-адресам и портам, то они смогут посылать пакеты клиенту на IP- адрес : порт 10.1.1.1:12345.

Symmetric NAT существенно отличается от первых трех механизмов способом отображения внутреннего IP-адреса:порта на внешний адрес : порт . Это отображение зависит от IP-адреса:порта компьютера, которому предназначен посланный запрос . Например, если клиентский компьютер 192.168.0.4:8000 посылает запрос компьютеру №1 (172.16.0.5:4000), то он может быть отображен как 10.1.1.1:12345, в тоже время, если он посылает с того же самого порта (192.168.0.4:8000) на другой IP- адрес , он отображается по-другому (10.1.1.1:12346).

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

Позволяет скрыть определённые внутренние сервисы внутренних хостов/серверов. По сути, выполняется та же указанная выше трансляция на определённый порт, но возможно подменить внутренний порт официально зарегистрированной службы (например, 80-й порт TCP (HTTP-сервер) на внешний 54055-й). Тем самым, снаружи, на внешнем IP-адресе после трансляции адресов на сайт (или форум) для осведомлённых посетителей можно будет попасть по адресу http://dlink.ru:54055 , но на внутреннем сервере, находящимся за NAT, он будет работать на обычном 80-м порту.

Однако следует упомянуть и о недостатках данной технологии:

1. Не все протоколы могут "преодолеть" NAT. Некоторые не в состоянии работать, если на пути между взаимодействующими хостами есть трансляция адресов. Опеределенные межсетевые экраны, осуществляющие трансляцию IP-адресов, могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не только в заголовках IP, но и на более высоких уровнях (например, в командах протокола FTP).
2. Из-за трансляции адресов "много в один" появляются дополнительные сложности с идентификацией пользователей и необходимость хранить полные логи трансляций.
3. Атака DoS со стороны узла, осуществляющего NAT – если NAT используется для подключения многих пользователей к одному и тому же сервису, это может вызвать иллюзию DoS-атаки на сервис (множество успешных и неуспешных попыток). Например, избыточное количество пользователей ICQ за NAT приводит к проблеме с подключением к серверу некоторых пользователей из-за превышения допустимой скорости подключений.