Количества публичных IPv4-адресов недостаточно, чтобы назначить уникальные адреса всем устройствам, подключённым к Интернету. В большинстве случаев, сети реализуются с использованием частных IPv4-адресов в соответствии с RFC 1918. На рис. 1 показан диапазон адресов, включённых в RFC 1918. Вероятнее всего, компьютеру, на котором вы сейчас просматриваете материал учебного курса, назначен частный адрес.

Эти частные адреса используются в рамках организации или объекта с целью обеспечения взаимодействия устройств на локальном уровне. Но поскольку эти адреса не определяют конкретную компанию или организацию, частные IPv4-адреса нельзя использовать для маршрутизации через Интернет. Для того, чтобы разрешить устройству с частным IPv4-адресом доступ к устройствам и ресурсам вне локальной сети, частный адрес сначала необходимо преобразовать в публичный адрес.

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

Без использования NAT адресное пространство IPv4 было бы исчерпано задолго до наступления 2000 года. Несмотря на свои преимущества, NAT имеет ряд ограничений, которые будут подробно рассматриваться далее в этой главе. Решением проблемы исчерпания пространства IPv4-адресов и ограничений NAT является окончательный переход на IPv6.

Характеристики NAT

Преобразование сетевых адресов NAT используется в различных целях, однако основной задачей данного механизма является сохранение публичных IPv4-адресов. Это достигается путём разрешения сетям использовать частные IPv4-адреса для внутреннего взаимодействия и преобразования их в публичные адреса только в случае необходимости. Дополнительное преимущество NAT - повышение степени конфиденциальности и безопасности сети - объясняется тем, что данный механизм скрывает внутренние IPv4-адреса от внешних сетей.

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

Маршрутизатор NAT обычно работает на границе тупиковой сети. Тупиковая сеть - это сеть, использующая единственное соединение с соседней сетью, один входящий маршрут и один исходящий маршрут. В примере, показанном на рисунке, R2 является пограничным маршрутизатором. С точки зрения интернет-провайдера, маршрутизатор R2 создаёт тупиковую сеть.

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

Примечание . Подключение к сети интернет-провайдера может также использовать частный адрес или публичный адрес, совместно используемый клиентами поставщика. В рамках рассматриваемой темы в качестве примера приведён публичный адрес.

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

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

В NAT предусмотрено 4 типа адресов:

• внутренний локальный адрес;

• внутренний глобальный адрес;

• внешний локальный адрес;

• внешний глобальный адрес.

При определении используемого типа адреса важно помнить, что терминология NAT всегда применяется с точки зрения устройства с преобразуемым адресом:

• Внутренний адрес - это адрес устройства, преобразуемый механизмом NAT.

• Внешний адрес - это адрес устройства назначения.

В рамках NAT по отношению к адресам также используется понятие локальности или глобальности:

• Локальный адрес - это любой адрес, появляющийся во внутренней части сети.

• Глобальный адрес - это любой адрес, появляющийся во внешней части сети.

На рисунке внутренним локальным адресом PC1 является 192.168.10.10. С точки зрения PC1 веб-сервер использует внешний адрес 209.165.201.1. Когда пакеты отправляются из PC1 по глобальному адресу веб-сервера, внутренний локальный адрес PC1 преобразуется в 209.165.200.226 (внутренний глобальный адрес). Адрес внешнего устройства обычно не преобразуется, так как этот адрес обычно уже является публичным IPv4-адресом.

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

Маршрутизатор NAT (R2 на рисунке) представляет собой точку разграничения между внутренней и внешней сетями, а также между локальными и глобальными адресами.

Термины «внутренний» и «внешний» используются в сочетании с терминами «локальный» и «глобальный», когда речь идёт о конкретных адресах. На рисунке маршрутизатор R2 настроен на использование механизма NAT. Он использует пул публичных адресов, назначаемых внутренним узлам.

• Внутренний локальный адрес - это адрес источника, видимый из внутренней сети. На рисунке PC1 назначен IPv4-адрес 192.168.10.10. Это внутренний локальный адрес PC1.

• Внутренний глобальный адрес - это адрес источника, видимый из внешней сети. На рисунке, когда PC1 отправляет трафик веб-серверу с адресом 209.165.201.1, R2 преобразует внутренний локальный адрес во внутренний глобальный адрес. В этом случае R2 меняет исходный IPv4-адрес с 192.168.10.10 на 209.165.200.226. В терминологии NAT, внутренний локальный адрес 192.168.10.10 преобразуется во внутренний глобальный адрес 209.165.200.226.

• Внешний глобальный адрес - это адрес назначения, видимый из внешней сети. Это глобально маршрутизируемый IPv4-адрес, назначенный узлу в Интернете. Например, веб-сервер доступен по IPv4-адресу 209.165.201.1. В большинстве случаев внешний локальный и внешний глобальный адреса совпадают.

• Внешний локальный адрес - это адрес назначения, видимый из внутренней сети. В этом примере PC1 отправляет трафик веб-серверу с IPv4-адресом 209.165.201.1. В редких случаях этот адрес может отличаться от глобально маршрутизируемого адреса назначения.

