Шлюз уровня коммутации

Данный шлюз может быть реализован как в виде отдельной компьютерной системы, так и в виде дополнительной функции шлюза прикладного уровня, предлагаемой для некоторых приложений. Шлюзы уровня коммутации не разрешают внешним узлам устанавливать сквозные TCP-соединения с узлами внутренней сети, а вместо этого устанавливают два TCP-соединения: одно между самим шлюзом и внутренним узлом, а второе — между шлюзом и внешним узлом. Если оба соединения установлены, шлюз обычно ретранслирует сегменты TCP от одного соединения к другому, не проверяя их содержимого. Защита осуществляется путем разрешения или запрета тех или иных соединений.

Рис. 7

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

Примером реализации шлюза уровня коммутации является пакет SOCKS. Версия 5 этого пакета описана в документе RFC 1928. В этом документе RFC пакет SOCKS определяется следующим образом.

"Протокол, описанный в данном документе, призван обеспечить каркас для приложений клиент/сервер в доменах TCP и UDP, обеспечивающий удобное и безопасное использование сервисов брандмауэра сети. Протокол концептуально является "прослойкой" между прикладным и транспортным уровнем, поэтому он не обеспечивает сервис шлюза сетевого уровня, например пересылку сообщений ICMP".

В пакет SOCKS включены следующие компоненты.

· Сервер SOCKS, работающий в составе брандмауэра на базе UNIX.

· Библиотека клиента SOCKS, работающая на внутренних узлах, защищенных брандмауэром.

· Адаптированные для использования с SOCKS стандартные приложения клиента типа FTP и TELNET. Реализация протокола SOCKS обычно требует перекомпиляции или перекомпоновки использующих TCP приложений клиента, чтобы последние получили возможность обращения к соответствующим процедурам библиотеки SOCKS.

Если использующему протокол TCP клиенту необходимо установить соединение с объектом, к которому можно получить доступ только через брандмауэр, клиент должен открыть TCP-соединение с соответствующим SOCKS-портом системы, в которой установлен SOCKS-сервер. По умолчанию сервис SOCKS использует порт TCP с номером 1080. Если на запрос об установке соединения получен положительный ответ, клиент начинает процесс согласования для выбора метода аутентификации, проходит аутентификацию в соответствии с выбранным методом, а затем посылает запрос на ретрансляцию. SOCKS-сервер проверяет поступивший запрос и либо устанавливает соответствующее соединение, либо посылает отказ. При использовании протокола UDP выполняются аналогичные действия. По существу, для аутентификации пользователя, который намеревается отправлять и получать сегменты UDP, открывается специальное соединение TCP. Сегменты UDP при этом могут пересылаться до тех пор, пока указанное соединение TCP остается открытым.