Сегодня мы рассмотрим вопрос организации общего доступа к интернет и автоматической настройки сети на платформе Windows. Несмотря на то, что это более дорогое решение, его применение будет оправдано когда необходима тесная интеграция с сетевой инфраструктурой развернутой на базе Windows Server.
В качестве рабочей платформы мы использовали Windows Server 2008 R2, как наиболее актуальную на сегодняшний день платформу, однако все сказанное с небольшими поправками применимо и к предыдущим версиям Windows Server 2003 / 2008.
Первоначально необходимо настроить сетевые интерфейсы. В нашем случае интерфейс смотрящий в сеть провайдера получает настройки по DHCP, мы переименовали его в EXT. Внутренний интерфейс (LAN) имеет статический IP адрес 10.0.0.1 и маску 255.255.255.0.
Простейшим способом организовать общий доступ к интернет будет включение соответствующей опции в настройках сетевого подключения. Однако при всей простоте такой способ чрезвычайно негибок и приемлем только если никаких других задач маршрутизации перед сервером ставиться не будет. Лучше пойти более сложным, на первый взгляд, путем, зато получить в свои руки весьма мощный и гибкий инструмент, позволяющий решать гораздо более сложные сетевые задачи.
Начнем, как полагается, с добавления новой роли сервера: Служб политики сети и доступа
.
В службах ролей отмечаем Службы маршрутизации и удаленного доступа , все остальное нас сейчас не интересует. После успешной установки роли можно будет переходить к настройкам маршрутизации.
В Ролях находим службу маршрутизации и через меню Действия выбираем Настроить и включить маршрутизацию и удаленный доступ . Настройка производится с помощью мастера, который пошагово проведет нас через все этапы настройки. В качестве конфигурации выбираем Преобразование сетевых адресов (NAT) , любые другие возможности можно будет настроить позже вручную.
Здесь нужно указать интерфейс которым наш сервер подключен к интернету, при необходимости его можно создать (например при использовании PPPoE или VPN соединения).
Остальные настройки оставляем по умолчанию и после нажатия на кнопку готово произойдет запуск службы Маршрутизации и удаленного доступа, наш сервер готов обслуживать клиентов из внутренней сети. Проверить работоспособность можно указав клиентской машине IP адрес из диапазона внутренней сети и указав в качестве шлюза и DNS сервера адрес нашего сервера.
Для автоматической настройки сетевых параметров на клиентских машинах, ну не бегать же от места к месту вручную прописывая IP адреса, следует добавить роль DHCP сервера.
Для этого выбираем Добавить роль в Диспетчере сервера и отмечаем необходимую нам опцию.
Теперь нам предстоит ответить на ряд несложных вопросов. В частности выбрать для каких внутренних сетей следует использовать DHCP, при необходимости можно настроить различные параметры для разных сетей. Потом последовательно указать параметры DNS и WINS серверов. Последний, при его отсутствии, можно не указывать. Если в вашей сети отсутствуют старые рабочие станции под управлением ОС отличных от Windows NT 5 и выше (2000 / XP / Vista / Seven), то необходимости в WINS сервере нет.
К добавлению DHCP-области нужно отнестись с повышенной внимательностью, ошибка здесь может привести к неработоспособности всей сети. Ничего сложного здесь нет, просто внимательно вводим все необходимые параметры сети, следя, чтобы выделяемый диапазон IP не перекрывал уже выделенный для других устройств и не забываем правильно указывать маску и шлюз.
Отдельно следует обратить внимание на такой параметр как срок аренды адреса. По истечении половины срока аренды клиент посылает серверу запрос на продление аренды. Если сервер недоступен, то запрос будет повторен через половину оставшегося срока. В проводных сетях, где компьютеры не перемещаются в пределах сети, можно выставлять достаточно большой срок аренды, при наличии большого количества мобильных пользователей (например публичная Wi-Fi точка в кафе) срок аренды можно ограничить несколькими часами, иначе не будет происходить своевременное освобождение арендованных адресов и в пуле может не оказаться свободных адресов.
Следующим шагом отказываемся от поддержки IPv6 и после установки роли DHCP сервер готов к работе без каких либо дополнительных настроек. Можно проверять работу клиентских машин.
Выданные IP адреса можно посмотреть в Арендованных адресах , относящихся к интересующей нас области. Здесь же можно настроить резервирование за определенным клиентом конкретного адреса (привязав по имени или MAC-адресу), при необходимости можно добавить или изменить параметры области. Фильтры позволяют создать разрешающие или запрещающие правила основываясь на MAC-адресах клиентов. Более полное рассмотрение всех возможностей DHCP-сервера Windows Server 2008 R2 выходит за рамки данной статьи и скорее всего мы посвятим им отдельный материал.
В нашем прошлом материале мы рассмотрели настройку NAT для платформы Windows Server. Как показал читательский отклик, определенные трудности возникают при использовании коммутируемых подключений к Интернету: VPN или PPPoE. Сегодня мы рассмотрим порядо...
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 или кабельные модемы.
Для того чтобы выступать в роли маршрутизатора, на сервере должно быть 2 сетевых интерфейса. Интернет и сама сеть, которую необходимо пускать в Интернет. У меня сетевые подключения называются LAN_1 (Internet) и LAN_2 (локальная сеть).
Сразу скажу, что служба Брандмауэр Windows/Общий доступ к Интернету (ICS) должна быть отключена.
Итак, приступим к установке:
Итак, сетевые интерфейсы мы установили, теперь настроим их.
Первым делом давайте настроим Внешний интерфейс (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.
Оригинальное использование трансляции сетевых адресов состоит в отображении каждого адреса из одного адресного пространства к соответствующему адресу в другом пространстве. Например, это необходимо, если провайдер интернет-услуг изменился, а пользователь не имеет возможности публично объявить новый маршрут к сети. В условиях обозримого глобального истощения IP-адресного пространства технология NAT все чаще используется с конца 1990-х годов в сочетании с IP-шифрованием (которое представляет собой метод перехода нескольких IP-адресов в одно пространство). Этот механизм реализован в устройстве маршрутизации, которое использует таблицы перевода с сохранением состояния для отображения «скрытых» адресов в один IP-адрес, и перенаправляет исходящие IP-пакеты на выходе. Таким образом, они отображаются выходящими из устройства маршрутизации. В обратном ответы отображаются в исходном IP-адресе с помощью правил, хранящихся в таблицах перевода. Правила таблицы перевода, в свою очередь, очищаются по истечении короткого периода, если новый трафик не обновляет свое состояние. Таков основной механизм NAT. Это что означает?
Данный метод позволяет осуществлять связь через маршрутизатор только тогда, когда соединение происходит в зашифрованной сети, так как это создает таблицы перевода. Например, веб-браузер внутри такой сети может просматривать сайт за ее пределами, но, будучи установленным вне ее, он не может открыть ресурс, размещенный в ней. Тем не менее большинство устройств NAT сегодня позволяют конфигурировать записи таблицы перевода для постоянного использования. Эта функция часто упоминается как статическая NAT или перенаправление портов, и она позволяет трафику, исходящему во «внешнюю» сеть, достичь назначенных хостов в зашифрованной сети.
Из-за популярности этого метода, используемого с целью сохранения адресного пространства IPv4, термин NAT (это что такое фактически - указано выше) стал практически синонимом метода шифрования.
Поскольку трансляция сетевых адресов изменяет информацию об адресе IP-пакетов, это имеет серьезные последствия для качества подключения к интернету и требует пристального внимания к деталям его реализации.
Способы применения NAT отличаются друг от друга в их конкретном поведении в различных случаях, касающихся влияния на сетевой трафик.
Простейший тип Network Address Translation (NAT) обеспечивает трансляцию IP-адресов «один-к-одному». RFC 2663 является основным типом данной трансляции. В этом типе изменяются только IP-адреса и контрольная сумма IP-заголовков. Основные типы трансляции можно использовать для соединения двух IP-сетей, которые имеют несовместимую адресацию.
Большинство разновидностей 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 на роутере.
Реализацией 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) разрешает конфликты, которые могут возникнуть между двумя различными хостами, использующими один и тот же номер порта источника для установления уникальных подключений одновременно.
/05.07.2004 20:43/Последние годы среди российских сетевых администраторов стихийно возрастает мода на FireWall и NAT . Моё отношение к этим технологиям пользователи Eserv знают еще с середины 90х годов, но иногда такие вопросы о FireWall / NAT задаются новичками, и приходится повторяться. Поэтому около года назад я написал отдельную статью о FireWall , а сегодня настала очередь NAT.
Оглавление документа
Простейшее решение этой задачи - подмена обратного адреса на границе сетей - лежало на поверхности и не замедлило опубликоваться: в мае 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" в 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-прокси.
Socks преодолел все ограничения NAT, плюс добавил как минимум три удобных средства, позволяющих не только "проксировать" практически любой TCP и UDP протокол, но и улучшить контроль над использованием интернета из ЛС:
То же самое с любым другим прикладным протоколом, для которого существуют специализированные прокси - они всегда на порядок более управляемые, чем универсальные низкоуровневые. Например, многие 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.
В Windows XP NAT/ICS включается в свойствах интернет-соединения.
Если выдается сообщение "Не удается разрешить общий доступ. Ошибка: 1722: Сервер RPC недоступен." ("Cannot enable shared access. Error: 1722: The RPC server is not available."), то скорее всего у вас остановлен или запрещен сервис DHCP-клиент, нужно его запустить до включения ICS.
Цитата Если сравнивать работу через 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 |
Помимо SNAT, т.е. предоставления пользователям локальной сети с внутренними адресами доступа к сети Интернет , часто применяется также Destination NAT , когда обращения извне транслируются межсетевым экраном на сервер в локальной сети, имеющий внутренний адрес и потому недоступный из внешней сети непосредственно (без NAT ).
На рисунках ниже приведен пример действия механизма NAT .
Рис.
7.1.
Пользователь корпоративной сети отправляет запрос в Интернет , который поступает на внутренний интерфейс маршрутизатора, сервер доступа или межсетевого экрана (устройство NAT ).
Устройство NAT получает пакет и делает запись в таблице отслеживания соединений, которая управляет преобразованием адресов.
Затем подменяет адрес источника пакета собственным внешним общедоступным IP-адресом и посылает пакет по месту назначения в Интернет .
Узел назначения получает пакет и передает ответ обратно устройству NAT .
Устройство NAT , в свою очередь , получив этот пакет, отыскивает отправителя исходного пакета в таблице отслеживания соединений, заменяет IP- адрес назначения на соответствующий частный IP- адрес и передает пакет на исходный компьютер . Поскольку устройство NAT посылает пакеты от имени всех внутренних компьютеров, оно изменяет исходный сетевой порт и данная информация хранится в таблице отслеживания соединений.
Существует 3 базовых концепции трансляции адресов:
Статический NAT отображает локальные IP-адреса на конкретные публичные адреса на основании один к одному. Применяется, когда локальный хост должен быть доступен извне с использованием фиксированных адресов.
Динамический NAT отображает набор частных адресов на некое множество публичных IP-адресов. Если число локальных хостов не превышает число имеющихся публичных адресов, каждому локальному адресу будет гарантироваться соответствие публичного адреса. В противном случае, число хостов, которые могут одновременно получить доступ во внешние сети, будет ограничено количеством публичных адресов.
Маскарадный NAT (NAPT, NAT Overload , PAT , маскарадинг) – форма динамического NAT , который отображает несколько частных адресов в единственный публичный IP- адрес , используя различные порты. Известен также как PAT ( Port Address Translation ).
Механизмов взаимодействия внутренней локальной сети с внешней общедоступной сетью может быть несколько – это зависит от конкретной задачи по обеспечению доступа во внешнюю сеть и обратно и прописывается определенными правилами. Определены 4 типа трансляции сетевых адресов:
В первых трех типах NAT для взаимодействия разных IP-адресов внешней сети с адресами из локальной сети используется один и тот же внешний порт . Четвертый тип – симметричный – для каждого адреса и порта использует отдельный внешний порт .
Full Cone , внешний порт устройства (маршрутизатора, сервера доступа, межсетевого экрана) открыт для приходящих с любых адресов запросов. Если пользователю из Интернета нужно отправить пакет клиенту, расположенному за NAT ’ом, то ему необходимо знать только внешний порт устройства, через который установлено соединение. Например, компьютер за NAT ’ом с IP-адресом 192.168.0.4 посылает и получает пакеты через порт 8000, которые отображаются на внешний IP- адрес и порт , как 10.1.1.1:12345. Пакеты из внешней сети приходят на устройство с IP-адресом:портом 10.1.1.1:12345 и далее отправляются на клиентский компьютер 192.168.0.4:8000.
Во входящих пакетах проверяется только транспортный протокол; адрес и порт назначения, адрес и порт источника значения не имеют.
При использовании NAT , работающему по типу Restricted Cone , внешний порт устройства (маршрутизатора, сервера доступа, межсетевого экрана) открыт для любого пакета, посланного с клиентского компьютера, в нашем примере: 192.168.0.4:8000. А пакет, пришедший из внешней сети (например, от компьютера 172.16.0.5:4000) на устройство с адресом:портом 10.1.1.1:12345, будет отправлен на компьютер 192.168.0.4:8000 только в том случае, если 192.168.0.4:8000 предварительно посылал запрос на IP- адрес внешнего хоста (в нашем случае – на компьютер 172.16.0.5:4000). То есть, маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае компьютер 172.16.0.5:4000), но номер порта источника при этом может быть любым. В противном случае, NAT блокирует пакеты, пришедшие с хостов, на которые 192.168.0.4:8000 не отправлял запроса.
Механизм NAT Port Restricted Cone почти аналогичен механизму NAT Restricted Cone. Только в данном случае NAT блокирует все пакеты, пришедшие с хостов, на которые клиентский компьютер 192.168.0.4:8000 не отправлял запроса по какому-либо IP-адресу и порту. Mаршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом должен быть 4000. Если клиент отправил запросы во внешнюю сеть к нескольким IP-адресам и портам, то они смогут посылать пакеты клиенту на IP- адрес : порт 10.1.1.1:12345.
Symmetric NAT существенно отличается от первых трех механизмов способом отображения внутреннего IP-адреса:порта на внешний адрес : порт . Это отображение зависит от IP-адреса:порта компьютера, которому предназначен посланный запрос . Например, если клиентский компьютер 192.168.0.4:8000 посылает запрос компьютеру №1 (172.16.0.5:4000), то он может быть отображен как 10.1.1.1:12345, в тоже время, если он посылает с того же самого порта (192.168.0.4:8000) на другой IP- адрес , он отображается по-другому (10.1.1.1:12346).
Однако следует упомянуть и о недостатках данной технологии:
