VMware problem

Инсталлировал SQL и AXAPTA 3 .. 5 на VMware (Win2003 Server) в трехзвенке. Работает нормально, клиенты коннектятся из VMware.

Но клиенты из внешней сети (XP sp2) не могут обнаружить AOS.

Ping до vmware доходит. По айпишнику на виртуальный комп (и его диск) захожу.

Подскажите, в чем может быть проблема?

[gl00mie]

Цитата:

Сообщение от otkudao

Работает нормально, клиенты коннектятся из VMware.
Но клиенты из внешней сети (XP sp2) не могут обнаружить AOS. Ping до vmware доходит. Подскажите, в чем может быть проблема?

А как у вас настроена сеть для виртуальной машины? У VMware есть вроде разные способы подключения виртуальной машины к сети: NAT, host-only, bridged. Проблема обнаружения клиентами из внешней сети AOS'а на виртуалке может возникать, есть сеть для нее настроена через NAT. Обнаружение ведь вроде проиcходит за счет ответов от сервера, получаемых на широковещательный UDP-запрос, посылаемый клиентом, а широковещательные UDP-запросы через NAT, я так понимаю, не проходят. Поэтому надо поменять настройки сети для виртуалки на bridged и указать в настройках сетевухи в виртуальной машине IP-адрес из той же подсети, в какой находится vmware host, чтобы виртуалка, а вместе с ней и AOS, могла получать широковещательные UDP-запросы.
Да, если дело не в том, что AOS не появляется в списке серверов, а в том, что клиенты из внешней сети даже по явно указанному IP не могут к нему подключиться, что дело, скорее всего, в маршрутизации. Допустим, у вас IP-адрес 192.168.0.100/24, а у виртуальной машины - 192.168.1.100/24, и она подключена к сети через NAT. Тогда, чтобы другие машины могли подключиться к AOS'у, у них должен быть происан роутинг типа

PHP код:

route add 192.168.1.100 mask 255.255.255.255 192.168.0.100 metric 1 


чтобы они знали, что весь трафик для AOS'а должен идти через ваш vmware host. Но прописывать на каждом клиенте статический роутинг - нудная задача, лучше подключить виртуалку к сети по предыдущему варианту.

судя по тому, что у виртуалки свой ip-адрес и для доступа не используется номер порта, NAT у нас не используется (так меня проконсультировали).

Остальное буду читать основательно чуть позже.

Нашел указание, что MDAC-и должны совпадать, проверяю утилитой ComponentChecher - на клиенте XP пишет MDAC 2.8 SP1, на виртуалке (Win Server 2003 R2 SP 2 StandardEdition) - UNKNOWN. Вроде как в WinServer должен быть установлен MDAC, но чекер его не показывает.

Может быть здесь проблема? Как выявить несовпадение MDAC-ов?

[gl00mie]

Цитата:

Сообщение от otkudao

Ping до vmware доходит.

пинг доходит с vmware host или с другой машины в сети?

Цитата:

Сообщение от otkudao

судя по тому, что у виртуалки свой ip-адрес и для доступа не используется номер порта, NAT у нас не используется.

дело не в используемом номере порта, а в том, чтобы IP-адрес виртуалки был в той же подсети, в какой и vmware host.

Цитата:

Сообщение от otkudao

Как выявить несовпадение MDAC-ов?

Проще всего, наверно, посмотреть на номера версий файлов: Administrative Tools/Data Sources (ODBC), там на вкладке Drivers и About это написано. На счет использования Ms SQL была интересная заметка: Подключение к Юкону родным ODBC драйвером. Последнюю версию SQL Native Client можно взять из дистрибутива SQL Server 2005.

Цитата:

пинг доходит с vmware host или с другой машины в сети?

с другой машины

да, клиент SQL Server-a находит SQL Server на виртуалке. Осталось клиента аскапты с AOS подружить.

Насчет подсети - виртуалка не в домене, соединяли через Hosts клиента. Чтобы клиент SQL до своего сервера достучался.

[gl00mie]

Цитата:

Сообщение от otkudao

да, клиент SQL Server-a находит SQL Server на виртуалке. Осталось клиента аскапты с AOS подружить.

А вот это уже интересно... Стало быть, дело именно в AOS?

Цитата:

Сообщение от otkudao

Насчет подсети - виртуалка не в домене

В этом случае с 4-кой и 5-кой могут быть некоторые сложности при подключении (Как дать доступ к Аксапте внешним пользователям?), но 3-ка же должна работать по-любому. Вообще, такие вопросы достаточно удобно диагностировать с помощью Network Monitor'а; еще есть NM OneClick - версия, которая запускается, ставит необходимые драйверы, осуществляет захват трафика в соответствии с настройками и затем сносит себя без следа. Достаточно поставить его на виртуальной машине, запустить захват трафика, попытаться соединиться с AOS и потом, отфильтровав трафик по порту, на котором он висит, посмотреть, смог ли клиент достучаться до AOS'а или нет.

Цитата:

Сообщение от otkudao

соединяли через Hosts клиента. Чтобы клиент SQL до своего сервера достучался.

К слову, если виртуальная машина не в домене и не может сама прописаться на DNS-сервере, можно это сделать за нее (создать А-запись) - тогда не понадобится править файл hosts на каждом клиенте в домене.

клиент из-под VMWare-машины (копии VMWare-машины сервера аскапты), запущенный на том же хосте, что и серверная виртуалка, коннектится к серверу на ура.

[gl00mie]

Цитата:

Сообщение от otkudao

клиент из-под VMWare-машины (копии VMWare-машины сервера аскапты), запущенный на том же хосте, что и серверная виртуалка, коннектится к серверу на ура.

Да это не интересно абсолютно Вам же надо, чтобы с реальных компов клиенты заходили - вот и надо разбираться, почему у них это не получается. А объяснение успешного захода клиента с другой виртуалки может быть такое.
4-я и 5-я (2009-я) Аксапта при подключении к AOS'у использует RPC с опциями NTLM-аутентификации и проверки целостности данных. Способ аутентификации, возможно, зависит от настроек доменной/локальной политики безопасности, мне попадалась именно NTLM. Соотв., в ходе подключения по RPC идет «2-хуровневая» аутентификация на AOS'е: во-первых, винда проверяет, имеет ли право пользователь, под которым запущен клиент Аксапты, инициирующий соединение, подключаться к хосту AOS'а по RPC; во-вторых, сам AOS проверяет, есть ли SID, передаваемый клиентом в ходе подключения, в табличке UserInfo, и активен ли соотв. пользователь DAX, прописанный там с этим SID.
Что произойдет, если сделать клон машины, на которой стоит AOS (при условии, что эта машина не является доменным контроллером или даже что она вообще не в домене) и попытаться подключиться с нее к AOS: кроме прочего, у пользователей склонированной машины окажутся те же SID'ы и те же хэши паролей, что и у пользователей исходной машины, чего при обычной установке виндов на два компа по отдельности добиться нельзя. В результате хост с AOS'ом будет доверять этой машине-клону как себе и ее пользователям - как своим (покуда у них будут те же пароли). Так что этот пример с клоном виртуалки ничего не доказывает. Вот поставьте на новую виртуалку винды с нуля и тогда попробуйте подключиться клиентом DAX к вашему AOS'у - увидите, что "виртуальность" машины клиента никак успеху этого мероприятия не способствует.

2 gl00mie

попытался разобраться в том обилии информации и новых для меня терминов, которые были предоставлены.

Итак,

- виртуалка подключена под bridge; Ip хоста 10.ХХХ.75.17, ip VmWare - 10.ХХХ.75.15, то есть они в одной подсети

- MDAC версии :
"версий файлов: Administrative Tools/Data Sources (ODBC), там на вкладке Drivers и About это написано." - ЭТО в Драйверах "SQL native Client" и "SQL Server"? Но после успешного наката новой инсталляции MDAC ДАТА в этой таблице не поменялась... Я так понимаю, что это дата инсталляции. Я правильно смотрю?

