NAT — Network Address Translation
AndreyCherezov /05.07.2004 20:43/Последние годы среди российских сетевых администраторов стихийно возрастает мода на FireWall и NAT. Моё отношение к этим технологиям пользователи Eserv знают еще с середины 90х годов, но иногда такие вопросы о FireWall / NAT задаются новичками, и приходится повторяться. Поэтому около года назад я написал отдельную статью о FireWall, а сегодня настала очередь NAT.
Эпиграф
Добавлено 28.12.2005. Хорошее резюме проблемы NAT сделали
История NAT
Сначала несколько слов об истории появления необходимости в проксировании / гейтировании / туннелировании в интернете, тогда яснее станут возможности разных подходов и их "иерархия". Как известно, нехватка IP-адресов в 4-байтовом адресном пространстве прогнозировалась еще в начале 90х годов (плюс нехватка денег на аренду адресных блоков в некоторых компаниях

Простейшее решение этой задачи — подмена обратного адреса на границе сетей — лежало на поверхности и не замедлило опубликоваться: в мае 1994 г., т.е. через два месяца после "раздела сетей" предложили спецификацию NAT:


NAT "глазами" интернет-программ
Если бы на практике все было так просто, то было бы неинтересно
NAT

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

Намного проще эта задача решается, если вместо 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 (предыдущие "версии" не применялись ни в каких продуктах)

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

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 на сайте Microsoft:


См. также:





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



NAT, IPv6, Teredo и Windows Vista
(добавление от 2 августа 2006 года) Цитата из Windows Vista Product Guide: "По мере быстрого увеличения количества сетевых устройств становится все труднее изменять масштаб архитектуры IPv4, приводя его в соответствие с растущими потребностями компаний. Сегодня ИТ-администраторам для обслуживания большего числа сетевых устройств приходится либо применять такие технологии, как преобразование сетевых адресов (NAT), что приводит к усложнению системы и может вызвать появление проблем с совместимостью приложений, либо объединять в одной сети общие и частные IP-адреса. Дополнительные решения и методики способны увеличить расходы на эксплуатацию сети и создать проблемы с безопасностью. Поддержка протокола IPv6 в Windows Vista позволяет компаниям обслуживать более широкий диапазон сетевых адресов, обходясь при этом без применения технологии NAT и других временных решений. Протокол IPv6 обеспечивает расширение адресного пространства, значительно превышающее возможности IPv4, и полностью поддерживает протокол IPSec. С помощью переходного механизма, обеспечивающего туннелирование трафика IPv6 через инфраструктуру IPv4, компания может осуществить развертывание протокола IPv6, не выполняя коренного обновления своей сети. Протокол IPv6 в составе Windows Vista поддерживает технологию Teredo, которая делает возможными глобальную адресацию и сквозной обмен данными между приложениями с поддержкой протокола IPv6 на разных клиентских компьютерах Teredo. Благодаря технологии Teredo разработчикам приложений больше не приходится в обязательном порядке создавать собственные решения для прохождения NAT. Преимущества технологии Teredo (встроенного в Windows Vista решения для прохождения NAT) доступны всем приложениям с поддержкой протокола IPv6."NAT глазами сисадмина провайдерских Linux
(Добавление от 6 июля 2004 — первый отклик на статью. Как и в статье про FireWall, предоставим слово настоящему сисадмину
Цитата Если сравнивать работу через NAT с реальным IP, то пока проблемы с NAT у меня были только с голосом, видео и передачей файлов в программах типа MSN Messenger. Возможно в каких-то реализациях NAT'а есть также проблемы с активным ftp, соединением с внешними VPN-серверами и т.п., но при работе через NAT в Linux'е (при соответсвующих настройках) с этим проблем нет. Преимущество NAT в данном случае в экономии IP-адресов и файрволе.
Если сравнивать NAT с прокси (как способ выхода в Интернет, т.е. перенаправление запросов, не рассматривая функции кэширования, анализа URL и т.п.), то через NAT работает больше приложений и протоколов (все IP); для NAT не требуется специальных настроек со стороны пользователя; прокси более требователен к оборудованию. Прокси обычно не обеспечивают функциональности Destination NAT (DNAT), хотя в Есерве у тебя частичного подобия DNAT можно добиться с помощью tcp/udp-маппинга. Конец цитаты.
Эта цитата показывает, что у провайдеров тоже требования сильно отличаются от админов на предприятиях.
См. также Статьи
unknown: YandexDirect|