Этой статьей мы открываем рубрику с не слишком оригинальным названием "расставим точки над i". Как следует из названия, целью материалов, публикуемых в ней, будет попытка дать наиболее полное описание некоторой технологии, как то освещение общих теоретических аспектов и обзор (сравнение) конктерных практических ее реализаций (это может быть и "железо", и программное обеспечение, или и то и другое вместе - в зависимости от того, о чем пойдет речь). Однако очевидно, что автор, делающий попытку столь глобально осветить ту или иную проблему, подходит к ней все-таки со своих, порой весьма субьективных позиций. Это естественно может привести к тому, что, выражаясь фигурально, не все "точки над i" окажутся на положенных им местах - нет-нет, да и закатятся куда-нибудь или не дай бог окажутся над какой-то другой буквой ;) . И вот тут на помощь можете придти вы, наши уважаемые читатели. Если у вас есть опыт работы с описанной в рубрике технологией, с конкретными продуктами на ее базе, и у вас есть впечатления, которыми вы бы хотели поделиться с коллегами, предлагаем вам высказать свое мнение на страницах СР. Таким образом, в каждом последующем номере в рамках "i" мы надеемся возвращаться к предыдущей теме, дабы услышать тот самый vox populi - глас народа, который, надеемся добавит газете объективизма и будет на пользу читателям. А может быть и нет... -- будем посмотреть ;)
КРАТКОЕ ВСТУПЛЕНИЕДвумя
основными
проблемами,
стоящими
сегодня
перед
глобальной
сетью
Интернет,
является
ограниченность
адресного
пространства
протокола 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 IP NAT 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 IP Port local NAT port
191.167.0.10 1243 61300
Таким
образом, при
получении
ответа от веб
сервера
будет
просмотрена
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. Saemon alice@nestor.minsk.by