Что это такое?

Это настройка службы STunnel.

Зачем это нужно?

Для защиты отдельных TCP-соединений с заданным адресом сервера и портом TCP назначения.

Особенности туннеля STunnel и требования для его создания:

• По туннелю передаётся полезная нагрузка одного TCP-соединения.
• Для сервера STunnel необходим статический IP-адрес. Сервер может находиться за Destination NAT, но в этом случае в NAT должен быть настроен проброс нужного порта.
• Номер порта TCP на прикладном сервере считается известным и постоянным.
• Один экземпляр туннеля на клиенте STunnel может обслуживать многих локальных прикладных клиентов с одинаковым номером порта TCP, а один экземпляр туннеля на сервере — многих клиентов STunnel с одинаковым номером порта. (Но это должно быть предусмотрено также на прикладном сервере).
• IP-адрес клиента STunnel может быть произвольным, в т.ч. динамическим и/или приватным. Клиент может находиться за Source NAT или Masquerading.

Как это настроить?

STunnel — технология туннелирования 4 уровня (в терминах модели OSI), предназначенная для защиты индивидуальных TCP-соединений. Она принципиально асимметрична и подразумевает постоянное разделение ролей между вызывающим хостом (прикладным клиентом) и отвечающим хостом (прикладным сервером). Связка из клиента и сервера STunnel, находящихся на границе одной и другой корпоративной подсетей, соответственно, с сетью общего пользования, всегда выполняет роль TCP-прокси между ними.

Когда клиенту некоторого протокола, работающего поверх TCP, необходимо обратиться к серверу через небезопасную сеть, то процедура разбивается на 3 последовательных соединения:

1. Прикладной клиент обращается, вместо удалённого сервера, к локальному клиенту STunnel по адресу и некоторому номеру порта TCP назначения (например, 80 — HTTP). Участок сети между прикладным хостом и клиентом STunnel считается безопасным по определению: он проходит внутри одного сегмента корпоративной сети или даже внутри одного физического хоста.
2. Клиент STunnel принимает соединение на этом порту и устанавливает новое TCP-соединение с сервером STunnel через публичную сеть, по тому же или другому номеру порта TCP (например, 443 — HTTPS).
3. Сервер STunnel принимает это соединение и устанавливает третье соединение со своего внутреннего адреса на адрес прикладного сервера. Участок сети между ними, как и в п.1, предполагается априори безопасным. Номер порта TCP назначения в этом соединении может, в общем случае, как совпадать с портом, использованным в первом (что наиболее логично) или втором соединении, так и отличаться от них.

Смысл всей этой эстафеты в том, что на втором этапе задействуется TLS (изначально SSL) — универсальный механизм, лежащий в основе многих безопасных технологий: HTTPS, OpenVPN и др. Пакеты прикладного протокола (HTTP и др.), извлечённые из TCP, шифруются и уже в зашифрованном виде заново инкапсулируются в TCP для передачи по второму этапу. При передаче эстафетной палочки со второго этапа на третий действия выполняются в обратном порядке.

Для защиты данных при передаче через публичную сеть используется асимметричная пара ключей RSA, подтвержденная сертификатом X.509. Для сервера STunnel наличие ключа и сертификата является обязательным по существу данной технологии. Для клиента STunnel они опциональны, в зависимости от того, с какими настройками (требовать ли аутентификации от клиента или нет) работает сервер.

Поддержка STunnel в NSG Linux реализована на основе стандартного пакета STunnel и настраивается в терминах файла stunnel.conf. Подробно обо всех возможных опциях см. man pages по stunnel.

Настройка соединений STunnel выполняется в узле tunnels при помощи наиболее существенных параметров файла stunnel.conf. Туннели могут создаваться как пользователем вручную, так и системой автоматически при включении определённых служб (например, HTTPS). Любые дополнительные параметры могут быть добавлены через узел extra-options.

Что делать, если это не работает?

1. Смотреть фактический файл конфигурации STunnel, сформированный на основе ваших настроек, и журнал работы данной службы.
2. Проверить доступность, попарно, всех смежных элементов вышеописанной цепочки друг для друга.
3. Убедиться, что используемые адреса и порты TCP не заблокированы фильтрами, не заняты другими службами, не перехватываются и не переназначаются NAT и т.п.

Уникальная идентификация клиентов SSL

В некоторых прикладных решениях имеется необходимость в том, чтобы прикладной сервер идентифицировал своего клиента, например, по заранее известному IP-адресу. Если же такое соединение пропускается через туннель STunnel, то уникальность клиента теряется: STunnel работает как прокси и все соединения с прикладным сервером исходят с внутреннего адреса сервера STunnel. Это принципиальная особенность данного типа туннелей, поскольку они работают на 4 уровне протокольной иерархии и могут произвольно манипулировать нижележащими уровнями. Соединения от сервера STunnel к прикладному серверу различаются только номером порта TCP источника, который выбирается системой случайным образом и никакой полезной информации о том, какой именно клиент работает по данному соединению, не содержит.

Сохранить уникальность клиентов можно следующими способами:

1. Использовать уникальные идентификаторы прикладного уровня — такие, как POS ID в банковских системах, имя/пароль клиента и т.п.
2. Настроить для каждого клиента STunnel уникальный номер порта TCP назначения на сервере STunnel (параметр connect), а на сервере STunnel — соответствующий входящий порт (accept) и уникальный порт назначения на прикладном сервере (connect). Таким образом, каждый прикладной клиент будет попадать в строго определённый порт на сервере. Отметим, что настройка портов назначения на прикладных клиентах и входящих портов на клиентах STunnel при этом может быть единообразной для всех клиентских площадок.
   Недостаток такого варианта — его трудоёмкость и, соответственно, вероятность человеческих ошибок.
3. Теоретически, для сервера STunnel предусмотрена специальная опция transparent = yes, позволяющая передать в соединение с прикладным сервером, в качестве IP-адреса источника, публичный IP-адрес клиента STunnel. Таким образом, прикладной сервер видел бы каждого клиента по уникальному IP-адресу. Однако эта функциональность не может являться стандартной, поскольку противоречит фундаментальным принципам построения сетей IP; по этой причине она отсутствует в реализациях STunnel для Windows, а в реализации для Linux требует включения специальных опций при генерации ядра. В данной версии NSG Linux она не реализована.
4. Использовать более развитые варианты VPN на основе SSL, предусматривающие передачу пакетов IP третьего уровня поверх туннеля 4 уровня. В ним относится, в частности, OpenVPN.