На рисунке показано, как адресуется трафик, отправленный внутренним компьютером внешнему веб-серверу через маршрутизатор с поддержкой NAT. Также показано, как первоначально адресуется и преобразуется обратный трафик.

Примечание . Использование внешнего локального адреса не рассматривается в материале данного учебного курса.

Типы преобразования сетевых адресов NAT

Существуют три механизма преобразования сетевых адресов:

• Статическое преобразование сетевых адресов (статический NAT) - это взаимно-однозначное соответствие между локальным и глобальным адресами.

• Динамическое преобразование сетевых адресов (динамический NAT) - это сопоставление адресов по схеме «многие ко многим» между локальными и глобальными адресами.

• Преобразование адресов портов (PAT) - это сопоставление адресов по схеме «многие к одному» между локальными и глобальным адресами. Данный метод также называется перегрузкой (NAT с перегрузкой).

Статическое преобразование сетевых адресов (NAT)

Статический NAT использует сопоставление локальных и глобальных адресов по схеме «один в один». Эти соответствия задаются администратором сети и остаются неизменными.

На рисунке для маршрутизатора R2 настроены статические соответствия для внутренних локальных адресов Svr1, PC2 и PC3. Когда эти устройства отправляют трафик в Интернет, их внутренние локальные адреса преобразуются в заданные внутренние глобальные адреса. Для внешних сетей эти устройства используют публичные IPv4-адреса.

Метод статического преобразования сетевых адресов особенно полезен для веб-серверов или устройств, которые должны иметь постоянный адрес, доступный из Интернета - например, для веб-сервера компании. Статический NAT также подходит для устройств, которые должны быть доступны авторизованному персоналу, работающему вне офиса, но при этом оставаться закрытыми для общего доступа через Интернет. Например, сетевой администратор может с PC4 подключиться с помощью SSH к внутреннему глобальному адресу Svr1 (209.165.200.226). Маршрутизатор R2 преобразует этот внутренний глобальный адрес во внутренний локальный адрес и подключает сеанс администратора к Svr1.

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

Динамическое преобразование адресов NAT

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

На рисунке PC3 получает доступ к Интернету, используя первый доступный адрес в пуле динамического NAT. Другие адреса по-прежнему доступны для использования. Аналогично статическому NAT, для динамического NAT требуется достаточное количество публичных адресов, способное обеспечить общее количество одновременных сеансов пользователей.

Преобразование адресов портов (PAT)

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

С помощью данного метода множество адресов могут быть сопоставлены одному или нескольким адресам, поскольку каждый частный адрес также отслеживаются по номеру порта. Если устройство начинает сеанс TCP/IP, оно создаёт значение порта TCP или UDP для источника, чтобы уникальным образом определить сеанс. Когда маршрутизатор NAT получает пакет от клиента, он использует свой номер порта источника, чтобы уникальным образом определить конкретное преобразование NAT.

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

Для управления анимацией используйте кнопки «Воспроизведение» и «Пауза» на рисунке.

Анимация иллюстрирует процесс преобразования адресов портов (PAT). Для того, чтобы различать преобразования, механизм PAT добавляет уникальные номера портов источника к внутреннему глобальному адресу.

Поскольку маршрутизатор R2 обрабатывает каждый пакет, он использует номер порта (в рассматриваемом примере 1331 и 1555) для идентификации устройства, с которого поступил пакет. Адрес источника (SA) - это внутренний локальный адрес с добавленным назначенным номером порта TCP/IP. Адрес назначения (DA) - это внешний локальный адрес с добавленным номером порта службы. В данном примере порт службы равен 80: HTTP.

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

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

Преобразование PAT пытается сохранить оригинальный порт источника. В том случае, если оригинальный порт источника уже используется, PAT назначает первый доступный номер порта, начиная с начала соответствующей группы портов - 0-511, 512-1023 или 1024-65535. Если доступных портов больше нет, а в пуле адресов есть несколько внешних адресов, PAT переходит к следующему адресу, пытаясь выделить оригинальный порт источника. Данный процесс продолжается до тех пор, пока не исчерпаются как доступные порты, так и внешние IP-адреса.

Для ознакомления с принципом работы PAT нажмите кнопку «Воспроизведение» на рисунке.

В анимации узлы выбирают один и тот же номер порта - 1444. Это допустимо для внутреннего адреса, поскольку узлам назначены уникальные частные IP-адреса. Но на маршрутизаторе с поддержкой NAT номера портов необходимо изменить. В противном случае пакеты от двух различных узлов выходили бы из R2 с одинаковым адресом источника. В рассматриваемом примере в процессе преобразования PAT второму адресу узла назначается следующий доступный порт (1445).

Сравнение NAT и PAT

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

Как показано на рисунке, NAT преобразует IPv4-адреса, исходя из схемы 1:1 для частных IPv4-адресов и публичных IPv4-адресов. В то же время, PAT меняет и адрес, и номер порта.

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

Пакеты без сегмента уровня 4

