Менеджер лицензий 1С

Менеджер лицензий 1С: на "переопределенном" интерфейсе

При попытке использовать менеджер лицензий столкнулись с проблемой, что ключ не находится, хотя настройки на клиенте указаны верно:

 [NH_COMMON]
 NH_TCPIP = Enabled
 
 [NH_TCPIP]
 NH_SERVER_ADDR = 11.22.33.44
 NH_TCPIP_METHOD = UDP
 NH_USE_BROADCAST = Disabled
 NH_PORT_NUMBER = 475

Хотя схема была несколько сложнее: клиент также находится за nat'ом, поэтому указывались настройки для внутренней переадресации, - оказалось, что существует проблема даже в таком простом случае, если на сетевой интерфейс сервера назначены разные IP-подсети. Если сравнить вывод ifconfig и ip a, то можно увидеть различие:

 #ifconfig
 ...
 inet      Link encap:Ethernet  HWaddr 00:11:22:33:44:55
         inet addr:11.22.33.44  Bcast:11.22.33.255  Mask:255.255.255.0
 ...

 #ip a
 ...
 inet: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
   inet 11.22.33.44/24 brd 11.22.33.255 scope global inet
      valid_lft forever preferred_lft forever
   inet 22.33.44.55/24 brd 22.33.44.255 scope global inet
      valid_lft forever preferred_lft forever
   inet 33.44.55.66/24 brd 33.44.55.255 scope global inet
      valid_lft forever preferred_lft forever
 ...

То есть на сетевой интерфейс "inet" назначено несколько подсетей и неизвестно, к какой из них "принадлежит" менеджер лицензий. Иными словами когда 1С шлет пакеты на сервер (DST - один из указанных ip), ответ может вернуться с другим SRC. Отсюда вывод: строго не рекомендуется вешать ключ 1С на многосетевое устройство. Впрочем, это официальное заявление от 1С.

Тем не менее хотелось все же получить рабочую схему проброса ключа, поэтому детально опишем результат исследования.

• При работе с UDP 475 не было обнаружено каких-либо посторонних запросов, кроме как по этому порту. Это позволяет написать вполне строгие правила для iptables, чтобы разрешать только то, что нужно.

• С помощью iptables -t filter -A OUTPUT -d <ip_клиента> -p udp --sport 475 -j LOG удается увидеть, с какого ip отправляются пакеты. В системных логах /var/log/messages такие пакеты видны с информацией о SRC.

• Не стоит забывать разрешить эквивалентный LOG'у выход: iptables -t filter -A OUTPUT -d <ip_клиента> -p udp --sport 475 -j ACCEPT на случай, если у вас есть запреты или запрещено по умолчанию.

• В настройках клиента (nethasp.ini) указать именно тот ip, который получен в результате диагностики на предыдущем шаге:

 [NH_TCPIP]
 NH_SERVER_ADDR = 22.33.44.55

В нашем случае он отличался от того адреса, который фигурирует в выводе ifconfig. Не был он и первым в списке ip a. И сказать, на каком основании он выбирался не могу. Отмечу, что попытка подменить источник SRC с помощью правил iptables (POSTROUTING) вместо изменения клиентских настроек тоже не помогла.