Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

IP-шлюз для "игры в прятки"

Эрик Холл

Позвольте еще раз напомнить вам то, что вы, наверное, уже хорошо знаете, — сегодня в сетях любого уровня предпочтение отдается семейству протоколов ТСР/IP. Все крупные производители сетевых операционных систем в той или иной степени оснащают ими свои продукты — это необходимо для работы с Интернет, и, наконец, этого просто требуют пользователи. В то время как в полностью изолированных локальных сетях можно работать с любыми IP-адресами, для нормального функционирования узлов, взаимодействующих с Интернет или с другими удаленными сетями, необходимо использовать установленные в Интернет правила выделения адресов. И хотя узел, чей IP-адрес не был назначен в соответствии с этими правилами, может посылать пакеты "во внешний мир", узел-адресат не ответит ему, если адрес первого узла уже используется где-то в сети Интернет.

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

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

В основном IP-шлюзы выполняются на базе либо аппаратно реализованных межсетевых экранов (firewall) или маршрутизаторов, либо программных преобразователей протоколов IP—IPX. Например, лежащие в основе архитектуры межсетевого экрана BorderWare фирмы Secure Computing приложения-посредники выполняют функции IP-шлюза для внутренних клиентских программ, которые взаимодействуют с внешними ресурсами. Для этих программ межсетевой экран выглядит как маршрутизатор, расположенный между внутренней и внешней сетями. В этом случае пакеты направляются к внешним узлам не сразу, как это делается с помощью обычного маршрутизатора, а сначала проходят через шлюз. В результате для внешних узлов они выглядят так, как будто созданы самим этим шлюзом. В свою очередь, ответные пакеты также направляются внешними узлами к шлюзу, где и происходят их переадресация и рассылка соответствующим внутренним узлам.

Другая распространенная форма реализации IP-шлюза, заключающаяся в замене файла WINSOCK.DLL специальным драйвером, обычно применяется в программных преобразователях протоколов IP—IPX, например в таком, как ПО Novell Internet Access Server (NIAS) в составе IntranetWare. При этом внутренние сетевые устройства используют не реальные IP-стеки, а новый драйвер WINSOCK.DLL, обеспечивающий транспортировку запросов на IP-услуги по протоколу IPX. Клиенты разделяют IP-стек сервера NetWare непосредственно между собой и используют его службу управления портами для своих нужд. По существу, клиентские IP-стеки на основе IPX становятся "расширениями" IP-стека сервера и вместо выстраивания таблиц соответствия внутренних и внешних IP-адресов и портов сервер NIAS создает одну адресную таблицу, которая "подстраивает" внутренние IPX-адреса под внешние IP-адреса и номера портов (см. функциональную схему организации шлюза на основе сервера NIAS). С помощью нового драйвера WINSOCK.DLL программы-клиенты взаимодействуют с TCP- и UDP-приложениями через протокол IPX и при этом создают виртуальные IP-соединения "от имени сервера". Таким образом, протокол IPX используется для доставки виртуальных IP-пакетов на сервер, а он, в свою очередь, использует свой локальный IP-стек для отправки пакетов по назначению.

Конструктивно это напоминает организацию шлюза в рамках старой системной сетевой архитектуры (Systems Network Architecture — SNA) фирмы IBM, где с целью предоставления транспортных услуг на базе IPX и других протоколов также используется центральная система. В нашем случае имеют место такие же ограничения, с которыми ранее приходилось сталкиваться при использовании SNA-шлюзов. Прежде всего внутренние сетевые устройства сами по себе не могут выступать здесь как полноценные IP-узлы, и поскольку эти устройства не имеют своих собственных IP-адресов, то даже в пределах локальной сети они не могут быть идентифицированы как IP-узлы. В данном случае они даже не смогут выполнить взаимное эхо-тестирование с помощью команды ping, так как ICMP-трафик замыкается на сервере NetWare, поскольку только он один имеет установленный IP-стек.

Минимум поддержки или максимум функциональности?

Коренные различия этих двух вынесенных в подзаголовок целей обусловливают различные варианты возможных схем организации управления. Например, поскольку сервер NIAS использует один-единственный IP-стек для обслуживания всех клиентов, то все, что необходимо последним, — только определить порты для работы с IP-приложениями. Сам же сервер просто-напросто создаст ссылку в адресной таблице, которая и назначит номер порта соответствующему IPX-клиенту. В этом случае даже не надо переписывать адреса в заголовках пакетов или делать что-нибудь в этом роде, требуется лишь пересылка пакетов по назначению либо во "внешний мир", используя протокол IP, либо во внутреннюю сеть с помощью протокола IPX.

Напротив, продукт BorderWare позволяет добиваться высокой степени управления пакетами путем полного "переписывания" каждого передаваемого IP-пакета. Этот межсетевой экран при любом изменении адресов приложений должен переписывать не только IP-адреса обрабатываемых пакетов, но и контрольные суммы IP-, TCP- и UDP-пакетов, а также адреса, находящиеся внутри самих пакетов, и порядковые номера TCP-пакетов.

