none
ISA-сервер блокирует RPC RRS feed

  • Вопрос

  • Помогите, пожалуйста, с проблемой.

    У меня есть ISA-сервер 2006 IP 192.168.0.3 и внешним 10.10.10.10. На этом же сервере стоит Exchange.

    Есть DC1 =AD+DNS+DHCP (192.168.0.1). И резервный DC2=AD+DNS+DHCP (192.168.0.2).

    Все работало хорошо. Но в выходные пришлось выключить сервера на 2 днй. С утра, когда я пришел и всевключил, я начал фикстировать в событиях ISA-сервера ошибки:

    Netlogon 5719:

    Компьютер не может установить безопасный сеанс связи с контроллером домена Domen по следующей причине:

    Сервер RPC недоступен.

    и за ней ошибка

    Компьютер не может установить безопасный сеанс связи с контроллером домена Domen по следующей причине:

    Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.

     

    Далее сервер не может проверить подлинность соединений, отваливается интернет и почта. К ISA нельзя соединиться по RDP. Причем, соединения уже установленные (например, ICQ или если до этого соединился по RDP установлено). Кроме того, соединения из внешней сети к компьютерам во внутренней сети (по RDP, например) проходят, но к самому ISA-серверу не идут.

    Я Проверил сетевые карты, обновли драйвера, прошелся dcdiag, netdiag. Все работает. Попробовал выгнать из домена компьютер, сбросить его запись  в AD и обратно вогнать. 

    Тогда я подумал, что если с сетью все впорядке, то скорее всего сама ISA блокирует. сединения (хотя странно. Я же не создавал новых правил, не изменял никаких настроек вот уже несколько недель).

    Попробовал сделать тестовое правило, разрешающее все соединения по всем протоколам и ото всех сетей ко всем и все начало работать.

    Но теперь я не знаб даже уда смотреть. По идее, системный правила ISA должны разрешать RPC-запросы, чтои происходило раньше. Почему сейчас этого не происходит - я не знаю.

    Подскажите, почему ISA может начать блокировать обращения по RPC и, наверно, к GC.

     

    Спасибо.

     

     

    14 июля 2010 г. 6:34

Ответы

  • В общем проблема заключалась в том, что внутренние DNS-сервера были настроены на пересылку к DNS-провайдерам, но в какой то момент почему то начали посылать запросы не только к DNS провайдера, но еще и к какм-то DNS, которые я не настраивал, т.е. получалось,  DNS-запросы шли к левым серверам и ISA их отбрасывала (т.к. правила ISA разрешали запросы только к провайдеру), после чего возникала указанная ошибка.

    Для решения проблемы на внутренних DNS-серверах в свояствах на вклдаке Пересылка установил галочки "Не использовать рекурсию для данного домена". После этого вроде проблема исчезла.

    • Помечено в качестве ответа Goblany 19 ноября 2010 г. 5:43
    19 ноября 2010 г. 5:43