Что же происходит с пакетами IPv4, передающими данные, не являющиеся сегментом TCP или UDP? Данные пакеты не содержат номера порта уровня 4. PAT преобразует большинство основных протоколов, передаваемых с помощью IPv4 и не использующих TCP или UDP, в протокол транспортного уровня. Самым распространённым среди таких протоколов является протокол ICMPv4. Процесс преобразования PAT обрабатывает каждый из этих протоколов по-разному. Например, сообщения запросов ICMPv4, эхо-запросы и эхо-ответы содержат идентификатор запроса (Query ID). ICMPv4 использует идентификатор запроса (Query ID), чтобы определить эхо-запрос с соответствующим эхо-ответом. Идентификатор запроса увеличивается с каждым отправленным эхо-запросом. PAT использует идентификатор запроса вместо номера порта уровня 4.

Примечание . Другие сообщения ICMPv4 не используют идентификатор запроса (Query ID). Эти сообщения и другие протоколы, не использующие номера портов TCP и UDP, могут отличаться друг от друга и не рассматриваются в рамках материала настоящего учебного курса.

Настройка NAT

Настройка статического NAT

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

На рис. 1 показана внутренняя сеть, содержащая веб-сервер с частным IPv4-адресом. На маршрутизаторе R2 настроен статический NAT, чтобы предоставить доступ к веб-серверу устройствам из внешней сети (Интернет). Клиент из внешней сети обращается к веб-серверу, используя публичный IPv4-адрес. Статический NAT преобразует публичный IPv4-адрес в частный IPv4-адрес.

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

Шаг 1. Первой задачей является создание соответствия между внутренним локальным и внутренним глобальным адресами. Например, на рис. 1 в качестве статического преобразования NAT настроены внутренний локальный адрес 192.168.10.254 и внутренний глобальный адрес 209.165.201.5.

Шаг 2. После настройки соответствия интерфейсы, участвующие в преобразовании, настраиваются как внутренние или внешние относительно NAT. В этом примере интерфейс Serial 0/0/0 маршрутизатора R2 является внутренним, а Serial 0/1/0 - внешним интерфейсом.

Пакеты, поступающие на внутренний интерфейс маршрутизатора R2 (Serial 0/0/0) от настроенного внутреннего локального IPv4-адреса (192.168.10.254) преобразуются, а затем передаются во внешнюю сеть. Пакеты, поступающие на внешний интерфейс маршрутизатора R2 (Serial 0/1/0), адресованные настроенному внутреннему глобальному IPv4-адресу (209.165.201.5), преобразуются к внутреннему локальному адресу (192.168.10.254) и затем передаются во внутреннюю сеть.

На рис. 2 приведены команды, необходимые для настройки статического NAT.

На рис. 3 показаны команды, необходимые для создания на маршрутизаторе R2 статического сопоставления NAT для веб-сервера в справочной топологии. В рамках показанной конфигурации R2 преобразует в пакетах, отправленных веб-сервером, адрес 192.168.10.254 в публичный IPv4-адрес 209.165.201.5. Интернет-клиент направляет веб-запросы на публичный IPv4-адрес 209.165.201.5. Маршрутизатор R2 пересылает этот трафик веб-серверу по адресу 192.168.10.254.

Используйте средство проверки синтаксиса (см. рис. 4) для настройки дополнительной записи статического преобразования NAT на маршрутизаторе R2.

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

1. Клиенту нужно подключиться к веб-серверу. Клиент передает пакет на веб-сервер, используя публичный IPv4-адрес назначения 209.165.201.5. Это внутренний глобальный адрес веб-сервера.

2. Первый пакет, который маршрутизатор R2 получает от клиента на свой внешний интерфейс NAT, заставляет R2 проверить свою таблицу NAT. IPv4-адрес назначения находится в таблице NAT, и маршрутизатор выполняет соответствующее преобразование.

3. R2 заменяет внутренний глобальный адрес 209.165.201.5 внутренним локальным адресом 192.168.10.254. Затем R2 пересылает пакет веб-серверу.

4. Веб-сервер получает пакет и отвечает клиенту, используя внутренний локальный адрес 192.168.10.254.

5а. R2 получает пакет от веб-сервера на свой внутренний интерфейс NAT с адресом источника, соответствующим внутреннему локальному адресу веб-сервера, 192.168.10.254.

5b. R2 проверяет таблицу NAT на предмет наличия преобразования для внутреннего локального адреса. Этот адрес присутствует в таблице NAT. R2 выполняет обратное преобразование адреса источника во внутренний глобальный адрес 209.165.201.5 и пересылает пакет клиенту через свой интерфейс Serial 0/1/0.

6. Клиент получает пакет и продолжает диалог. Маршрутизатор NAT выполняет шаги 2-5b для каждого пакета (шаг 6 на рисунке не показан).

Проверка статического NAT

Для проверки работы NAT используется команда show ip nat translations . Эта команда отображает активные преобразования NAT. В отличие от динамических преобразований, статические преобразования всегда присутствуют в таблице NAT. На рис. 1 показан результат этой команды для предыдущего примера конфигурации. Поскольку в примере приводится статическая конфигурация, преобразование всегда присутствует в таблице NAT независимо от активных взаимодействий. Если команда вводится во время активного сеанса, выходные данные будут также содержать адрес внешнего устройства, как показано на рис. 1.

