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

Это список локально открытых TCP-сокетов.

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

Чтобы принимать TCP-соединения из локальной сети и ретранслировать их в туннель.

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

Объекты localListener создаются на вызывающем устройстве и предназначены для приёма входящих TCP-соединений от приложения-клиента. Они определяют, какие пакеты готова принимать служба uiTCP, чтобы отправить их в туннель. (TCP-соединение внутри туннеля, несущее полезную нагрузку, именуется логическим каналом — LC.) На отвечающем устройстве должны быть настроены парные к ним правила NAT — они определяют, как дальше отправлять пакеты, полученные из туннеля, через локальную сеть на той стороне к прикладному серверу.

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

Для добавления TCP-сокетов используйте команды +, _new или _insert. Данный список является нумерованным и упорядочивается автоматически. Для удаления используйте команду - или _remove.

ВНИМАНИЕ! Для того, чтобы туннель мог передавать пользовательские данные в режиме TCP-прокси, необходимо настроить, как минимум:

• На вызывающей стороне — один localListener; в противном случае устройство NSG не будет принимать никакие пакеты из локальной сети.
• На отвечающей стороне — одно правило NAT, под которое будут подпадать эти пакеты; это правило должно содержать, как минимум, IP-адрес вызываемого прикладного хоста, поскольку исходный IP-адрес назначения (локальный адрес вызывающего устройства NSG) уже не имеет никакого смысла в отвечающей сети.

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

1. Убедиться по журналу uiTCP, что туннель установлен нормально.
2. Проверить в журнале вызывающей и отвечающей стороны записи о входящем соединении от прикладного клиента, установлении логического канала (LC) в туннеле и исходящем соединении к прикладному серверу, соответственно.
3. Проверить, что вызывающее устройство NSG доступно по локальной сети с вызывающего прикладного хоста (клиента), что используемый порт TCP не закрыт фильтрами, не занят другими приложениями и т.п.
4. Если соединение не устанавливается, или устанавливается, но при отсутствии активности в течение некоторого времени разрывается, несмотря на нормальную работу туннеля — обратить внимание на механизм TCP keepalive в прикладных соединениях с обеих сторон.