Все ответы

  • проверяйте системную политику (политики -изменить системную политику - службы проверки подлинности - уберите галку требовать строго соответствия РПЦ)
    у вас созданно какое-нибудь правило доступа откуда/куда локальный компьютер откуда/куда внутренняя сеть по всем протоколам?? если да, проверьте фильтр РПЦ в этом правиле.
    • Помечено в качестве ответа Goblany 14 июля 2010 г. 12:59
    • Снята пометка об ответе Goblany 14 июля 2010 г. 13:00
    14 июля 2010 г. 12:45
  • проверяйте системную политику (политики -изменить системную политику - службы проверки подлинности - уберите галку требовать строго соответствия РПЦ)
    у вас созданно какое-нибудь правило доступа откуда/куда локальный компьютер откуда/куда внутренняя сеть по всем протоколам?? если да, проверьте фильтр РПЦ в этом правиле.

     

    Галочка строгого соответствия убрана давно. Ее там нету.

    Такого правила нету.

     

    Я так понимаю, что жля RPC дополнительно не надо делать никаких дополнительный правил. Что это в системной политике должно быть разрешено .

    14 июля 2010 г. 13:02
  • проверяйте тогда 22 системное правило.
    14 июля 2010 г. 13:07
  • Там стоит RPC(все интерфейсы) от локального компьютера во внутреннюю сеть всем пользователям в любое время.

    В свойствах протокола RPC(все интерфейсы) должен RPC-фильтр должен быть включен?

     

    У мен яесть правило отдельное, разрешающие RPC(все интерфейсы) от локального компьютера во впутреннюю сеть. В нем надо включать требовать строгого соответствия RPC в настройках RPC. Или это правило не влияет ни на что, т.к. действуют системные политики?

    14 июля 2010 г. 13:16
  • фильтр должен быть выключен везде. вы делали тестовое правило, в котором разрешали все всем, соотв, что то блочит РПЦ. у меня проблема была между КД, которые не могли реплицироваться по впн, пока я не снял на обоих исах фильтр РПЦ.
    14 июля 2010 г. 13:28
  • Я делаю тестовое правило и все работает. в тестовом правиле правой кнопкой - Настроить протокол RPC - стоит галка Требовать строгого соответствия RPC.

     

    А вот снимать фильтр RPC, так как вы делали, это где надо?

    14 июля 2010 г. 13:39
  • так вот, эту самую галку я и убираю. а каким по порядку вы ставите свое тестовое правило??
    14 июля 2010 г. 13:44
  • Самое первое в списке моих правил. И тогда с этой галочкой все работает.

     

    Я просто немного не понимаю. Ведь RPC-запросы должны идти не за счет моих правил? А за счет системных? Т.е. сейча да. Я Создал правило дополнительное и все арботает, но почему не работает без этого (и раньше проблем не было).

    14 июля 2010 г. 13:47
  • думаю, у вас есть запрещающее правило. для эксперимента, поставьте свое тестовое самым последним и проверьте, будет ли работать. а вообще можно ведь еще запустить мониторинг и посмотреть, где блочится протокол.
    14 июля 2010 г. 14:07
  • В том то и дело, что уже дано никаких изменений на сервере не делал и новых правил не делал и не изменял старые.

    Если посмотреть в мониторинге: ставлю IP-адрес источника равно 192.168.0.3 (ISA-сервер). Начинаются блочиться:

    порт 1947 назначение 255.255.255.255

    порт 1025 газначение 192.168.0.1 (AD)

     

    Через некаторое время (через несколько минут) блочиться 398 Ldap (Все интерфейсы). Причем, просто соединение в мониторинге отмечено красным цветом, а столбец "првило"- пустой.

     

    Т.е. я не вижу чтобы какоето правило блочило соединение.

     

     

    14 июля 2010 г. 17:17
  • Добавлю.

    Когда я начинаю видеть отклоненные соединения в мониторинге от ISA-сервера к серверу AD

    (т.е. когда ISA-счервер обращается к серверу AD и к глобальному каталогу):

    1) Порт 3296 - LDAP GC(Глобальный каталог)

    2) Порт 135 RPC (Все интерфейсы)

    3) Порт 389 LDAP

     

    То в столбуе ПРАВИЛО пусто. В столбце КОД РЕЗУЛЬТАТА cообщение:

      0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED

     

    14 июля 2010 г. 18:02
  • так вы попробуйте тестовое правило поменять местами.
    15 июля 2010 г. 5:35
  • Я уже запутался...

    Значит если я ставлю тестовое правило, разрешающее все ото всех сетей во все всем, то все работает нормально.

    Причем, я начинаю делать мониторинг от ISA-сервера с IP 192.168.0.3 и смотрю куда он лезет. Он обращаетяс к AD 192.168.0.1 но в списке правил, которые разрешают это соединение, я не вижу моего тестовое... Т.е. я вижу, что соединение разрешено, но она разрешено системным правилом.

    Тогда если я отключаю тестовое правило, ISA начинает блокировать соединения. Опять же, правило которое блокирует в мониторинге не высвечивается, а в коде состояния пишет "  0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED".

     

    Если я понимаю правильно логику ISA, то RPC-запросы, LDAP-запросы должны работать и без моих правил. Все это должны отрабатывать систеные правила. Почему влияет на чтото моя правило, мне не понятно.

    15 июля 2010 г. 6:07
  • вот посмотрите, перечисленно несколько решений.

    http://social.technet.microsoft.com/Forums/ru-RU/isaru/thread/e2cfc4c9-b2ef-4222-a5d1-437d5c77eb30

    • Помечено в качестве ответа Goblany 16 июля 2010 г. 5:27
    • Снята пометка об ответе Goblany 19 июля 2010 г. 4:42
    15 июля 2010 г. 8:37
  • levii, спасибо за помощь. Ваши ссылки и советы не совсем подошли к моей ситуации, но тем не менее они натолкнули меня на правильное решение проблемы.

    Итак, расскажу в чем была проблема.

    Проблема была в том, что ISA-сервер блокировал RPC-запросы к AD. Причем, если бы это блокировало какоето правило, то в мониторенге или логах я бы видел какое. Но я видел, что столбец правила пуст, а в коде результата выводится 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED. Причем, если создать праило, разрешающее всем всё в любое время по всем протоколам, то блокировок не происходило )именно это и заставляло думать, что по каким то причином какоето правило блокирует соединение).

    Итак, т.к. никакое правило не было написано в причинах блокировки трафика, это значит, что ISA не допускает запрос до правил, а отпбрасывает его еще раньше. На каких то форумах я вычитал, что код 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED возникает, когда пакет идет по одному маршруту, а возвращается по другому, соответственно ISA считает пакеты поддельными и отбрасывает. Но у меня же оба сервера воткнуты в одну циску, как может быть другой маршрут?

    Значит я подумал, что проблема в циске. Так и оказалось. Во время сбоя электричества, на ней сбилось время. Точно не знаю, но могу предположить, что ISA отправляет пакет и засекает время его отправки, когда пакет возвращается через циску со сбитым временем, она, видимо, его подписывает своим временем и ISA видит, что она отослала пакет сегодня, а вернулся он со временем 1993 года.

     

    Вот, думаю что проблема была именно в этом. По крайней мере, после выставления времени ве стало работать.

     

    • Помечено в качестве ответа Goblany 16 июля 2010 г. 5:27
    • Снята пометка об ответе Goblany 19 июля 2010 г. 4:42
    16 июля 2010 г. 5:27
  • Я поторопился, проблема не ушла. Сервер проработал два дня и ошибка появилась опять. Помогите, пожалуйста разобраться. Я уже голову сломал. Подскажите, у меня есть несколько вопросов:

    1) Я правильно понимаю, что если ISA блокирует соединение каким-либо правилом, то оно пишется в столбце правил (если смотреть в монтиоринг). Если же там нету правила, то это значит, что ISA не допустила запрос до обработки правилами и заблокировала его раньше?

    2) Если по первому вопросу я все правильно понимаю, то почему тогда если сделать правило, разрешающее все соединения отовсюду всем во все сети исправляет ошибку? Если сделать такое правило и посмотреть в мониторенге, каие запросы отправляет ISA-сервер (с интерфейса 192.168.0.3), то я вижу, что это правило выпускает только какието соединения ISA во внутреннюю сеть, а запросы к AD LDAP, LDAP GC и RPC  - из выпускает правило [SYSTEM] Разрешает отправлять RPC-запросы.... (в общем, 22 правило).

    3) Если не делать праивло, которое разрешает всем отовсюду куда угодно, то я в мониторе вижу, что от 192.168.0.3 идут запросы к AD (192.168.0.1). И при этом, есть запросы по протоколу LDAP 389, например. Так вот, я вижу что иногда эти запросы пропускаются системным правилом 22, а иногда блокируютс с кодом 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED . Почему так происходит?

    4) Может кто-то поподробонее объяснить, что это за ошибка такая 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED. Почему она возникает?

     

    Спасибо.

     

    19 июля 2010 г. 5:04
  • Посмотрите вот на это . Там есть советы, которые могут быть полезными в вашем случае.

    19 июля 2010 г. 10:34
    Модератор
  • Нет. Это не мой случай. Я это уже пробовал.

    19 июля 2010 г. 12:28
  • Насколько я понимаю чвою проблему, ISA сервер лет на AD SYN пакет, а ответ отбрасывает, т.к. он возврращается не по тому маршруту?

    Может какие то маршруты прописать надо? Или чтото неверно настроено?

                     

                             (Сетвевая карта смотрит в Internet)   IP - 99.99.99.99, маска, шлюз 99.99.99.98, DNS 192.168.0.1 и 192.168.0.2

                          /

    ISA-сервер 

                      \ 

                       (Ликалка) IP: 192.168.0.3, маска 255.255.255.0, шлюз-нету, DNS 192.168.0.1 и 192.168.0.2

                                      |

                        |         ROUTER           |

                        |  IP 192.168.0.19       |

                        | mask 255.255.255.0 |

                        |  шлюз 192.168.0.3   |

                          /                            \

    AD   - IP: 192.168.0.1,                         AD2   - IP: 192.168.0.2

    маска 255.255.255.0,                          маска 255.255.255.0,

    шлюз 192.168.0.3,                              шлюз 192.168.0.3,

    DNS 192.168.0.2 и 192.168.0.1           DNS 192.168.0.1 и 192.168.0.2

     

     

     

    • Изменено Goblany 20 июля 2010 г. 5:15
    19 июля 2010 г. 20:21
  • Еще интересное наблюдение.

    Если из тестового правила (которое разрешает всем отовюду везде) убрать Куда-внешняя сеть, то сервер отваливается.

    20 июля 2010 г. 4:31
  • а почему ДНСы не внешние??

     (Сетвевая карта смотрит в Internet)   IP - 99.99.99.99, маска, шлюз 99.99.99.98, DNS 192.168.0.1 и 192.168.0.2

     

    20 июля 2010 г. 7:10
  • У меня есть внутренний DNS-сервер, у которого сдела редирект на  внешние.

    Насколько я почитал литератутру, именно так все и делают.

     

    Я нашел вот такую статью, где как раз говорится о том, что пакеты SYN-ACK  должны идти по одному маршруту и через ISA.

    http://support.microsoft.com/kb/888042/en-us

     

    А как сделать так, чтобы такие пакеты шли через ISA и как проверить, куда идут я не знаю..

    20 июля 2010 г. 9:15
  • Проверить что куда идет вы можете с использованием любого сетевого монитора.



    Daniil Khabarov, MSFT  Follow MSTechnetForum on Twitter
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Посетите Блог Инженеров
    21 июля 2010 г. 8:38
    Модератор
  • Проблема так и не решилась.

    Едиинственное, что помогает - это создать верхним правило, разрешающее все для всех из Внутренняя во Внешняя. Если сделать такое правило, то все работает, но я не понимаю, причем тут соединения из внутренней сети во внешнюю. По лигике, ISA не может получить ответ от контроллера (ошибка Netlogon возникает), а значит проблема в связи ISA-сервра (локальный компьютер) и AD (внутренняя сеть). Почему тогда все работает только при правиле разрешить все протоколы из внутренней во внешнюю?

    И так же мне непонятно. ISA отбрасывает соединение, как я понимаю (FWX_E_TCP_NOT_SYN_PACKET_DROPPED), потому, что отправляет SYN пакет по одному маршруту к контроллеру, а ответ возвращается по другому маршруту. Непонятно, почему тогда вышеуказанное праило решает проблему, т.к. пакеты даже не должны доходить до правил, а отбрасываться раньше.

    И если пакеты идут по одному маршруту, а возвращаются по другому, почему это может быть? и как исправить?

    (Я правильно настравиваю, что не ставлю FWC клиентов никаких ни на ISa ни на AD и на AD указываю шлюзом ISA, может нужны другие настройки. Может на ISA надло прописать каой то маршрут к AD?)

     

    Спасибо.

    22 июля 2010 г. 6:13
  • Еще раз настоятельно рекомендую посмотреть в сторону системных правил. У меня стойкое ощущение, что именно там что-то там не так указано. А есть какие-либо ошибки о том, что не правильно определен диапазон IP адресов сетевых адаптеров?



    Daniil Khabarov, MSFT  Follow MSTechnetForum on Twitter
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Посетите Блог Инженеров
    22 июля 2010 г. 7:58
    Модератор
  • На счет диапазонов - ошибок нет. Конфигурация-сети-Внутренняя-Адреса - 192.168.0.0-192.168.0.255

     

    Куда смотреть в сторону системных правил не хнаю. Что именно проверить? Просто если бы чтото блокировалось системными правилами, то я бы должен это видеть при просмотре в ISA-мониторе (IP-адрес клиента равен 192.168.0.3).

     

    22 июля 2010 г. 10:43
  • В общем, я нашел как решить проблему, но вот почему она визникла - я так и не понял...

    В общем, есть ISA у которого:

    на внешнем интерфейсе указаны IP, маска, шлюз которые выданы провайдером.

    на внутреннем IP 192.168.0.3 255.255.255.0 шлюза нет, DNS- 192.168.0.1 и 192.168.0.2

     

    Соответственно, на DNS-серверах 192.168.0.1 и 192.168.0.2 в настройках сетевухи указан шлюз 192.168.0.3 и в настройках DNS-серверов указана пересылка на два IP-адреса - DNS-сервера провайдера.

    На ISA-сервере есть правило, разрешающее моим DNS-серверам делать запросы к DNS-серверам провайдера.

     

    Так вот, что я заметил, что мои DNS-сервера начали обращаться не только к серерверам провайдера, на которые настроена пересылка, но еще и к каким-то другим DNS-серверам, т.е. они обращаются куда хотят. и ISA блочит жти запросы (т.к. у меня правило разрешает только к провайдеру обращаться). 

    Вобщем, если сделать на ISA правило, разрешающее моим DNS-серверам обращаться куда угодно с запросами, то все арботает и ошибка не возникаеет. Только вот не пойму никак:

    1) Почему если пересылка настроена на 2 конкретных сервера, мои DNS лезут еще кудато?

    2) Почему это вызывает ошибку? Т.е. почему если внутренние DNS не могут обратиться к какимто внешним, возникают проблемы, котоыре я уже описывл выше, почему сервер начинает блочить RPC и LDAP и теряет связь с контроллером?

    26 июля 2010 г. 7:23
  • Так. А куда он обращается? Что за сервера?



    Daniil Khabarov, MSFT  Follow MSTechnetForum on Twitter
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Посетите Блог Инженеров
    28 июля 2010 г. 12:30
    Модератор
  • Ну на разнве внешние IP-адреса:

    20.137.18.66

    63.243.194.2

    66.28.0.14

    66.28.0.30

    68.87.71.167

    68.87.85.132

    128.11.2.20

    128.167.2.20

    134.216.26.1

    146.12.3.19

    146.12.3.21

    152.160.1.3

    157.50.50.13

     

    29 июля 2010 г. 7:10
  • А приведите-ка ipconfig /all с ISA.



    Daniil Khabarov, MSFT  Follow MSTechnetForum on Twitter
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Посетите Блог Инженеров
    29 июля 2010 г. 8:56
    Модератор

  • Подключение по локальной сети - Ethernet адаптер:

       DNS-суффикс этого подключения . . :
       Описание  . . . . . . . . . . . . : HP NC105i PCIe Gigabit Server Adapter
       Физический адрес. . . . . . . . . : 00-1E-0B-D5-59-91
       DHCP включен. . . . . . . . . . . : нет
       IP-адрес  . . . . . . . . . . . . : 192.168.0.3
       Маска подсети . . . . . . . . . . : 255.255.255.0
       Основной шлюз . . . . . . . . . . :
       DNS-серверы . . . . . . . . . . . : 192.168.0.1
                                           192.168.0.2
       Основной WINS-сервер  . . . . . . : 192.168.0.1
       Дополнительный WINS-сервер. . . . : 192.168.0.2

    Интернет - Ethernet адаптер:

       DNS-суффикс этого подключения . . :
       Описание  . . . . . . . . . . . . : HP NC105i PCIe Gigabit Server Adapter #2
       Физический адрес. . . . . . . . . : 00-1E-0B-D5-59-90
       DHCP включен. . . . . . . . . . . : нет
       IP-адрес  . . . . . . . . . . . . : 217.70.24.186
       Маска подсети . . . . . . . . . . : 255.255.255.240
       Основной шлюз . . . . . . . . . . : 217.70.24.177
       NetBIOS через TCP/IP. . . . . . . : отключен

    29 июля 2010 г. 9:55
  • //1) Почему если пересылка настроена на 2 конкретных сервера, мои DNS лезут еще кудато?

    а вы уверены, что на обоих серверах указанны только ДНС провайдера??

     

    //Едиинственное, что помогает - это создать верхним правило, разрешающее все для всех из Внутренняя во Внешняя.

    поставьте это правило ниже разрешения выхода для ДНС и посмотрите будет ли оно так же помогать.

    29 июля 2010 г. 14:50
  • кстати, вот что еще советовали.

    http://social.technet.microsoft.com/Forums/ru-RU/ws2008ru/thread/731cbe63-83cb-4dd2-b436-61005e889e4a

    29 июля 2010 г. 15:09
  • То, что на обоих ДНС серверах в пересылке указаны только ДНС провайдера - это совершенно точно. В любом случае, я в мониторинге ISA смотрел запросы с IP 192.168.0.1 (с первого моего ДНС-сервера), т.ч. на нем точно все настроено на пересылку к двум конкретным серверам. (Второй сейчас проверил, настройки такие же).

     

    На счет попробовать правило опустить - попробую в выходные это сделать.

     

    В статье не совсем моя проблема. КАк оказалось, моя проблема в том, что DNS-сервера лезут непонятно куда (первооочередная проблема). А в статье описана проблема с VPN-трафиком, который рубится ISA, т.к. галка строгого соответствия стоит.

    30 июля 2010 г. 4:55
  • //То, что на обоих ДНС серверах в пересылке указаны только ДНС провайдера - это совершенно точно

    но чудес ведь не бывает... даже сегодня ) )

    покажите ипконфиг ол с обоих серверов и исы.

    30 июля 2010 г. 6:14
  • C:\>ipconfig /all

    Настройка протокола IP для Windows

       Имя компьютера  . . . . . . . . . : server-ad1
       Основной DNS-суффикс  . . . . . . : Tsniis.com
       Тип узла. . . . . . . . . . . . . : гибридный
       IP-маршрутизация включена . . . . : нет
       WINS-прокси включен . . . . . . . : нет
       Порядок просмотра суффиксов DNS . : Tsniis.com

    Подключение по локальной сети2 - Ethernet адаптер:

       DNS-суффикс этого подключения . . :
       Описание  . . . . . . . . . . . . : HP NC105i PCIe Gigabit Server Adapter #2
       Физический адрес. . . . . . . . . : 00-1E-0B-DB-DD-FA
       DHCP включен. . . . . . . . . . . : нет
       IP-адрес  . . . . . . . . . . . . : 192.168.0.1
       Маска подсети . . . . . . . . . . : 255.255.255.0
       Основной шлюз . . . . . . . . . . : 192.168.0.3
       DNS-серверы . . . . . . . . . . . : 192.168.0.2
                                           192.168.0.1

     

     

     

    Microsoft Windows [Версия 5.2.3790]
    (С) Корпорация Майкрософт, 1985-2003.

    C:\>ipconfig /all

    Настройка протокола IP для Windows

       Имя компьютера  . . . . . . . . . : server-ex
       Основной DNS-суффикс  . . . . . . : Tsniis.com
       Тип узла. . . . . . . . . . . . . : неизвестный
       IP-маршрутизация включена . . . . : да
       WINS-прокси включен . . . . . . . : да
       Порядок просмотра суффиксов DNS . : Tsniis.com

    Подключение по локальной сети - Ethernet адаптер:

       DNS-суффикс этого подключения . . :
       Описание  . . . . . . . . . . . . : HP NC105i PCIe Gigabit Server Adapter
       Физический адрес. . . . . . . . . : 00-1E-0B-D5-59-91
       DHCP включен. . . . . . . . . . . : нет
       IP-адрес  . . . . . . . . . . . . : 192.168.0.3
       Маска подсети . . . . . . . . . . : 255.255.255.0
       Основной шлюз . . . . . . . . . . :
       DNS-серверы . . . . . . . . . . . : 192.168.0.1
                                           192.168.0.2
       Основной WINS-сервер  . . . . . . : 192.168.0.1
       Дополнительный WINS-сервер. . . . : 192.168.0.2

    Интернет - Ethernet адаптер:

       DNS-суффикс этого подключения . . :
       Описание  . . . . . . . . . . . . : HP NC105i PCIe Gigabit Server Adapter #2
       Физический адрес. . . . . . . . . : 00-1E-0B-D5-59-90
       DHCP включен. . . . . . . . . . . : нет
       IP-адрес  . . . . . . . . . . . . : 217.70.24.186
       Маска подсети . . . . . . . . . . : 255.255.255.240
       Основной шлюз . . . . . . . . . . : 217.70.24.177
       NetBIOS через TCP/IP. . . . . . . : отключен

    C:\>

    31 июля 2010 г. 20:59
  • Итак, вы смогли приблизиться к решению проблемы?



    Daniil Khabarov, MSFT  Follow MSTechnetForum on Twitter
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Посетите Блог Инженеров
    12 августа 2010 г. 14:26
    Модератор
  • Нет. Проблема не решена.

    Почему то мои DNS-сервера начали обращаться не только к DNS-серверам провайдера, которые указаны в пересылка, но и к каким то другим. В результате этого, ISA блокиреет LDAP и RPC запросы к DNS- серверам (они же AD).

    Т.е. из-за того, что DNS сервера кудато образаются, кроме серверов пересылки (а ISA-сервер блокирует эти запросы, т.к. я правилом выпускаю такие запросы только к DNS-серверам провайдера), ISA блокирует контроллеры домена.

    Надо понять:

    1) Почему DNS-сервера обращаются кудао, кроме серверов перемылки

    2) Почему ISA из-заэтих DNS-запросов блокирует доступ к AD (LDAP, RPC).

    13 августа 2010 г. 19:57
  • Goblany

    А почему у Вас  основной DNS-суффикс  . . . . . . : Tsniis.com

    Может AD посылает  LDAP и RPC запросы к DNS- серверам, а он у Вас внешний  217.70.24.186

    >nslookup

    Non-authoritative answer:
    Name:    Tsniis.com
    Address:  217.70.24.186

    В ISA нет разрешающего правила, вот она и блокирует.

    10 октября 2010 г. 18:38
  • TSNIIS.COM потому, что у меня домент так называется.

    А DNS-сервера у меня 192.168.0.1 и 192.1689.0.2, к ним и посылаются DNS-запросы.

    11 октября 2010 г. 8:07
  • А чем история завершилась? Та же проблема. Внезапно 1-2 раза в неделю иса стала тупить. Не пропускает трафик ни снаружи ни внутри, при этом открытые сессии пашут. Локально заходим - все типа работает, ну да особо разглядывать некогда - в перезагрузку и все снова работает. Еще перестал доступ к машине по RPC работать, т.е. журнал событий по сети уже не посмотришь. С чего бы это и что делать? Рецептов тут не видать...
    14 ноября 2010 г. 18:10
  • В общем проблема заключалась в том, что внутренние DNS-сервера были настроены на пересылку к DNS-провайдерам, но в какой то момент почему то начали посылать запросы не только к DNS провайдера, но еще и к какм-то DNS, которые я не настраивал, т.е. получалось,  DNS-запросы шли к левым серверам и ISA их отбрасывала (т.к. правила ISA разрешали запросы только к провайдеру), после чего возникала указанная ошибка.

    Для решения проблемы на внутренних DNS-серверах в свояствах на вклдаке Пересылка установил галочки "Не использовать рекурсию для данного домена". После этого вроде проблема исчезла.

    • Помечено в качестве ответа Goblany 19 ноября 2010 г. 5:43
    19 ноября 2010 г. 5:43