Другой полезной командой являетсяshow ip nat statistics . Как показано на рис. 2, команда show ip nat statistics

Чтобы убедиться в правильности работы преобразования NAT, перед тестированием рекомендуется очистить статистику всех предыдущих преобразований с помощью командыclear ip nat statistics .

До начала взаимодействия с веб-сервером команда show ip nat statistics не должна показывать каких-либо совпадений. После установки клиентом сеанса с веб-сервером результат команды show ip nat statistics покажет увеличение количества совпадений до 5. Это подтверждает выполнение статического преобразования NAT на R2.

Настройка динамического NAT

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

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

Примечание . Преобразование между публичными и частными IPv4-адресами является самым распространённым применением NAT. Тем не менее, преобразования NAT могут возникать между любыми парами адресов.

В справочной топологии, показанной на рисунке, внутренняя сеть использует адреса из пространства частных адресов, определённого в RFC 1918. К маршрутизатору R1 подключены две локальных сети - 192.168.10.0/24 и 192.168.11.0/24. Пограничный маршрутизатор R2 настроен на динамическое преобразование NAT с использованием пула публичных IPv4-адресов от 209.165.200.226 до 209.165.200.240.

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

На рис. показаны шаги и команды, используемые для настройки динамического NAT.

Шаг 1. С помощью команды ip nat pool задайте пул адресов, которые будут использоваться для преобразования. Данный пул адресов обычно является группой публичных адресов. Эти адреса определяются с помощью указания начального и конечного IP-адресов пула. Ключевое слово netmask или prefix-length указывает, какие биты адреса относятся к сети, а какие - к диапазону адресов узлов.

Шаг 2. Настройте стандартный ACL-список, чтобы определить (разрешить) только те адреса, которые должны быть преобразованы. ACL-список со слишком большим количеством разрешающих команд может привести к непредсказуемым результатам. Помните, что в конце каждого ACL-списка находится строка deny all .

Шаг 3. Выполните привязку ACL-списка к пулу. Команда ip nat inside source list access-list-number number pool pool name используется для привязки списка к пулу. Эта конфигурация используется маршрутизатором, чтобы определить, какие устройства (list ) получают какие адреса (pool ).

Шаг 4. Определите интерфейсы, являющиеся внутренними по отношению к NAT, т.е. любой интерфейс, подключенный к внутренней сети.

Шаг 5. Определите интерфейсы, являющиеся внешними относительно NAT, т.е. любой интерфейс, подключенный к внешней сети.

На рис. 2 приведен пример топологии и соответствующая конфигурация. Данная конфигурация разрешает преобразование для всех узлов сети 192.168.0.0/16, содержащей локальные сети 192.168.10.0 и 192.168.11.0, когда узлы создают трафик, входящий в S0/0/0 и выходящий из S0/1/0. Адреса этих узлов преобразуются в доступный адрес из пула в диапазоне от 209.165.200.226 до 209.165.200.240.

На рис. 3 показана топология, используемая для конфигурации инструмента проверки синтаксиса. Используйте инструмент проверки синтаксиса на рис. 4, чтобы настроить динамическое преобразование NAT на маршрутизаторе R2.

Анализ динамического NAT

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

На рис. 1 показан поток трафика изнутри наружу.

1. Узлы с IPv4-адресами источника (192.168.10.10 (PC1) и 192.168.11.10 (PC2)) отправляют пакеты, запрашивающие подключение к серверу на публичный IPv4-адрес (209.165.200.254).

2. Маршрутизатор R2 получает первый пакет от узла 192.168.10.10. Поскольку этот пакет был получен на интерфейс, настроенный как внутренний интерфейс NAT, R2 проверяет конфигурацию NAT, чтобы определить, следует ли выполнять преобразование для данного пакета. ACL-список разрешает этот пакет, поэтому R2 выполняет его преобразование. Маршрутизатор R2 проверяет свою таблицу NAT. Поскольку для данного IP-адреса нет записей преобразования, R2 решает, что для адреса источника 192.168.10.10 требуется динамическое преобразование. Маршрутизатор R2 выбирает доступный глобальный адрес из пула динамических адресов и создает запись преобразования - 209.165.200.226. Первоначальный IPv4-адрес источника (192.168.10.10) - это внутренний локальный адрес, а используемый для преобразования адрес - это внутренний глобальный адрес (209.165.200.226) в таблице NAT.

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

3. R2 заменяет внутренний локальный адрес источника PC1 (192.168.10.10) используемым для преобразования внутренним глобальным адресом (209.165.200.226) и пересылает пакет. Те же действия выполняются для пакета, отправленного PC2, с использованием для преобразования адресом, соответствующим PC2 (209.165.200.227).

Рис 1

На рис. 2 показан поток трафика снаружи вовнутрь.

4. Сервер получает пакет от PC1 и отвечает, используя IPv4-адрес назначения 209.165.200.226. Получив второй пакет, сервер отвечает PC2, используя IPv4-адрес назначения 209.165.200.227.

