Основные подходы к организации межсетевого взаимодействия

На первый взгляд выражение «организация межсетевого взаимодействия» может показаться парадоксальным. Действительно, если сети взаимодействуют, значит, их компьютеры связаны между собой и, следовательно, они все вместе образуют сеть. Тогда что же понимается под сетями, взаимодействие которых надо органи­зовать? Понимается ли под этим совокупность компьютеров, которые работают под управлением одной сетевой операционной системы, например Windows NT или NetWare? Или это те компьютеры, которые связаны между собой средства­ми одной и той же базовой сетевой технологии, такой как, например, Ethernet или Token Ring? И наконец, может быть, здесь имеются в виду сети в терминах протокола сетевого уровня, то есть части большой сети, разделенные между со­бой маршрутизаторами?

Ни то, ни другое, ни третье. В контексте межсетевого взаимодействия под тер­мином «сеть» понимается совокупность компьютеров, общающихся друг с другом с помощью единого стека протоколов. Средства взаимодействия компьютеров в сети организованы в виде многоуровневой структуры — стека протоколов. В од­нородной сети все компьютеры используют один и тот же стек. Проблема возни­кает тогда, когда требуется организовать взаимодействие компьютеров, принад­лежащих разным сетям в указанном выше смысле, то есть организовать взаимодействие компьютеров, на которых поддерживаются отличающиеся стеки коммуникационных протоколов.

Проблема межсетевого взаимодействия может иметь разные внешние проявле­ния, но суть ее одна — несовпадение используемых коммуникационных протоко­лов. Например, эта проблема возникает в сети, в которой имеется только одна сетевая ОС, однако транспортная подсистема неоднородна из-за того, что сеть включает в себя фрагменты Ethernet, объединенные кольцом FDDI. Здесь в ка­честве взаимодействующих сетей выступают группы компьютеров, работаю­щие по различным протоколам канального и физического уровня, например сеть Ethernet, сеть FDDI.

Равным образом проблема межсетевого взаимодействия может возникнуть в сети, построенной исключительно на основе технологии Ethernet, но в которой установ­лено несколько разных сетевых ОС. В этом случае все компьютеры и все приложе­ния используют для транспортировки сообщений один и тот же набор протоколов, но взаимодействие клиентских и серверных частей сетевых служб осуществляется по разным протоколам прикладного уровня. В этом случае компьютеры могут быть отнесены к разным сетям, если у них различаются протоколы прикладного уровня, например компьютеры, использующие для доступа к файлам протокол SMB, обра­зуют сеть Windows NT, а компьютеры, использующие для доступа к файлам прото­кол NCP, — сеть NetWare. Конечно, эти сети могут сосуществовать независимо, передавая данные через общие транспортные средства, но не предоставляя пользо­вателям возможности совместно использовать ресурсы. Однако если потребуется обеспечить доступ к данным файлового сервера Windows NT для клиентов NetWare, администратор сети столкнется с необходимостью согласования сетевых служб.

Задачи устранения неоднородности имеют некоторую специфику и даже разные названия в зависимости от того, к какому уровню модели OSI они относятся. За­дача объединения транспортных подсистем, отвечающих только за передачу со­общений, обычно называется internetworking — образование интерсетей. Клас­сическим подходом для ее решения является использование единого сетевого протокола, такого, например, как IP или IPX. Однако существуют ситуации, ко­гда этот подход неприменим или нежелателен, и они будут рассмотрены ниже.

Другая задача, называемая interoperability, возникает при объединении сетей, ис­пользующих разные протоколы более высоких уровней — в основном приклад­ного и представительного. Будем называть это задачей согласования сетевых служб операционных систем, так как протоколы прикладного и представитель­ного уровней реализуются именно этими сетевыми компонентами.

Кардинальным решением проблемы межсетевого взаимодействия могло бы стать повсеместное использование единого стека протоколов. И такая попытка введе­ния единого стека коммуникационных протоколов была сделана в 1990 году пра­вительством США, которое обнародовало программу GOSIP — Government OSI Profile, в соответствии с которой стек протоколов OSI предполагалось сделать уобщим для всех сетей, устанавливаемых в правительственных организациях США. Однако массового перехода на стек OSI не произошло. Тем временем в связи с быстрым ростом популярности Интернета стандартом де-факто становится стек протоколов TCP/IP. Но это пока не означает, что другие стеки протоколов пол­ностью вытесняются протоколами TCP/IP. По-прежнему очень много сетевых узлов поддерживает протоколы IPX/SPX, DECnet, IBM SNA, NetBEUI, так что до единого стека протоколов еще далеко.

Самыми общими подходами к согласованию протоколов являются:

· трансляция;

· мультиплексирование;

· инкапсуляция (туннелирование).

Трансляция

