...

Приоткрывая завесу

Квитирование установления связи: всего лишь брокер подключения

Рикошет всего соединения может стать причиной превращения отражателя подключений в опасное узкое место, потому что в любом направлении он должен видеть весь трафик дважды: один раз – при получении пакетов и еще один раз – при отсылке их обратно. По этой причине интерес к отражателю подключений отсутствует даже со стороны наиболее амбициозных проектов соединения равноправных узлов хостов P2P (peer-to-peer – соединение равноправных хостов (узлов)). Существуют сугубо экспериментальные системы, которые позволяют находящимся посередине соединения хостам запросто становиться брокером подключения (broker the connection). Брокеры подключения предоставляют двум хостам, запрашивающим выходящие линии связи, средства склеивания друг с другом. Подобные методы описаны в конце главы 12 и их полная работоспособность везде и всегда не гарантируется (авторы разработали их только во время написания книги). Напротив, приведенные ниже методы более работоспособны и надежны.

В общем случае проксисервера являются разновидностью отражателя подключения. Запрос на выходящее соединение перенаправляется по направлению отсылки ответного сигнала входящего соединения от удаленного Web-сервера или что-то в этом роде. В данном случае это не всегда полезно. Существуют небольшие приложения, которые делают из сервера отражатель подключения, но логика их работы слегка запутана, и они не всегда переносимы. Кроме того, почти всегда они не поддерживают криптографических возможностей, которые пусть не всегда нужны, но полезно, когда они есть под рукой.

К счастью, в данном случае нет необходимости ни в том, ни в другом. Если читатель вспомнит, то сначала была описана система с клиентом, который не мог непосредственно инициировать соединение с сервером. Вместо этого для создания сквозной безопасной линии связи по протоколу SSH клиент подтверждал свою подлинность хосту-бастиону и использовал сетевой путь, доступный ему благодаря бастиону. Затем была описана система, в которой для подключения клиента хост-бастион уже не предусматривался. Сервер самостоятельно инициировал свое собственное соединение с внешним миром, экспортируя при помощи переадресации удаленного порта путь клиенту для того, чтобы он проложил к нему обратный туннель. Так получилось, что этот путь был экспортирован непосредственно клиенту, хотя в этом не было необходимости. На самом деле сервер мог бы использовать переадресацию удаленного порта своему собственному SSH-демону на любом хосте, который был бы доступен как серверу, так и клиенту. После этого клиенту было бы достаточно просто обратиться к этому доступному как со стороны сервера, так и со стороны клиента хосту, который внезапно стал хостом-бастионом. Ниже рассмотрено объединение двух названных методов в один:

# Server: Export link to a mutually accessible “floating

# bastion server”

[effugas@localhost effugas]$ ssh -R20022:127.0.0.1:22

effugas@10.0.1.11

effugas@10.0.1.11’s password:

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3

13:44:59 GMT 2001

$

# Client: Import link from the mutually accessible

# “floating bastion server” (not using netcat,

# because we’re assuming zero software installation

# for this host)

effugas@OTHERSHOE ~

$ ssh -L30022:127.0.0.1:20022 effugas@10.0.1.11

effugas@10.0.1.11’s password:

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3

13:44:59 GMT 2001

$

# Client: Initiate a connection over the imported/

# exported link, verifying the endpoint goes where we

# think it does.

effugas@OTHERSHOE ~

$ ssh -o HostKeyAlias=10.0.1.10 -p 30022 effugas@127.0.0.1

Enter passphrase for key “/home/effugas/.ssh/id_dsa”:

Last login: Mon Jan 14 12:00:19 2002 from 10.0.1.56

[effugas@localhost effugas]$

Загрузка...