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

Это cписок правил преобразования адресов и портов TCP.

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

Для передачи TCP-соединений из туннеля в локальную сеть.

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

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

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

Название NAT для данного узла сложилось исторически и не вполне соответствует сущности выполняемой процедуры. При работе туннеля в режиме прокси заголовок IP не передаётся, поэтому на принимающей стороне выполняется, по существу, не подмена тех или иных полей IP, а формирование этого заголовка заново. Подменяться может только номер порта назначения в заголовке TCP.

При установлении соединения запрос, полученный из туннеля, проверяется по двум значимым критериям: IP-адресу источника и номеру порта TCP назначения; на сервере, помимо этого, неявно присутствует третий критерий — имя клиента. Далее отвечающее устройство NSG формирует новый запрос на установление локального TCP-соединения и, исходя из этих критериев, должно подставить в него некоторый новый IP-адрес назначения, IP-адрес источника (заданный явно или по умолчанию), и новый порт TCP назначения (если он изменён). Таким образом, пакет IP сформирован заново, и с этими атрибутами запрос и последующие пакеты с данными отправляются дальше в локальную сеть назначения.

Вместо проверки назначения на отвечающей стороне, можно выполнить эту проверку на вызывающей стороне сразу в localListener (там его всё равно надо настраивать) и присвоить соединению некоторый идентификатор. В этом случае на отвечающей стороне анализируется только идентификатор.

Правила NAT могут быть заданы глобально (для всей системы uiTCP на данном устройстве в целом) или локально для отдельного туннеля. При наличии того и другого индивидуальные настройки для туннеля имеют приоритет.

TCP-запрос, полученный из туннеля, проверяется по правилам NAT в порядке их следования в конфигурации. Если пакет не подпадает ни под одно правило NAT для данного туннеля, то он дополнительно проверяется по глобальным правилам NAT. Если пакет не соответствует ни одному правилу, он уничтожается.

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

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

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

ПРИМЕЧАНИЕ. Механизм TCP-прокси в uiTCP не предусматривает контроля за несколькими взаимосвязанными TCP-соединениями, относящихся к одному протоколу (например, FTP). Для передачи трафика таких протоколов следует использовать датаграммные сокеты в режиме виртуальных интерфейсов.

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

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