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

Это Un-Intrerruptible TCP (uiTCP) — фирменная технология VPN компании NSG.

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

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

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

• По туннелю передаётся полезная нагрузка одного или нескольких TCP-соединений и/или датаграммных потоков. Датаграммные потоки могут включать в себя потоки UDP, потоки произвольных протоколов 4 уровня (в модели OSI) и виртуальные соединения "точка-точка".
• В качестве нижележащего протокола используется TCP. Номер используемого порта TCP на сервере uiTCP считается известным и постоянным.
• uiTCP предполагает построение распределённой системы с большим числом клиентов и, как правило, несколькими серверами (для резервирования и распределения нагрузки). Как частный случай, возможны более простые системы, вплоть до одиночного туннеля "точка-точка".
• Клиентские устройства uiTCP могут использовать любое количество каналов связи любого типа, включая проводные, беспроводные, двухсимчатые сотовые интерфейсы NSG и др., и любые способы подключения, предлагаемые поставщиками услуг — в т.ч. базовую услугу доступа в Интернет с динамическими приватными адресами. Каналы связи могут быть как равноценными, так и более/менее приоритетными.
• Для серверов uiTCP необходимы статические IP-адреса. Сервер может находиться за Destination NAT, но в этом случае в NAT должен быть настроен проброс нужного порта.
• Один и тот же сервер может быть доступен через разные сети по разным адресам (например, через нескольких поставщиков услуг, или через публичный Интернет и через изолированную сеть VPN оператора связи). При переходе между этими адресами туннель сохраняется.
• Клиент инициирует соединение с сервером и контролирует его работоспособность. При наличии установленного туннеля, обмен полезным трафиком может быть инициирован прикладными хостами с любой стороны. В ходе работы туннеля:
  • При разрыве соединения клиент пытается восстановить соединение с этим же сервером по всем доступным каналам связи. При этом TCP-соединения с прикладными хостами на обеих сторонах соединения не разрываются и никакие другие сигналы потери связи не передаются.
  • Если туннель восстановлен, то передача полезных данных возобновляется с того же места, где она фактически прервалась, без потерь, по тем же TCP-соединениям. Таким образом, с точки зрения приложений, потеря и восстановление связи приводят только к паузе в передаче пакетов.
  • Если каналы связи имеют приоритет и туннель работает по одному из резервных каналов, то при восстановлении основного канала uiTCP возвращается на него. Переключение может выполняться немедленно либо откладываться до обнаружения паузы в передаче полезных данных.
  • Если восстановить туннель не удаётся за заданное число попыток (например, авария на сервере или его единственном канале связи), то он считается разорванным окончательно и приём/передача прикладного трафика прекращаются на обеих сторонах (разрываются TCP-соединения, удаляются маршруты через туннель и т.п.). Только в этом неизбежном случае сеанс работы прикладного ПО завершается аварийно с потерей всех не переданных данных. После этого клиент предпринимает попытки установить новый туннель к какому-нибудь из резервных серверов.
  • Клиент поддерживает соединение, по возможности, постоянно и с одним и тем же сервером. Для штатного завершения работы сервера и перевода клиентов на другие сервера с минимальными потерями для прикладных сессий предусмотрена специальная процедура.
• Для аутентификации сторон и защиты трафика используется SSL/TLS на основе асимметричных ключей с сертификатами X.509. Ключи и сертификаты могут генерироваться как на устройстве NSG (самоподписанные), так и сторонним удостоверяющим центром.
• Для передаваемого полезного трафика предусмотрена процедура NAT внутри туннеля.
• Состояние всех туннелей в системе можно наблюдать с помощью Web-интерфейса, в том числе — доступного отдельному пользователю без права входа в командные оболочки NSG. Помимо состояния и статистики собственно uiTCP, в этот же Web-интерфейс могут быть выведены (при помощи обработчика событий и сервера мониторинга NSG) любые другие события на клиентах. C другой стороны, состояния uiTCP могут использоваться как виртуальные датчики для обработчика событий и транслироваться им в любые другие средства мониторинга (SNMP, Zabbix, уведомление по e-mail, светодиодные индикаторы и т.п.).
• Система предусматривает централизованную настройку и мониторинг нескольких серверов, а также централизованное обновление сертификатов на клиентских устройствах.
• Клиенты могут добавляться в систему и удаляться из неё "на лету" без перезагрузки всего сервера.
• Информация о работе системы может выводиться, с требуемой степенью детализации, в локальный файл или во внешнюю SQL-совместимую базу данных.
• C одного клиентского устройства могут быть установлены одновременно несколько туннелей к различным серверам (например, для подключения нескольких банкоматов, расположенных на одной площадке, к различным процессинговым центрам), или несколько туннелей к одному серверу, агрегируемых в одно соединение с увеличенной пропускной способностью.
• uiTCP является фирменной разработкой NSG и требует наличия оборудования под управлением NSG Linux на обеих сторонах туннеля.

ПРИМЕЧАНИЕ. Существующая реализация uiTCP не предназначена для работы в обстановке, когда состояние, характеристики и доступность каналов связи динамично изменяются со временем — в частности, на подвижных объектах.

Чем uiTCP лучше стандартных типов VPN?

Основная суть uiTCP — это универсальный механизм поддержания бесперебойных сеансов работы прикладного ПО и гарантированной доставки данных. Поверх этого механизма могут работать любые приложения, в т.ч. и те, которые изначально предназначены только для работы по абсолютно надёжной локальной сети. Потребность в разработке и применении uiTCP вызвана следующими причинами:

1. При потере связи и переключении на другого оператора происходит не только потеря части данных. Это ещё можно было бы исправить средствами прикладного программного обеспечения. Но в сети нового оператора (и при переподключении к тому же самому — обычно тоже) клиент получает другой IP-адрес и, следовательно, с точки зрения сервера, становится уже другим клиентом. С ним надо начинать сеанс работы заново, по полной программе (аутентификация и т.п.), а старую закрывать по неактивности. В частности, для некоторых типов ПО банкоматов это может означать полную инициализацию всего устройства, и если она выполняется часто, то в сумме это может занимать недопустимо большую часть времени.
2. Стандартные технологии VPN не предусматривают бесперебойной работы приложений при переходе на другой канал связи, переподключении и в других ситуациях, приводящих к изменению IP-адреса клиента. Для них это заканчивается переустановлением туннеля так же, как и описано выше. Как следствие, аварийно завершаются установленные сеансы всех вышележащих уровней (разрываются TCP-соединения, удаляются маршруты и т.п.). Таким образом, стандартные типы туннелей не решают проблему — такая задача перед ними и не ставилась; все они исходят из предположения, что прикладное ПО должно самостоятельно обнаруживать потерю связи и корректно обрабатывать её.
3. Вертикальная интеграция. В стандартных технологиях почти каждая из аппаратных и программных компонент разрабатывалась и функционирует независимо от остальных, на одном определённом уровне протокольного стека: модем, модемная "звонилка", стек TCP/IP, туннели, прикладное ПО. Такой подход — единственно оправданный при разработке абсолютно универсальных технологий Интернет. Но в результате, за отдельными исключениями, они не имеют механизмов для взаимодействия. Когда нижележащая компонента (например, модем) "зависла", они не могут ни обнаружить немедленно сей прискорбный факт, ни рестартовать её, ни просигнализировать вышестоящей компоненте (туннелю, прикладному ПО) о необходимости рестарта. Но жизнь требует этого, так или иначе — и в результате решение обрастает, на практике, разнообразными кустарными скриптами, пинговалками, прерывателями питания и т.п. При этом каждый пользователь вынужден изобретать этот велосипед самостоятельно, не будучи специалистом в этой части и повторяя большинство ошибок своих коллег.
   uiTCP — это не просто очередной тип туннелей, функционирующий на том или ином уровне сетевого стека. Это готовая цельная система, охватывающая все уровни ниже прикладного ПО. Она контролирует работоспособность каналов связи, рестартует их при необходимости, переписывает маршруты с учётом работающих каналов связи на данный момент, контролирует доставку данных.
4. Оперативность реагирования. Каждая из компонент протокольного стека должна самостоятельно установить, что нижележащая часть системы не работает (или работает не так, как раньше), и рестартовать свой сеанс. Сделать это, в отсутствие единых механизмов сигнализации, можно единственным способом: по факту того, что данные или контрольные пакеты (ping, keepalive, dead peer detection и т.п.) не проходят в течение какого-то времени. Причём время срабатывания должно быть разным у разных компонент, чтобы они не дёргались вразнобой. Практическое инженерное правило — на каждом следующем уровне его рекомендуется устанавливать примерно в 3 раза больше, чем на нижележащем. В результате время восстановления работы прикладного ПО может оказаться недопустимо большим.
   uiTCP, в отличие от фрагментарных стандартных решений, контролирует весь программно-аппаратный стек и при необходимости рестартует или переконфигурирует все необходимые компоненты последовательно, снизу доверху: модем, протокол канального уровня, IP-маршрутизацию, сам туннель. В результате время переключения составляет минимально возможное для данной аппаратной конфигурации. В самом сложном случае — при единственном сотовом модеме — оно гарантированно не превышает 60–75 сек.

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

Включить. Далее см. справку по узлу configure и теоретические пояснения по отдельным вопросам:

Принципы и режимы работы uiTCP
Механизм обеспечения бесперебойности
Симметрия и асимметрия в uiTCP
Многотуннельные и многоканальные режимы
Массовая конфигурация клиентов
Маршрутизация на серверной стороне при наличии нескольких серверов
Особенности настройки соединений LTE/3G с 2 SIM-картами
Централизованное управление сертификатами в системе
Централизованная замена сертификатов на клиентских устройствах
Мониторинг uiTCP
Часто задаваемые вопросы

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

1. Смотреть журнал uiTCP на обеих сторонах.
2. Убедиться, что используемые каналы связи функционируют нормально.
3. Убедиться, что сервер uiTCP доступен по сети, используемый порт TCP не запрещён фильтрами, не перехватывается NAT, не занят другими приложениями и т.п.
4. Попытаться зайти с клиента на сервер по Telnet на заданный номер порта. Нормальная ситуация — соединение устанавливается, но дальше остаётся пустой экран (сервер молчит и ждёт приветствия от клиента согласно протоколу). В этом случае отлаживать последующие компоненты туннеля: SSL, передачу полезного трафика на обеих сторонах. Ненормальная ситуация — Telnet-соединение не устанавливается с диагностикой "No reply from server..." или аналогичной. В этом случае см. выше.
5. Убедиться, что на обеих сторонах корректно установлено системное время и сертификаты корректно сгенерированы для этого времени.
6. Попытаться установить простейший туннель с минимумом функций, в т.ч. с отключённым TLS/SSL.
7. Смотреть страницу Web-мониторинга для данного клиента, в т.ч. развернуть список соединений внутри туннеля, по которым передаётся полезная нагрузка (или show.connections).