Что такое NAT на роутере? Технология преобразования сетевых адресов, механизмы PAT и NAT

Давно не новость, что сетевых адресов 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

NAT (Network Address Translation — преобразование сетевых адресов) представляет собой стандарт IETF (Internet Engineering Task Force — рабочая группа разработки технологий Интернета), с помощью которого несколько компьютеров частной сети (с частными адресами из таких диапазонов, как 10.0.x.x, 192.168.x.x, 172.x.x.x) могут совместно пользоваться одним адресом IPv4, обеспечивающим выход в глобальную сеть. Основная причина растущей популярности NAT связана со все более обостряющимся дефицитом адресов протокола IPv4. Также многие шлюзы Интернета активно используют NAT, особенно для подключения к широкополосным сетям, например, через DSL или кабельные модемы.

Установка NAT

Для того чтобы выступать в роли маршрутизатора, на сервере должно быть 2 сетевых интерфейса. Интернет и сама сеть, которую необходимо пускать в Интернет. У меня сетевые подключения называются LAN_1 (Internet) и LAN_2 (локальная сеть).

Сразу скажу, что служба Брандмауэр Windows/Общий доступ к Интернету (ICS) должна быть отключена.

Итак, приступим к установке:





Настройка NAT

Итак, сетевые интерфейсы мы установили, теперь настроим их.

Первым делом давайте настроим Внешний интерфейс (LAN_1) :

192.168.0.2 - IP-адрес пользователя, который будет выходить в сеть через наш сервер

10.7.40.154 - внешний IP-адрес сервера

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

Настраиваем клиентскую машину

Заходим в Свойства локальной сетевой карты, далее Свойства TCP/IP . Прописываем IP клиента, маску, в Основной шлюз (Default gateway) прописываем IP адрес сервера. В полях DNS необходимо прописать IP адреса DNS провайдера или IP адреса установленного локального DNS сервера.

Всё! На этом установка и настройка завершена.

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

NAT - это что такое?

Оригинальное использование трансляции сетевых адресов состоит в отображении каждого адреса из одного адресного пространства к соответствующему адресу в другом пространстве. Например, это необходимо, если провайдер интернет-услуг изменился, а пользователь не имеет возможности публично объявить новый маршрут к сети. В условиях обозримого глобального истощения IP-адресного пространства технология NAT все чаще используется с конца 1990-х годов в сочетании с IP-шифрованием (которое представляет собой метод перехода нескольких IP-адресов в одно пространство). Этот механизм реализован в устройстве маршрутизации, которое использует таблицы перевода с сохранением состояния для отображения «скрытых» адресов в один IP-адрес, и перенаправляет исходящие IP-пакеты на выходе. Таким образом, они отображаются выходящими из устройства маршрутизации. В обратном ответы отображаются в исходном IP-адресе с помощью правил, хранящихся в таблицах перевода. Правила таблицы перевода, в свою очередь, очищаются по истечении короткого периода, если новый трафик не обновляет свое состояние. Таков основной механизм NAT. Это что означает?

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

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

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

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

Базовая NAT

Простейший тип Network Address Translation (NAT) обеспечивает трансляцию IP-адресов «один-к-одному». RFC 2663 является основным типом данной трансляции. В этом типе изменяются только IP-адреса и контрольная сумма IP-заголовков. Основные типы трансляции можно использовать для соединения двух IP-сетей, которые имеют несовместимую адресацию.

NAT - это что в подключении «один-ко-многим»?

Большинство разновидностей NAT способны сопоставить несколько частных хостов к одному публично обозначенному IP-адресу. В типичной конфигурации локальная сеть использует один из назначенных «частных» IP-адресов подсети (RFC 1918). Маршрутизатор в этой сети имеет частный адрес в этом пространстве.

Маршрутизатор также подключается к интернету с помощью «публичного» адреса, присвоенного провайдером. Так как трафик проходит из локальной сети источника в каждом пакете переводится на лету из частного адреса в публичный. Маршрутизатор отслеживает основные данные о каждом активном соединении (в частности, адрес и порт назначения). Когда ответ возвращается к нему, он использует данные соединения, которые сохраняются во время выездного этапа, чтобы определить частный адрес внутренней сети, к которому следует направить ответ.

Одним из преимуществ этого функционала является то, что он служит практическим решением надвигающегося исчерпания адресного пространства IPv4. Даже крупные сети могут быть подключены к Интернету с помощью одного IP-адреса.

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