Трансляция обеспечивает согласование стеков протоколов путем преобразова­ния сообщений, поступающих от одной сети в формат сообщений другой сети. Транслирующий элемент, в качестве которого могут выступать, например, про­граммный или аппаратный шлюз, мост, коммутатор или маршрутизатор, разме­щается между взаимодействующими сетями и служит посредником в их «диало­ге». Термин «шлюз» обычно подразумевает средство, выполняющее трансляцию протоколов верхних уровней, хотя в традиционной терминологии Интернета шлю­зом (gateway) называется маршрутизатор.

В зависимости от типа транслируемых протоколов процедура трансляции может иметь разную степень сложности. Так, преобразование протокола Ethernet в протокол Token Ring сводится к нескольким несложным действиям, главным образом благодаря тому, что оба протокола ориентированы на единую адреса­цию узлов. А вот трансляция протоколов сетевого уровня IP и IPX представляет собой гораздо более сложный, интеллектуальный процесс, включающий не толь­ко преобразование форматов сообщений, но и отображение адресов сетей и уз­лов, различным образом трактуемых в этих протоколах.

Трансляция протоколов прикладного уровня включает отображение инструкций одного протокола в инструкции другого, что представляет собой сложную логи­чески неоднозначную интеллектуальную процедуру, которую можно сравнить с работой переводчика с. одного языка на другой. Например, в файловой службе операционной системы NetWare (протокол NCP) определены следующие права доступа к файлу: read, write, erase, create, file scan, modify, access control, super­visory, а файловая служба UNIX (протокол NFS) оперирует совсем другим пе­речнем прав доступа: read, write, execute. Для некоторых из этих прав доступа су­ществует прямое соответствие, для других же оно полностью отсутствует. Так, если клиент NCP назначает право доступа к файлу supervisory или access control, то трансляция этих операций на язык протокола NFS не является очевидной. С другой стороны, в протоколе NCP отсутствует обычное для протокола NFS понятие монтирования файловой системы.

На рис. 10.10 показан шлюз, размещенный на компьютере 2, который согласовы­вает протоколы клиентского компьютера 1 в сети А с протоколами компьютера 3 в сети В. Допустим, что стеки протоколов в сетях А и В отличаются на всех уров­нях. В шлюзе установлены оба стека протоколов.

· Запрос от прикладного процесса клиентского компьютера сети А поступает на прикладной уровень его стека протоколов.

· В соответствии с этим протоколом на прикладном уровне формируется пакет (или несколько пакетов), в котором передается запрос на выполнение услуг некоторому серверу сети В.

· Пакет при­кладного уровня перемещается вниз по стеку компьютера сети А, обрастая заголовками нижележащих протоколов, а затем передается по линиям связи в ком­пьютер 2, то есть в шлюз.

o

· На шлюзе обработка поступивших данных идет в обратном порядке, от протокола самого нижнего к протоколу самого верхнего уровня стека А.

· Затем пакет при­кладного уровня стека сети А преобразуется (транслируется) в пакет прикладно­го уровня серверного стека сети В.

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

Примером шлюза, транслирующего протоколы прикладного уровня, является компонент Windows NT Gateway Services for NetWare (GSNW), который обеспе­чивает клиентам Windows NT прозрачный доступ к томам и каталогам серверов NetWare 3.x и 4.x. Шлюз устанавливается на том же компьютере, на котором ус­тановлен сервер Windows NT. Между шлюзом и сервером NetWare устанавлива­ется связь по протоколу NCP.

Для доступа к файлам NetWare клиенты Windows NT, используя свой «родной» протокол SMB, обращаются к серверу Windows NT, на котором работает шлюз GSNW. Шлюз виртуализирует разделяемые каталоги серверов NetWare: они. выглядят для клиентов SMB точно так же, как и разделяемые каталоги сервера Windows NT (рис. 10.11). Если запрос, поступивший на сервер Windows NT, относится к ресурсам серверов NetWare, то он переадрееуется шлюзу, который транслирует его в понятный для сервера NetWare вид и передает по протоколу NCP соответствующему серверу. При этом шлюз выступает по отношению к сер­верам NetWare как клиент-пользователь.

 

Таким образом, шлюз реализует взаимодействие «многие ко многим».

Достоинство шлюзов состоит в том, что они сохраняют в неизменном виде про­граммное обеспечение на клиентских компьютерах. Пользователи работают в при­вычной среде и могут даже не заметить, что они получают доступ к ресурсам другой сети; Однако, как и всякий централизованный ресурс, шлюз снижает на­дежность сети. Кроме того, при обработке запросов в шлюзе возможны относи­тельно большие временные задержки, во-первых, из-за затрат времени на собст­венно процедуру трансляции, а во-вторых, из-за задержек запросов в очереди к разделяемому всеми клиентами шлюзу, особенно если запросы поступают с большой интенсивностью. Это делает шлюз плохо масштабируемым решением. Правда, ничто не мешает установить в сети несколько параллельно работающих шлюзов.