Используя сервер NIAS, этих сложностей можно избежать, поскольку клиентам непосредственно уже назначены соответствующие порты через IP-стек сервера NetWare. Если же FTP-клиент "пожелает" загрузить находящийся на внешнем узле файл через сервер NIAS, то, используя обычный запрос драйвера WINSOCK.DLL, он назначит данному соединению идентификатор (socket) и выдаст команду PORT, указывающую на него.

Если бы описанный выше сценарий относился только к FTP, данную статью можно было бы на этом и закончить. Но на самом деле некоторые приложения включают в свои пакеты адреса клиентов и номера портов. Большинство ICMP-приложений (например, ping и traceroute), подобно большинству популярных агентов БД типа клиент—сервер, помещают информацию о клиенте прямо в пакет. И если IP-шлюз "не умеет" работать с такими приложениями и "не знает", как преобразовать пакеты соответствующим образом, то эти приложения не будут работать нигде, кроме локальной сети.

К тому же уметь преобразовывать данные, помещенные в пакет конкретным приложением, — это еще не все. При неидентичном "размере" заменяемых адресов вся последовательность пакетов должна быть скорректирована. Обеспечивая поддержку виртуального канала, протокол TCP использует специальные поля для информирования взаимодействующих друг с другом процессов о количестве переданных и полученных байтов. Если шлюз заменяет адрес клиента в FTP-команде PORT с 10.0.0.1 на 192.155.15.10, то тогда физический размер пакета увеличится на 5 байт. В свою очередь, это потребует, чтобы шлюз также увеличил значение внешнего TCP-счетчика на 5 байт. При этом шлюз должен не только отслеживать соответствующую информацию как для внешней, так и для внутренней части соединения, но и обеспечивать коррекцию счетчика байтов для клиентской программы.

Фирма Secure Computing проделала работу, достойную восхищения: она оснастила свой продукт BorderWare модулями-посредниками, чувствительными к особенностям конкретных приложений, и продолжает разрабатывать все новые и новые модули. Суть в том, что вся архитектура этого межсетевого экрана построена на базе "умных" модулей-посредников, которые обеспечивают учет специфических особенностей приложений. Напротив, сервер NIAS не перезаписывает адреса, полагая, что все приложения работают без каких-либо специальных требований.

Виртуальные межсетевые экраны и серверы приложений

С точки зрения рассматриваемых в данной статье вопросов важна не только специфика работы клиентской части приложения, но и особенности, присущие серверной стороне. Для многих пользователей доступ к серверам приложений внутренней сети предприятия извне часто бывает не менее важен, чем работа с внешними службами. В этом отношении межсетевые экраны, подобные BorderWare, функционально более развиты по сравнению со шлюзами IP—IPX, например такими, как сервер NIAS.

Обычно клиентские приложения используют порты с номерами выше 1024, поскольку для серверов типично использование номеров ниже 1024. Например, при открытии сеанса доступа к удаленной системе вашему telnet-клиенту будет назначен случайный номер порта выше 1024, в то время как сервер традиционно будет использовать порт 23. Для этих продуктов назначение номера порта внешнему соединению практически несущественно, так как внешним серверам неважно, с какого именно порта получен запрос.

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

С помощью продукта BorderWare можно определить конечные системы для серверных портов, что позволяет иметь во внутренней сети выделенные системы для предоставления FTP-, HTTP- и других услуг. Кроме того, внутренние соединения, так же как и внешние клиентские, осуществляются посредством IP-шлюза. При этом обеспечивается защита от несанкционированного доступа извне, так как внешние системы непосредственно не взаимодействуют с внутренними ресурсами сети, а "общаются" с модулями-посредниками, которые перед пересылкой пакетов во внутреннюю систему переписывают их.

Сервер NIAS предлагает похожий набор услуг, используя совершенно иной принцип. В связи с тем, что IPX-клиенты, по сути, являются "расширениями" IP-стека сервера, им может назначаться любой номер порта, в том числе и номера стандартных серверных портов. Например, пользователь установил на своем ПК HTTP-сервер, тогда драйвер WINSOCK.DLL выдает запрос на прослушивание порта 80. Сервер NetWare обязан будет выполнить этот запрос, если только этот порт уже не назначен другому Web-серверу. Таким образом, любое серверное приложение можно запускать на любой внутренней системе, причем извне это будет выглядеть так, словно приложение запускается на самом сервере NetWare, а не на рабочей станции.

Это можно расценивать и как весьма существенную брешь в системе защиты. Нельзя разрешать пользователям запускать любое, какое им захочется, серверное приложение. Такая проблема не возникнет, если вы будете применять входящие в состав ПО IntranetWare загружаемые NLM-модули для фильтрации IP-трафика и таким образом блокировать доступ извне к соответствующим портам, хотя, конечно, это и не панацея от всех бед. При желании пользователь сможет зарезервировать для Web-сервера порт 8000, но тогда вы опять откроете свою сеть для "вторжения". В больших корпоративных сетях для их надежной защиты необходим настоящий межсетевой экран, который полностью бы блокировал доступ к внутренним ресурсам.

