To NAT or not to NAT, вот в чем вопрос:
краткое вступление
Двумя основными проблемами, стоящими сегодня перед глобальной сетью Интернет, является ограниченность адресного пространства протокола IP и масштабирование маршрутизации.
Эти проблемы не решает, но в некотором роде нивелирует приобретающая в последнее время все большую популярность технология, о которых сегодня и пойдет речь: NAT (Network Address Translation*).
зачем это нужно
NAT применяется для решения следующих проблем и задач:
При необходимости подключения к Интернет, когда количество внутренних узлов сети превышает выданное поставщиком услуг Интернет количество реальных адресов IP. NAT позволяет частным сетям IP, использующим незарегистрированные адреса, получать доступ к ресурсам Интернет. Функции NAT конфигурируются на пограничном маршрутизаторе, разграничивающем частную (внутреннюю) сеть и сеть общего пользования (например, Интернет). Далее сеть общего пользования мы будем называть внешней сетью, а частную сеть - внутренней сетью.
При необходимости изменения внутренней системы адресов. Вместо того, чтобы производить полное изменение всех адресов всех узлов внутренней сети, что представляет собой достаточно трудоемкую процедуру, NAT позволят производить их трансляцию в соответствии с новым адресным планом.
При необходимости организации простого разделения трафика на основе портов TCP. Функции NAT предоставляют возможность установления соответствия (mapping) множества локальных адресов одному внешнему адресу, используя функции распределения нагрузки TCP.
как это работает
Определение NAT в общем случае может звучать следующим образом: это трансляция IP адресов, использующихся в одной сети в адреса, используемые в другой. Определение, конечно, несколько обтекаемо, но оно отражает важную, на мой взгляд идею - вопреки бытующему в народе мнению, что NAT призван транслировать лишь незарегистрированные, зарезервированные для использования в локальных сетях (иногда их еще называют fake addresses) адреса в реальные, выданные провайдером или регистрирующей организацией, NATу решительно все равно что во что транслировать, что на практике может оказаться весьма полезным.
NAT по сути не является протоколом или стандартом. Документ RFC 1631, посвященный NAT, называет его не иначе как технология или design, описывая только общие идеологические моменты. В конечном итоге все будет зависеть от реализации этой техники. Поэтому остановимся на общих аспектах функционирования NAT.
Существует 3 базовых концепции трансляции адресов - статическая, динамическая, и masquerading.
Static Network Address Translation
С помощью этого типа NAT мы можем организовать трансляцию между сетями одинакового класса . Частным случаем является ситуация когда обе эти сети содержат по одному адресу (маска 255.255.255.255). Эта стратегия наиболее проста в реализации поскольку весь процесс трансляции может быть описан парой простых логических трансформаций.
В качестве примера приведем трансляцию адресов из двух сетей класса С - 194.24.90 и 195.60.3. При прохождении через NAT интерфейс пакеа, адресованный от хоста 194.24.90.13 в IP заголовке в поле адрес отправителя будет произведена замена с 194.24.90.13 на 195.60.3.13. Аналогично и в обратную сторону.
Dynamic Address Translation
Динамическая трансляция необходима в случае, когда количество транслируемых адресов (внутренних и внешних) различно, впрочем иногда применяется и в случае, когда их количество одинаково, но из каких-либо соображений зависимость не может быть описана правилами статической трансляции. Количество взаимодействующих хостов в любом случае будет ограничено числом свободных (доступных) на NAT-интерфейсе адресов. Динамическая реализация NAT более сложна, поскольку требует вести учет взаимодействующих хостов, а иногда и конкретных соединений, в случае когда требуется просмотр и модификация содержимого на 4-м уровне (TCP например).
Пример:
Необходимо динамически транслировать все IP адреса в сети класса B 138.201 в адреса сети класса С 190.200.112. При этом каждое новое соединение из внутренней сети получает адрес из пула класса С до тех пор, пока там есть свободные адреса.
В этой технологии в отличае от статической трансляции появляется новое понятие - таблица NAT (NAT table), которая применительно к динамической трансляции представляет собой таблицу соответствия внутренних адресов и адресов интерфейса NAT (далее для краткости - NAT адресов). Гипотетическая NAT таблица применительно к нашему примеру может выглядить следующим образом:
Internal IPNAT IP
190.200.112.35
190.200.112.76
и так далее...
В случае динамический трансляции существует возможность организовать соединение извне к некоторому внутреннему хосту, но только в том случае, пока в NAT таблице существует соответсвующая запись. Применительно к описанному выше примеру, мы можем получить доступ извне к машине с адресом 138.201.70.20, обратившись по адресу 190.200.112.35. Это, конечно, дает некоторую почву для злоупотреблений, однако несколько непредсказуемую по времени.
Masquerading (NAPT, PAT)
Прежде чем разобрать технологические аспекты этой схемы, хочется сделать небольшое замечание. Дело в том, что именно эта техника наиболее распространена на сегодняшний момент, особенно в небольших частных сетях, имеющих выход в глобальные. И зачастую всю идеологию NAT путают именно с этим частным случаем - "маскарадом" (второе популярное название PAT - Port Address Translation) , поскольку он призван решать проблему нехватки реальных IP и использование одного адреса, выделенного провайдером, для работы в Интернет хостов из локальной сети.
Строго говоря, маскарад (да простят меня пуристы русскоязычной компьютерной терминологии за вольный, калькированный перевод ;) - это очень частный случай динамичесмкой трансляции, при котором мы имеем только один внешний адрес, за которым "спрятаны" внутренние - их может быть теоретически сколько угодно. В отличае от оригинальной динамической трансляции, маскарад, разумеется, не подразумевает функционирование единовременно только одного соединения, иначе вся идея лишалась мало-мальского смысла. Дабы расширить количество одновременных сеансов, эта техника использует информацию о номере TCP порта. Таким образом количество одновременных сеансов ограничено только количеством свободных (из числа выделенных под NAT портов). Чаще всего под это дело выделяются порты, малоприменимые в других сферах. Линукс использует диапазон 60000-64096, но есть и другие варианты.
Рассмотрим функционирование маскарада на таком примере:
Имеется внутренняя сеть 191.167.0 ( я намеренно использую реальные адреса в примерах дабы подчеркнуть, что теоретически это абсолютно нормальное положение вещей) и маршрутизатор с NAT адресом 193.200.150.5. Хост из внутренней сети с адресом 191.167.0.10 и исходящим TCP портом 1243 обращается к веб-серверу 205.131.1.1. При проходе через NAT интерфейс исходящий пакет в общем случае претерпевает следующие преобразования: в заголовке IP заменяется адрес оправителя, и в заголовке TCP заменяется исходящий (source) порт - с 1243 на, например, 62300. В NAT таблицу при этом вносится следующая запись:
Internal IPPortlocal NAT port
191.167.0.10124361300
Таким образом, при получении ответа от веб сервера будет просмотрена NAT таблица и пакет, адресованный на порт 61300 будет соответствующим образом откорректирован: в заголовке IP появится внутренний адрес, а в заголовке TCP - порт 1243, теперь уже в качестве входящего (destination) порта.
В отличае от классической динамической трансляции, маскарад не допускает организации входящих соединений, и записи в таблице NAT .... только для активных соединений. Разумеется, можно организовать так называемый порт маппинг (port mapping) на NAT интерфейсе, но это уже напрямую к классическому NAT не относится и в рамках этой статьи рассматриваться не будет.
Кроме описанных выше классических техник, примемение находят также другие схемы - например так называемый виртуальный сервер, обеспечивающий прозрачное для пользователя распределение нагрузки между несколькими "реальными" серверами.
Теперь такой вот момент... Из того, что мы выяснили о NAT на первый взгляд следует его абсолютная прозрачность для взаимодействующих хостов. Однако это не совсем так. Если присмотреться внимательно к используемым сегодня сетевым приложениям, мы обнаруживаем, что иногда IP адрес передается не только в заголовке IP, но и в датаграммах более высоких уровней. Эта проблема требует от соверменных реализаций NAT некоторой дополнительной "интеллектуальности". Вот лишь пара наиболее ходовых примеров:
FTP
Команды PORT и ответ на PASV посылают IP адрес и номер порта в теле сообщения в десятичном представлении. При прохождении через NAT возникает необходимость, корректировать эту информацию в теле FTP-сообщения. Поскольку каждая цифра в представленном в десятичном ASCII виде IP адресе это лишний байт нашего пактеа, при изменении адреса в сторону увеличения или уменьшения количества цифр в октетах, размер всего пакета соответствующим образом изменится. Таким образом перед NATом стоит дополнительная задача - внести изменения в TCP sequence number, пересчитать контрольные суммы и размеры пакетов как IP так и TCP. Так что если у вас "нерадивый" NAT, не утруждающий себя хотя бы одним из вышеперечисленных занятий - с ftp могут случится проблемы. Все вышесказанное, кстати, справедливо и применительно к другим протоколам, в которых изменения IP адреса влечет за собой изменение размера пакета.
ICMP
Некоторые типы ICMP сообщений включают в себя часть заголовка исходного IP пакета. Если исходный пакет был транслирован, заголовок будет содержать адрес NAT интерфейса вместо локального. В зависимости от того, как в каждом конкретном случае используется эта информация, это может либо создавать проблему, либо нет. При выборе реализации NAT, таким образом, следует обратить внимание как происходит трансляция ICMP сообщений.
Кроме приведенных выше "клинических случаев", теоретически проблемы могут возникнуть также с DNS, Real Audio, RSVP, H.323V1, X-Windows, и даже с SMTP, но последнее - скорее курьез, связанный с неудачной конфигурацией внутреннего почтовго сервера. Можете заглянуть в документ от Internet Engineering Task Force на эту тему, дабы ознакомиться с подробностями -- http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-01.txt
преимущества и недостатки
Одним из важнейших преимуществ NAT является то, что нет необходимости вносить изменения в конфигурацию конечных узлов и маршрутизаторов внутренней сети, за исключением тех устройств, на которых собственно и выполняются эти функции. NAT не имеет практического применения в тех сетях, где с внешней сетью одновременно работает большое количество внутренних узлов. Также отметим, что функции NAT скрывают внутреннее расположение узлов, что в зависимости от конкретных условий может быть как преимуществом, так и недостатком, впрочем с практической точки зрения это в большинстве случаев -- благо.
Как уже было сказано ранее, наибольшее практическое применение NAT в наших условиях находит в качетсве решения для так называемого internet connection sharing'а - предоставления доступа пользователям локальной сети в Интернет при наличии лишь одного реального адреса. В этом плане у нас есть выбор между двумя технологиями - собственно NAT' ом и прокси (proxy, посредник). Не вдаваясь в подробности отосительно технологии прокси, следует обратить внимание на принципиальное различие этих концепций. Модуль NAT - маршрутизирует пакеты, внося в них некоторые изменения, прокси же представляет собой сервис, демона если угодно, который для осуществления взаимодействия между внутренним и внешним хостами открывает 2 соединения - с внутренним и внешним хостом соответственно, и передает данные между ними. Из чего следует что соединение с внешним хостом действительно происходит от имени прокси-сервера. Трудно, а скорее всего -- невозможно однозначно сказать, решения на базе какой технологии будут работать быстрее, поскольку это в конечном итоге зависит а) от конкретной реализации б) от аппаратной платформы, на которой это дело работает. Другой вопрос, что большинство современных прокси-серверов включают возможность кэширования веб и ftp, что используется для ускорения загрузки часто используемых ресурсов. Поэтому с этой точки зрения работа прокси кому-то может показаться быстрее, но это в нашем контексте - фактор субъективный ;)
Что касается вопросов безопасности... Прокси и NAT (имеем в виду маскарад) по сути дела являются файерволлами, или, выражаясь точнее, входя в состав различных аппаратных и программных файерволлов, обеспечивают невидимость хостов внутренней сети извне. Однако вопросы безопасности не ограничиваются ограждением сети от попыток проникновения извне. Многих администраторов не менее волнует, чем именно и в каком объеме занимаются его пользователи в Интернет. Вопрос политики безопасности каждой компании - дело сугубо интимное, но одно можно сказать определенно - большинство современных реализаций прокси дают администратору больше возможностей по ущемлению прав пользователей, чем NAT - за счет фильтрации на уровне ресурсов протоколов верхних уровней (как, например, http).
реализации
Я сознательно не хочу очень подробно останавливаться на особенностях конкретных реализаций NAT - наборе возможностей и тонкостях конфигурирования. Дело в том, что с повышением популярности этой технологии, поддержка NAT на сегодняшний день реализуется во множестве сетевых устройств (в первую очередь в маршрутизаторах большинства известных марок) , а также программно для использования на платформе ПК. Я лишь смею надеяться, что вооружившись информацией этой статьи и руководством по настройке и эксплуатации интересующего железа или ПО - вы прекрасно разберетесь во всем сами ;)
В качестве примеров приведу наиболее ходовые на мой взгляд решения, одно из которых относится к использованию NAT на аппаратном маршрутизаторе, и 2 - на ПК (варианты для win32 и unix-like систем).
CISCO IOS NAT
Нет нужды говорить, что сегодня подавляющее большинство парка маршрутизаторов как в мире, так и в нашей стране - маршрутизаторы Cisco, работающие под управлением их собственной операционной системы Cisco IOS. Начиная с версии 11.2 IOS включает в себя поддержку NAT, однако от версии к версии набор функциональных возможностей IOS NAT несколько различается. До версии 12.0 стандартная поставка IOS включает в себя либо только PAT (маскарад), либо не включает NAT вовсе. Поставка "Plus" имеет полную поддержку NAT во всех версиях начиная с 11.2. Полный NAT (full NAT) от циски - это работа по всем 3-м рассмотренным выше схемам, плюс, естественно, достойный уровень "интеллектуальности" применительно к проблемным протоколам. Однако и на старуху бывает проруха, кое-что в IOS NAT не поддерживается: IP Multicast, обновление маршрутных таблиц, трансфер зон DNS, BOOTP, talk, ntalk, SNMP, NetShow. Впрочем, к чести Cisco, не-функционированию почти всего из перечисленного можно найти достойное оправдание.
Что приятно, конфигурирование IOS NAT достаточно просто, даже, если такой термин может быть применим к IOS - интуитивно. Вот вам пример: осуществление трансляции адресов внутренних сетей 192.168.1.0 или 192.168.2.0 в пулл внешних 171.69.233.208/28 :
ip nat pool net-20 171.69.233.208 171.69.233.223 netmask <netmask>255.255.255.240
ip nat inside source list 1 pool net-20
!
interface Ethernet0
ip address 171.69.232.182 255.255.255.240
ip nat outside
!
interface Ethernet1
ip address 192.168.1.94 255.255.255.0
ip nat inside
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
На мой взгляд, вполне "душевный" синтаксис команд.
Более подробно о возмостях Cisco IOS NAT вы можете прочесть на сайте компании (www.cisco.com) в разделе технической документации, в частности вот здесь: http://www.cisco.com/warp/public/110/index.shtml#nat
Winroute
Если вашей компании накладно или по каким-то иным причинам нет необходимости держать у себя аппаратный маршрутизатор, или вы, как ваша покорная слуга, принципиальный поклонник PC router'ов - можно организовать работу NAT на базе ПК под управлением Windows95/98/NT или какого-либо клона UNIX.
Наилучшим решением для win32 по праву признан чешский продукт Winroute. Это интегрированное решение, включающее в себя IP маршрутизатор, NAT, файерволл, DHCP , proxy и почтовый сервера. В отличае от реализации от Сisco, Winroute NAT способен работать лишь на некоторых типах интерфейсов: LAN, ppp-dialup, ISDN, xDSL, DirecPC. Из чего следует, что этот продукт не будет работать на хосте, подключенному к Интернет через WAN-интерфейс к, например, сети x.25 или frame relay, поверх которых работает ваш IP, что в рамках Беларуси является топологией исключительно распространенной. Еще одна чисто местная проблема - широкая распространенность протокола SLIP в dial-up соединениях. SLIP интерфейсы, к сожалению, не поддерживаются вовсе, и разработчик делать это решительно не собирается :( В обоих случаях вам придется выделять Winroute в качестве отдельного сегмента с двумя LAN-интерфейсами.
Врочем овчинка выделки стоит! Winroute поддерживает шипрочайший набор протоколов. Не буду приводить полный список, отмечу только что корректно работает UnixTalk, ICA Winframe, h.323, и, естественно, все широкоупотребимые. Пакет занимает очень мало места на диске и, выполняя столько полезных задач, съедает относительно немного оперативной памяти. С точки зрения безопасности особого внимания заслуживает тот факт, что модули NAT и файерволла работают "под" винсоком, на более низком уровне, тем самым при грамотной конфигурации файерволла вы сможете уберечь себя от проблем ( в том числе еще не "открытых" ;) в реализации TCP/IP от Microsoft.
Конфигурация Winroute потрясающе интуитивна, административный GUI - безупречен! Стоит Winroute по нашим меркам бешенных денег (от $50 до $700) , но... всегда есть варианты для, так сказать, злоупотреблений ;) Подробности на www.winroute.com.
Linux IP Masquerade
Допустим вы принципиально не переностите платформу win32 для управления сетями, либо являетесь поклонником open source и бесплатных (в исконном смысле слова ;) программных продуктов. Постройте NAT на Linux.
Исторически маскарад живет на Линуксе начиная с версий ядра 1.3.х, однако на практике нормальный NAT можно получить на ядрах 2.0.3х - если вы убежденный ретроград, и на всех 2.2.х. О последних и пойдет речь. Маскарад на Линуксе встраивается в ядро. Часть современных дистрибутивов поставляются с изначально встроенной поддержкой маскарада, но в общем случае нужно посмотреть, что есть в вашем ядре и при необходимости пересобрать (перекомпилировать) ядро (вообще-то пересобирать под свои задачи ядро - это в принципе хороший тон ;) . Конфигурируется линуксовый NAT с помощью утилит - администраторов файерволлов: ipfwadm для ядер 2.0.х и ipchains для 2.2.х. На мой взгляд, интуитивным этот интерфейс вряд-ли назовешь...
Маскарад на Линуксе достаточно интеллектуален, правда, поддержка того или иного протокола зависит от установленной версии masquerade-модуля ядра и/или соответствующих патчей - и того и другого очень много, поэтому советую следить за документацией ;) На данный момент в качестве неподдерживаемых протоколов/сервисов были замечены: Netscape CoolTalk, talk, ntalk, WebPhone, под вопросом X-Windows. Многие вещи требуют дополнительных ухищрений в конфигурации файерволла (port mapping и т. п). По крайней мере терминалы h.323, как заявлено, без такого рода донастройки работают криво... Это что касается недостатков.
В качестве достоинств следует отметить, что исходя из общей идеологии Линукс/GNU - процесс замены версий и выпуска патчей идет очень быстро, поэтому есть вероятность, что то, что не поддерживается сегодня, будет прекрасно работать уже завтра. Вторым достоинством является то, что решеня на базе Линукс до сих пор (хотя уже с некоторой натяжкой) считаются одними из самых малотребовательных к ресурсам ПК. Вы можете собрать сами или найти в Интернете "маленький" специализированный Линукс, который на минимальной аппаратной конфигурации (P80-100, 32M RAM) обеспечит вам хороший NAT Router - поставить в шкаф и забыть ;)
прочие
Выше были предложены наиболее ходовые решения. Вы можете подыскать себе что-нибудь другое. Нет никакой возможности привести полный список устройств и ПО, реализующих NAT, поскольку уже на следующий день список будет безнадежно устаревшим. Есть прекрасная страница в Интернет, где имеется такого рода список и даже более-менее регулярно обновляется: Вот ее адрес: http://www.uq.net.au/~zzdmacka/the-nat-page/.
послесловие(для тех, кто не поленился дочитать до конца ;)
Как хорошо известно сисадминам-практикам, универсальных решений в природе нет и быть не может. Поэтому советовать - применять описаную технологию или нет, и если применять, то в какой ее реализации, я не буду. Но как было сказано , задача рубрики "Расставим точки над i" -- не только осветить основные аспекты той или иной технологии, но и дать возможность специалистам, уже применяющим ее на практике, поделиться своими соображениями с читателем. Редакция будет рада ознакомиться с вашими замечаниями, дополнениями и даже исправлениями, а также с впечатлениями от работы с NAT вообще, и используемыми вами реализациями в частности. Комментарии принимаются наземной и электронной почтой, а также через веб-форму по адресу: home.nestor.minsk.by/netsol/i/feedback.html. Самое содержательное и полезное будет опубликовано в следующем выпуске СР в этой же рубрике. Спасибо за внимание ;)
* -- вообще-то авторитетная организация Internet Engineering Task Force, курирующая разработку и стандартизацию в области NAT, расшифровывает аббревиатуру как Network Address Translator, но в народе de facto прижилось почему-то ...Translation ;)
Alice D. Saemonalice@nestor.minsk.by
Сетевые решения. Статья была опубликована в номере 13 за 2000 год в рубрике RFC