Особенности

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

Протоколы, не основанные на TCP и UDP, требуют других методов перевода. Протокол управления сообщениями в (ICMP), как правило, соотносит передаваемые данные с существующим соединением. Это означает, что они должны быть отображены с использованием того же IP-адреса и номера, установленного изначально.

Что нужно учитывать?

Настройка NAT в роутере не дает ему возможности соединения «из конца в конец». Поэтому такие маршрутизаторы не могут участвовать в некоторых интернет-протоколах. Услуги, которые требуют инициации TCP-соединений от внешней сети или пользователей без протоколов, могут быть недоступны. Если маршрутизатор NAT не делает особых усилий для поддержки таких протоколов, входящие пакеты не могут добраться до места назначения. Некоторые протоколы могут разместиться в одной трансляции между участвующими хостами («пассивный режим» FTP, например), иногда с помощью шлюза прикладного уровня, но соединение не будет установлено, когда обе системы отделены от сети Интернет с помощью NAT. Использование трансляции сетевых адресов также усложняет такие «туннельные» протоколы, как IPsec, поскольку она изменяет значения в заголовках, которые взаимодействуют с проверками целостности запросов.

Существующая проблема

Соединение «из конца в конец» является основным принципом интернета, существующим с момента его разработки. Текущее состояние сети показывает, что NAT является нарушением этого принципа. У специалистов существует серьезная озабоченность в связи с повсеместным использованием в IPv6-трансляции сетевых адресов, и поднимается проблема о том, как эффективно ее устранить.

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

Масштабируемость

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

Некоторые сложности

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

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

Port Address Translation (PAT)

Реализацией Cisco Rapt является Port Address Translation (PAT), который отображает несколько частных IP-адресов в виде одного публичного. Несколько адресов могут быть отображены как адрес, потому что каждый из них отслеживается с помощью номера порта. PAT использует уникальные номера портов источника на внутреннем глобальном IP, чтобы различать направление передачи данных. Такими номерами являются 16-разрядные целые числа. Общее количество внутренних адресов, которые могут быть переведены на один внешний, теоретически может достигать 65536. Реальное же количество портов, на которые может быть назначен единый IP-адрес, составляет около 4000. Как правило, PAT пытается сохранить исходный порт «оригинала». Если он уже используется, Port Address Translation назначает первый доступный номер порта, начиная с начала соответствующей группы - 0-511, 512-1023 или 1024-65535. Когда больше нет доступных портов и есть более чем один внешний IP-адрес, PAT переходит к следующему, чтобы попытаться выделить исходный порт. Этот процесс продолжается до тех пор, пока не закончатся доступные данные.

Отображение адреса и порта осуществляется службой Cisco, которая сочетает в себе адрес порта перевода с данными туннелирования пакетов IPv4 по внутренней сети IPv6. По сути дела, это неофициальная альтернатива CarrierGrade NAT и DS-Lite, которая поддерживает IP-трансляции адресов/портов (и, следовательно, поддерживается настройка NAT). Таким образом, это позволяет избежать проблем в установке и поддержании соединения, а также обеспечивает механизм перехода для развертывания IPv6.

Методы перевода

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

Для этой цели (как настроить NAT) в 2003 году был разработан специальный протокол RFC 3489, обеспечивающий простой обход UDP через NATS. На сегодняшний день он является устаревшим, поскольку такие методы в наши дни являются недостаточными для правильной оценки работы многих устройств. Новые методы были стандартизованы в протоколе RFC 5389, который был разработан в октябре 2008 года. Эта спецификация сегодня носит название SessionTraversal и представляет собой утилиту для работы NAT.

Создание двусторонней связи

Каждый пакет TCP и UDP содержит IP-адрес источника и номер его порта, а также координаты порта назначения.

Для получения таких общедоступных услуг, как функционал почтовых серверов, номер порта имеет важное значение. Например, подключается к программному обеспечению веб-сервера, а 25 - к SMTP почтового сервера. IP-адрес общедоступного сервера также имеет существенное значение, подобное почтовому адресу или номеру телефона. Оба этих параметра должны быть достоверно известны всем узлам, которые намерены установить соединение.

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

РАТ (Port AddressTranslation) разрешает конфликты, которые могут возникнуть между двумя различными хостами, использующими один и тот же номер порта источника для установления уникальных подключений одновременно.

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

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

Основная функция, которая работает в любом роутере - 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. Вот таки образом получится двухсторонняя маршрутизация.

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