- "отфильтровав трафик по порту, на котором он висит, посмотреть, смог ли клиент достучаться до AOS'а или нет."

я без утилит вижу, что клиент до AOS не достучался. Мне бы диагноз поставить, почему. А утилиты этого не показывают (или я не знаю, куда смотреть , подскажите, пожалуйста. Использую Network Monitor'а + NM OneClick )

[gl00mie]

Цитата:

Сообщение от otkudao

- виртуалка подключена под bridge; Ip хоста 10.ХХХ.75.17, ip VmWare - 10.ХХХ.75.15, то есть они в одной подсети

Замечательно, значит, проблем с NAT и тому подобным быть не должно. Скажу наперед, что скорее всего понадобится-таки включить виртуальную машину в домен...

Цитата:

Сообщение от otkudao

- MDAC версии - ЭТО в Драйверах "SQL native Client" и "SQL Server"?

Да, только для использования SQL Native Client нужна отдельная настройка в конфиге, иначе будет использоваться драйвер SQL Server 2000. Для 3-ки в конфиге должно быть прописано: sqlparm,Text,DRIVER={SQL Native Client}

Цитата:

Сообщение от otkudao

Но после успешного наката новой инсталляции MDAC ДАТА в этой таблице не поменялась... Я так понимаю, что это дата инсталляции. Я правильно смотрю?

Отображаемая там дата - это дата последней модификации файла.

Цитата:

Сообщение от otkudao

- "отфильтровав трафик по порту, на котором он висит, посмотреть, смог ли клиент достучаться до AOS'а или нет."
я без утилит вижу, что клиент до AOS не достучался.

Не... без утилит видно, что клиент не подключился, а вот по какой причине не подключился - это надо выяснить: не нашел сервер по доменному имени, или нашел, но не смог достучаться по TCP, или смог, но не смог подключиться по RPC, или смог подключиться, но был послан AOS'ом... Под "достучать" я понимаю наличие соединения по TCP.

Цитата:

Сообщение от otkudao

Мне бы диагноз поставить, почему. А утилиты этого не показывают (или я не знаю, куда смотреть Использую Network Monitor

Во-первых, при захвате трафика либо при его последующем просмотре надо поставить фильтр, чтоб не видеть не относящейся к делу ерунды. Фильтр ставится по порту TCP, чтобы видеть только трафик между клиентом и AOS'ом, и по наличию данных в TCP-пакете, чтоб не видеть всякие служебные TCP-пакеты. Фильтр должен выглядеть примерно так: TCP.Port==2712 && TCP.TCPPayload. посмотрим, как примерно выглядит результат успешного (на первый взгляд ) и неуспешного подключения к AOS'у после применения фильтра.
При подключении по RPC с NTLM-авторизацией сначала идут три пакета: Bind (от клиента к серверу), Bind Ack (от сервера к клиенту) и Bind Resp (от клиента серверу; в последних версиях NetMon его обозвали Auth3). На этом этапе собственно происходит challenge-response авторизация клиента на хосте AOS'а с использованием NTLM. Затем клиент посылает запрос (RPC-пакет типа Request) той службе, к которой он по RPC попытался подключиться. При неуспешном подключении по причине невозможности авторизоваться по RPC (скорее всего, у вас картина будет именно такая, если клиенты могут достучаться до AOS'а) вместо RPC-пакета с ответом (Response) он получает RPC-пакет с типом "ошибка" (Fault), в статусе которого может быть указано, по какой причине произошла ошибка. В приведенном примере статус 0x00000005 по всей видимости означает "отказано в доступе".


В случае успешной авотризации при установлении RPC-соединения клиент получит в аналогичной ситуации ответ от службы, к которой он подключился, в виде RPC-пакета типа Response.

Здесь уже в дело вступает непосредственно RPC-интерфейс, используемый клиентом и сервером, без знания конкретики которого с помощью NetMon'а разобраться будет сложно. Но применительно к Аксапте мы, по крайней мере, получим «внятное» сообщение об ошибке, типа "unable to logon" или что-то в этом духе.