5а. Получив пакет с IPv4-адресом назначения 209.165.200.226, маршрутизатор R2 выполняет поиск в таблице NAT. С помощью сопоставления из таблицы маршрутизатор R2 выполняет преобразование адреса обратно во внутренний локальный адрес (192.168.10.10) и пересылает пакет PC1.

5b. Получив пакет с IPv4-адресом назначения 209.165.200.227, маршрутизатор R2 выполняет поиск в таблице NAT. С помощью сопоставления из таблицы маршрутизатор R2 выполняет преобразование адреса обратно во внутренний локальный адрес (192.168.11.10) и пересылает пакет PC2.

6. PC1 с адресом 192.168.10.10 и PC2 с адресом 192.168.11.10 получают пакеты и продолжают диалог. Маршрутизатор NAT выполняет шаги 2-5b для каждого пакета (шаг 6 не приводится на рисунках).

Рис 2

Проверка динамического NAT

Результаты команды show ip nat translations , показанные на рис. 1, содержат сведения о двух предыдущих назначениях NAT. Команда отображает все настроенные статические преобразования адресов и все динамические преобразования, созданные в результате обработки трафика.

Добавление ключевого слова verbose выводит дополнительную информацию о каждом преобразовании, включая время, прошедшее после создания и использования записи.

По умолчанию срок действия записей преобразования истекает через 24 часа, если настройка таймеров не была изменена с помощью команды ip nat translation timeout timeout-seconds в режиме глобальной конфигурации.

Для удаления динамических записей до истечения их времени действия используйте команду режима глобальной конфигурации clear ip nat translation . При проведении проверки конфигурации NAT рекомендуется удалять динамические записи. Как показано в таблице, эту команду можно использовать с ключевыми словами и переменными, чтобы определить удаляемые записи. Конкретные записи можно удалить во избежание сбоев активных сеансов. Чтобы удалить из таблицы все преобразования, используйте команду глобальной конфигурации clear ip nat translation * .

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

Как показано, команда show ip nat statistics выводит сведения о суммарном количестве активных преобразований, параметрах конфигурации NAT, числе адресов в пуле и числе выделенных адресов.

В качестве альтернативы, можно воспользоваться командой show running-config и найти команды NAT, ACL, интерфейса или пула с нужными значениями. Внимательно изучите результаты и исправьте все обнаруженные ошибки.

Настройка преобразования адресов портов (PAT)

Преобразование адресов портов PAT (также называемое NAT с перегрузкой) экономит адреса во внутреннем глобальном пуле, разрешая маршрутизатору использовать один внутренний глобальный адрес для нескольких внутренних локальных адресов. Другими словами, один публичный IPv4-адрес может использоваться для сотен или даже тысяч внутренних IPv4-частных адресов. Если настроен данный тип преобразования, маршрутизатор хранит достаточный объём информации протоколов более высоких уровней, например, номера портов TCP или UDP, для обратного преобразования внутреннего глобального адреса в нужный внутренний локальный адрес. При привязке нескольких внутренних локальных адресов к одному внутреннему глобальному адресу для различения локальных адресов используются номера портов TCP или UDP.

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

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

Настройка PAT для пула публичных IP-адресов

Если объекту было выделено несколько публичных IPv4-адресов, то эти адреса могут быть частью пула, используемого PAT. Это аналогично динамическому NAT, за исключением того, что публичных адресов недостаточно для создания взаимно-однозначных соответствий внутренних и внешних адресов. Небольшой пул адресов совместно используется большим числом устройств.

На рис. 1 показаны шаги по настройке PAT для использования пула адресов. Основное различие между данной конфигурацией и конфигурацией для динамического взаимно-однозначного NAT состоит в использовании ключевого слова overload . Ключевое словоoverload задействует работу PAT.

Пример конфигурации, показанной на рис. 2, создаёт преобразование с перегрузкой для пула NAT с именем NAT-POOL2. NAT-POOL2 содержит адреса с 209.165.200.226 по 209.165.200.240. Объектами преобразования являются узлы сети 192.168.0.0/16. В качестве внутреннего интерфейса определен интерфейс S0/0/0, а в качестве внешнего интерфейса - интерфейс S0/1/0.

Используйте средство проверки синтаксиса на рис. 3, чтобы настроить PAT на маршрутизаторе R2, используя пул адресов.

Настройка PAT для одного публичного IPv4-адреса

На рис. 1 показана топология реализации PAT для преобразования одного публичного IPv4-адреса. В этом примере для всех узлов сети 192.168.0.0/16 (соответствующий список ACL 1), отправляющих трафик в Интернет через маршрутизатор R2, будет выполняться преобразование в IPv4-адрес 209.165.200.225 (IPv4-адрес интерфейса S0/1/0). Потоки трафика будут определяться номерами портов в таблице NAT, поскольку было использовано overload .

На рис. 2 показаны действия, необходимые для настройки PAT с одним IPv4-адресом. Если доступен только один публичный IPv4-адрес, для конфигурации с перегрузкой обычно назначается публичный адрес внешнего интерфейса, который подключается к интернет-провайдеру. Все внутренние адреса в пакетах, выходящих из внешнего интерфейса, преобразуются в один IPv4-адрес.

