Инструментарий и ловушки
«Реверс» клиентов
Проблема доступа к клиенту, когда сервера могут инициализировать соединение с клиентом, а клиент с ними нет, обычно разрешается с помощью «реверса» клиентов, при котором клиенты ожидают появления серверов для того, чтобы установить с ними соединение и послать им данные в стиле X-Windows. И действительно, слишком часто кто-то открыто запрашивает режим клиента SSH, для того чтобы разрешить программе sshd подключиться к нему. Подобные решения, если только они с самого начала не были заложены в протокол и его реализацию, в лучшем случае дезинформируют, а в худшем – ужасно небезопасны. Применение для перенаправления SSHD переадресации удаленного порта вместо доступа к Web-сети является уникальным расширением хорошо устанавливаемых и в общем-то безопасных методологий, которые постоянно используются. Внедрение редко используемого клиента в sshd и сервера в ssh является слишком специфичным и совсем необязательным бедствием, которое только выжидает удобный момент для своего свершения.
Сказанное – это прежде всего ответ на постоянный поток запросов, который автор чаще всего наблюдал. (Однако отнеситесь к этому скептически: кто-то попытается свести счеты с половиной способов, изложенных в этой главе, если не во всей книге.)
Эхо на чуждом языке: перекрестное соединение взаимно защищенных межсетевыми экранами хостов
Типовое использование протокола передачи файлов FTP для управления защищенными межсетевыми экранами сетями предусматривает наличие хостов, которые не могут получить соединение и всегда генерируют поток выходящих данных к хосту, который может их получить. (Характеризуя протокол FTP, можно сказать, что, по крайней мере, это несколько странный протокол. Для сохранности своих соединений, упорядоченных в том же самом направлении, необходимо перевести протокол в так называемый пассивный режим (Passive Mode). Пассивный режим протокола FTP предусматривает, что сервер сообщает клиенту номер порта, по которому в случае установления соединения клиент передаст содержимое файла. Напротив, работа в активном режиме (Active Mode) ориентирована на клиента, который ранее инициировал выходящее соединение к серверу и сейчас посылает запрос к серверу для установки сервером выходящего соединения обратно к клиенту по некоторому случайному порту, для того чтобы разместить переданный сервером файл. Межсетевым экранам было сложно работать с одним из грандов старых протоколов Интернета из-за того, что приходилось выполнять сложную подстройку протокола FTP в результате непредсказуемых изменений направлений соединений и номеров портов.) В инструментариях Napster и Gnutella реализованы системы, которые автоматически выясняют, какая из сторон транзакции не может получать запросы на соединение. После чего транзакция создает TCP-соединение, а дальше файл либо проталкивается в канал связи (командой PUT), либо выталкивается из него (командой GET) на хост, который выдал запрос на пересылку файла.
Все хорошо работает в случае, когда одна или другая сторона может получать запросы подключения. Но что произойдет, если ни одна из сторон не сможет этого сделать? Что, если оба хоста расположены позади домашних маршрутизаторов, которые поддерживают возможность сетевой трансляции адресов NAT и им даже присвоены те же самые личные IP-адреса? Еще хуже. Что произойдет, если оба хоста работают за уровнем ядра корпоративного межсетевого экрана Cisco и возникает критическая потребность в интересах дела предоставить двум хостам возможность обмениваться информацией? Как правило, в данном случае усилия администраторов штабов информационных технологий обоих хостов будут направлены на то, чтобы один хост нашел брешь в системе защиты своего межсетевого экрана, что позволило бы другому хосту связаться с первым. Поскольку обязательно произойдет так, что самые параноидные члены штаба информационных технологий настраивают межсетевой экран и управляют им, то в результате будет получен нелепо медленный и болезненный процесс, абсолютно неприемлемый на практике, если только потребность в нем не окажется бесспорной и, возможно, постоянной.
Иногда возможно более изящное решение. Основная идея универсального решения, которое может быть использовано в случае отсутствия непосредственного сетевого соединения, заключается в использовании третьего хоста, так называемого отражателя подключения (connection bouncer). Отражатель подключения получает исходящие от обоих хостов соединения и затем рикошетом отправляет трафик с первого хоста на второй и наоборот.