|
Вообще, как я понимаю, соединение по стандартному порту через AOS Manager происходит примерно как в случае с ICQ - через сервер, который "говорит" клиентам, по какому адресу и порту реально находится нужная им служба. AOS Manager (ax32mgr) висит на 0.0.0.0:2712 (т.е. слушает все интерфейсы); сервера AOS (ax32serv) висят на интерфейсе по умолчанию на произвольных портах, при этом AOS Manager знает, на каких. Клиент соединяется с сервером, обслуживающим подключения (AOS Manager), тот, к примеру, по маске имени выдает ему IP-адрес и порт, на котором висит нужный сервер AOS, клиент отсоединяется и подключается уже напрямую по этому адресу и порту. Так вот, появилась такая догадка, что дело может быть в роутинге. По крайней мере, именно такая ситуация у меня воспроизвелась с использованием vmware.
К примеру, на хосте с сервером AOS есть два интерфейса с адресами 192.168.1.1 (1-й сетевой интерфейс, верхний в списке привязки служб и протоколов, о котором писал AndyD) и 192.168.2.1 (2-й, в моем случае - виртуальный сетевой адаптер vmware), у виртуальной машины-клиента один интерфейс с адресом 192.168.2.2 и маской 255.255.255.0. Если посмотреть, кто на каких интерфейсах слушает на сервере, то увидим, что ax32mgr висит на 0.0.0.0, а ax32serv висит на 192.168.1.1. Я прописал на виртуальной машине-клиенте "левый" шлюз, в результате чего ни ping, ни, соотв., tracert достучаться до 192.168.1.1 не могли, а при попытке запуска на нем клиента Axapta он "зависал". Но если прописать нормальный шлюз или вручную - нужное правило роутинга для подсети 192.168.1.0/255.255.255.0, чтобы адрес 192.168.1.1 стал пинговаться, то клиент сразу находит AOS.
|