Шаг 1. Определите ACL-список, разрешающий преобразование трафика.

Шаг 2. Настройте преобразование источника, используя ключевые словаinterface и overload . Ключевое слово interface определяет IP-адрес интерфейса, который будет использоваться при преобразовании внутренних адресов. Ключевое словоoverload указывает маршрутизатору отслеживать номера портов для каждой записи NAT.

Шаг 3. Укажите интерфейсы, являющиеся внутренними по отношению к NAT. Это любой интерфейс, подключенный к внутренней сети.

Шаг 4. Укажите интерфейс, являющийся внешним по отношению к NAT. Это должен быть тот же интерфейс, который указан в записи преобразования источника в шаге 2.

Эта конфигурация аналогична динамическому NAT, за исключением того, что для определения внешнего IPv4-адреса вместо пула адресов используется ключевое словоinterface . Таким образом, пул NAT не определяется.

Используйте средство проверки синтаксиса, чтобы настроить PAT на маршрутизаторе R2 с использованием одного адреса.

Анализ PAT

Процесс преобразования NAT с перегрузкой является одинаковым как при использовании пула адресов, так и при использовании одного адреса. Продолжая предыдущий пример PAT с использованием одного публичного IPv4-адреса, компьютеру PC1 требуется подключение к веб-серверу Svr1. Одновременно другому клиенту, PC2, нужно установить аналогичный сеанс с веб-сервером Svr2. И для PC1, и для PC2 настроены частные IPv4-адреса, а на маршрутизаторе R2 включено преобразование PAT.

Процесс передачи пакетов от компьютеров к серверам

1. На рис. 1 показаны компьютеры PC1 и PC2, отправляющие пакеты серверам Svr1 и Svr2, соответственно. PC1 использует IPv4-адрес 192.168.10.10 и TCP-порт источника 1444. PC2 использует IPv4-адрес 192.168.10.11 источника и, по случайному совпадению, тот же TCP-порт источника - 1444.

2. Пакет компьютера PC1 первым достигает маршрутизатора R2. Используя PAT, R2 изменяет IPv4-адрес источника на 209.165.200.225 (внутренний глобальный адрес). В таблице NAT отсутствуют другие устройства, использующие порт 1444, поэтому PAT сохраняет этот же номер порта. Затем пакет пересылается серверу Svr1 по адресу 209.165.201.1.

3. Далее на маршрутизатор R2 приходит пакет с компьютера PC2. Настройка PAT обеспечивает использование для всех преобразований одного внутреннего глобального IPv4-адреса - 209.165.200.225. Аналогично процессу преобразования для PC1, PAT изменяет IPv4-адрес источника PC2 на внутренний глобальный адрес 209.165.200.225. Однако в этом пакете PC2 используется номер порта источника, уже содержащийся в текущей записи PAT, обеспечивающей преобразование PC1. PAT увеличивает номер порта источника, пока его значение не окажется уникальным для данной таблицы. В данном случае записи порта источника в таблице NAT и пакету от PC2 назначается номер 1445.

Хотя PC1 и PC2 используют одинаковый преобразованный адрес, внутренний глобальный адрес 209.165.200.225, и одинаковый номер порта источника - 1444, изменённый номер порта для PC2 (1445) делает уникальной каждую запись в таблице NAT. Это становится очевидным при отправке серверами обратных пакетов клиентам.

Процесс передачи пакетов от серверов к компьютерам

4. Как показано на рис. 2, при типовом обмене «клиент-сервер» серверы Svr1 и Svr2 отвечают на запросы, полученные от компьютеров PC1 и PC2 соответственно. Серверы используют для обратного трафика порт источника из полученного пакета в качестве порта назначения и адрес источника - в качестве адреса назначения. Серверы ведут себя так, как если бы они взаимодействовали с одним узлом 209.165.200.225, однако это не так.

5. Получив пакеты, маршрутизатор R2 находит уникальную запись в таблице NAT, используя адрес назначения и порт назначения каждого пакета. В случае получения пакета от сервера Svr1 адресу назначения IPv4 209.165.200.225 соответствует несколько записей, но только одна из них содержит порт назначения 1444. Используя эту запись таблицы, маршрутизатор R2 изменяет IPv4-адрес назначения пакета на 192.168.10.10. Изменение порта назначения в данном случае не требуется. Затем пакет пересылается компьютеру PC1.

6. Получив пакет от сервера Svr2, маршрутизатор R2 выполняет аналогичное преобразование. Маршрутизатор снова находит адрес назначения IPv4 209.165.200.225 с несколькими записями. Однако, используя порт назначения 1445, R2 может уникально идентифицировать запись преобразования. IPv4-адрес назначения меняется на 192.168.10.11. В этом случае порт назначения также необходимо изменить обратно на первоначальное значение 1444, сохранённое в таблице NAT. Затем пакет пересылается компьютеру PC2.

Проверка PAT

Маршрутизатор R2 настроен на предоставление PAT клиентам из сети 192.168.0.0/16. Когда внутренние узлы выходят через маршрутизатор R2 в Интернет, выполняется преобразование их адресов в IPv4-адрес из пула PAT с уникальным номером порта источника.

Для проверки PAT используются те же команды, что и для проверки статического и динамического NAT, как показано на рис. 1. Команда show ip nat translations выводит преобразования для трафика от двух различных узлов к различным веб-серверам. Обратите внимание, что двум различным внутренним узлам выделяется один и тот же IPv4-адрес 209.165.200.226 (внутренний глобальный адрес). Для различения этих двух транзакций в таблице NAT используются номера портов источников.

Как показано на рис. 2, команда show ip nat statistics позволяет проверить, что в пуле NAT-POOL2 выделен один адрес для обоих преобразований. Результат выполнения команды содержит информацию о количестве и типе активных преобразований, параметрах настройки 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 используя

Давно не новость, что сетевых адресов IP для всех устройств, желающих находиться в Интернете, не достаточно. В настоящее время выход из этой ситуации нашли, разработав протокол IPv6, в котором длина адреса составляет 128 бит, в то время как нынешний IPv4 всего 32 бита. Но в начале 2000-х годов нашли другое решение – использовать преобразование сетевых адресов, сокращенно nat. Дальше в статье будет произвена настройка nat в роутере.

Вход в меню настроек роутера

В качестве примера возьмем роутер фирмы ZyXEL серии ZyWALL USG и NXC5200.

Первым делом заходим в настройки роутера. Для этого в любом веб браузере в адресной строке набираем 192.168.1.1. (стандартный адрес роутера), появится окно с требованием ввести логин и пароль.

В поле «Имя пользователя» вводим admin, в поле «Пароль» вводим 1234. Нажимаем «ОК».

Настройка nat в роутере

В открывшемся окне меню переходим во вкладку «Configuration» (значек с двумя шестиренками), далее «Network», далее «Routing». В выбранном окне переходим на закладку «Policy Routing».

Меню настроек роутера ZyXEL

В данном меню настраивается политика маршрутизации. В области «Criteria» настраиваем критерии для выборки трафика – какой трафик необходимо транслировать (собственно настроить nat), а какой просто маршрутизировать. Трафик можно быть выбран по нескольким критериям:

1. Пользователь (User);
2. По интерфейсу (Incoming);
3. По IP-адресу источника (Source Address);
4. По IP-адресу получателя (Destination Address);
5. По порту назначения (Service).

В области «Next-Hop» назначаем объект для перенаправления трафика:

Выбор объекта перенаправления роутера ZyXEL

Где «Auto» – трафик будет перенаправляться в глобальный интерфейс, назначенного по умолчанию; Gateway – на адрес указанного в настройках шлюза; VPN Tunnel – IPSec виртуальный частный туннель; Trunk – маршрут на «транк», где «транк» – это несколько интерфейсов, настроенных на работу вместе либо в режим резервирования; Interface – перенаправление на указанный интерфейс:

Важно не забывать при любом внесении изменений в настройки роутера нажимать кнопку «OK», чтобы сохранить настройки, а не просто закрывать веб браузер.

Настройка nat на компьютере

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

Обязательно на главном компьютере, который смотрит в Интернет (назовем его SERVER) было установлено 2 сетевые карты – первая для подключения в локальную сеть, вторая к провайдеру. В примере будет использоваться операционная система Windows Server 2012.

Для настройки первым делом запускаем «Диспетчер сервера» (Пуск -> Администрирование –> Диспетчер сервера). Появится окно настройки:

Отсюда мы будем управлять нашим сервером. Для продолжения настройки нажмите «Добавить роли и компоненты», в результате чего откроется окно мастера добавления ролей. Первый шаг – Тип установки:

В следующем окне нам необходимо выбрать роль, которую мы устанавливаем на сервер. Ставим галку напротив «Удалённый доступ».

Появится следующее окно, в котором отображается список необходимых для работы компонентов. Нажимаем «Добавить компоненты», данное окно исчезнет. Жмем «Далее».

В следующем окне мастер предлагает добавить компоненты сервера. Ничего менять не надо, жмем «Далее».

На следующей странице мастер просто информирует нас о работе роли «Удаленный доступ». Жмем «Далее».

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

Следующее окно снова информационное, ничего выбирать не надо, но можно поставить галочку напротив «Автоматический перезапуск на выбранном сервере…», в результате чего сервер после установки будет автоматически перезагружен. Но можно это сделать и вручную. Жмем «Далее».

И последний шаг – непосредственная установка сервера. После окончания нажимаем кнопку «Закрыть».

Установка сервера

Итак, мы настроили компьютер, который подключен к интернету, в режим сервера. Теперь необходимо на нем настроить nat.

Переходим в Пуск / Администрирование / Маршрутизация и удалённый доступ. В появившемся окне в левой части находим пункт «SERVER (локально)», кликнем по нему правой кнопкой мыши и в выпавшем меню жмем «Настроить и включить маршрутизацию и удалённый доступ».

Появится мастер настройки сервера маршрутизации и удалённого доступа, в котором и настроим nat.

На первой странице нас кратко знакомят с мастером – жмем «Далее». На следующем шаге необходимо выбрать одну из служб, которые будут запускаться на данном сервере. Выбираем «преобразование сетевых адресов (NAT)», жмем «Далее».

Дальше мастер попросит выбрать сетевое соединение, которое смотрит в Интернет. В списке будут присутствовать обе сетевые карты (как минимум, в зависимости, сколько их установлено на сервере). Выбираем ту, к которой подключен сетевой кабель провайдера. Жмем «Далее».

В следующем окне мастер начнет ругаться, что ему не удается обнаружить в локальной сети службы DHCP или DNS. Предлагается два варианта продолжения – включить базовые службы, либо установить службы позднее.

Выбираем первый пункт, жмем «Далее». На следующей странице нас проинформирую, в каком диапазоне будет работать nat. Мастер настройки этот диапазон выбирает автоматически, исходя из конфигурации сетевого подключения, подключенного в локальную сеть. Жмем «Далее».

Диапазон nat

Все, мастер настройки завершает настройку nat. Жмем «Далее», и в следующем окне «Готово».

Осталось последнее – настроить клиентские компьютеры, то есть все остальные компьютера локальной сети. Для этого в компьютере клиента (так необходимо будет сделать на каждом компьютере сети) переходим в Пуск / Панель управления / Центр управления сетями и общим доступом / изменение параметров адаптера. Заходим в «Сетевые подключения». Кликаем по значку правой кнопкой мыши и в выпавшем меню выбираем «Свойства». В появившимся окне выбираем «Протокол Интернета версии 4 (TCP/IPv4)», жмем «Свойства».

В после «Основной шлюз» пишем IP-адрес компьютера сервера (который настраивали на прошлом шаге), в поле «Предпочитаемый DNS-сервер» пишем IP-адрес DNS сервера провайдера, указанного в сведениях подключения к интернету на сервере. Жмем «OK», и еще раз «OK». Все, клиентский компьютер подключен к Интернет.

/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

Принцип работы роутера (маршрутизатора)

Читая эту статью, я думаю, все понимают, что такое роутер и зачем он нужен, но задумывался ли кто-то - как он работает? В данной статье я постараюсь максимально доступным языком рассказать основные принципы работы маршрутизатора. Данная статья будет полезна и системным администраторам и простым пользователям.

Основная функция, которая работает в любом роутере - NAT

NAT - Network Address Translation служит для замены IP адресов. В локальных сетях в основном используются адреса типа 192.168.1.XXX или подобные, и это порождает проблему маршрутизации в глобальной сети интернет, так как IP адреса в сети не должны дублироваться. Решением данной проблемы есть NAT - компьютеры локальной сети подключаются к локальному интерфейсу роутера, получают от него IP адреса и шлюз (шлюзом служит роутер), а WAN интерфейс роутера подключается к интернету.

Теперь рассмотрим принцип NAT трансляции:

• С любого компьютера в локальной сети делается запрос, например, вы пытаетесь выйти на любой сайт - компьютер отправляет данный запрос на адрес шлюза, то есть нашего роутера;
• Роутер, получив данный запрос, записывает ваш компьютер как инициатор соединения, после чего создаётся копия вашего пакета и отправляется по адресу назначения, но уже от лица роутера, и с его IP адресом, а ваш пакет просто уничтожается;
• Сервер, которому был отправлен запрос, обрабатывает его и отправляет ответ, естественно на адрес роутера. А роутер этого уже ждал, так как создал запись о том, что на запрос вашего компьютера должен прийти ответ, и направляет его на ваш компьютер. Как видно, по данной схеме - инициатором соединения может быть только компьютер из локальной сети, а ответ от сервера попадёт на компьютер, только если роутер будет этого ждать (ответ на запрос). Другими словами, все попытки соединится из вне будут останавливаться на роутере, и будет удачны только если роутер предоставляет ресурс по запрошенному порту или у него настроены правила Port Forwarding, о которых мы сейчас поговорим.

Port Forwarding

Port Forwarding - это по сути то же самое что и NAT, но в другую сторону, а следовательно только статический NAT, то есть, определённые запросы только на определённые компьютеры, ведь в глобальной сети не могут знать IP адресов за роутером. Например, вы создали FTP или HTTP сервер на компьютере и хотите предоставить доступ к данным ресурсам, для этого нужно прописать данное правило в роутере, в котором будет указано, что все входящие пакеты на нужный порт (21 или 80 в нашем случае) будут переданы на IP адрес нашего компьютера на определённый порт (порт можно поменять).

NAT - DMZ

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

Маршрутизация

Для упрощения представления о том, что это такое, можно сказать, что это тоже самое, что и NAT, но только в обоих направлениях. При данной схеме у роутера должно быть более 2-х LAN интерфейсов (не портов, а интерфейсов), с разными адресными пространствами, например у одного интерфейса IP - 192.168.0.1, а у другого - 192.168.1.1. Следовательно, компьютеры одной сети будут получать IP типа 192.168.0.XXX, а в другой сети 192.168.0.XXX, а шлюзы у них будут соответственно 192.168.0.1 и 192.168.1.1. Вот таки образом получится двухсторонняя маршрутизация.

Не забываем оставлять