Некоторые дополнения

Помимо технической стороны дела, существуют еще и аспекты управления. Они также влияют на принятие решений по развитию вашей сети, а большинство их обусловлено существованием двух отличных друг от друга архитектур. К примеру, если сервер NIAS поддерживает все имеющиеся в сети ПК, то эта поддержка и относится исключительно к ПК, не более. Большинство программных шлюзов IP—PX, замещающих WINSOCK.DLL, располагают только библиотеками динамической загрузки для Windows 3.x и Windows 95, поэтому для Macintosh, OS/2, Unix, Windows NT или других операционных систем они не обеспечивают подобные услуги.

Также существуют некоторые проблемы совместимости у многих реализаций шлюзов, выполненных на базе замены WINSOCK.DLL. Например, в сетевых средствах Microsoft используется уровень Transport Driver Interface (TDI), предназначенный для пересылки файлов и услуг сетевой печати, независимых от используемого транспортного протокола. Уровень TDI поддерживают всего лишь несколько продуктов, включая и ПО NIAS. Это означает, что данные услуги не всегда могут быть предоставлены пользователям. Опять же, в первых версиях спецификации WinSock не предусмотрена поддержка протокола ICMP — следовательно, пользователи не смогут применить команды ping или traceroute. Чтобы это стало возможным, производитель IP-шлюза должен снабдить свое изделие такими утилитами.

Основным преимуществом данной архитектуры является низкая стоимость самих сетевых продуктов, а также их эксплуатации. Кроме того, вам не нужно управлять стеками TCP/IP каждой системы — для этого вы можете использовать один-единственный разделяемый драйвер WINSOCK.DLL на файловом сервере, к которому Windows-клиенты могут обращаться по мере необходимости. Вы также не будете иметь дело с управлением службой доменных имен или с динамическим протоколом конфигурации хостов и отслеживать конфликты адресов либо решать другие задачи, связанные с управлением и возникающие при запуске полноценных IP-стеков на каждой рабочей станции. Программные продукты с такими преимуществами не теряют популярности долгие годы, особенно там, где не используются сетевые средства фирмы Microsoft.

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

В действительности нет никаких причин для отказа от совместного использования обеих архитектур. Если, имея многочисленную группу пользователей NetWare, вы не можете получить достаточного количества IP-адресов, то для обеспечения их связи с остальным коллективом вашей организации можно применить шлюз IP—IPX. Но для преобразования адресов между вашей внутренней и внешней сетями вместо предоставляемой этим шлюзом возможности использовать "полноценные" IP-адреса серверами NetWare обратитесь лучше к продуктам типа BorderWare. Теоретически при такой комбинации вы сможете поддерживать несколько тысяч пользователей NetWare, ограничиваясь при этом лишь несколькими IP-адресами, причем неважно, являются они легальными или нет.

Независимо от выбранного вами механизма адресации все же лучше использовать легальные IP-адреса, тогда по крайней мере у вас не возникнет проблем с "дублированием" адресов. Если вы не можете получить для всех ваших систем достаточного количества адресов, постарайтесь назначать их из специально выделенных в стандарте RFC 1918 "частных" адресных пулов (см. врезку). Как отмечалось в начале статьи, одна из уважительных причин отказа от использования легальных IP-адресов — наличие в вашей внутренней сети унаследованных систем или приложений, исключающих это. Однако, применяя произвольно назначенные IP-адреса, будьте готовы получить сообщение об отказе в обслуживании при попытке соединиться с узлом, адрес которого совпадает с вашим адресом





  
8 '1997
СОДЕРЖАНИЕ

колонка редактора

• Пираты электронных морей

локальные сети

• Модернизация кабельных систем

• Оптические дисковые системы

• Два плохих модуля

корпоративные сети

• Интервью с вице-президентом компании Bay Networks

• Передовые технологии: Layer 3 Switching (часть I)

• Пограничные коммутаторы АТМ: заранее подготовьтесь к росту сетевого трафика

• Системы удаленного управления

услуги сетей связи

• Анатомия модемных "56К-технологий"

• Полезные и доступные офисные системы речевой почты

• Спутниковые модемы

• Маршрутизаторы ISDN BRI для малого офиса

интернет и интрасети

• Технологии "выталкивания" в информационных службах Интернет

• Microsoft у "последней черты"

• Метаморфозы Интернет

• Разработка Web-приложений с помощью мощных CGI-инструментов

защита данных

• IP-шлюз для "игры в прятки"

новые продукты

• Тестер двухмегабитных потоков "Морион-Е1", RemoteVU: видео по каналу 2,4 Кбит/с, SmartSTACK 10 фирмы Cabletron Systems, NUCLON - третье поколение отечественных СПРВ, Новый мощный Web-сервер фирмы Netscape, Dell PowerEdge 2200

только на сервере

• Novell и Netscape начинают совместный проект

• NT CONPAS - маленький, но мощный

• Stac Replica предотвращает потерю данных



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх