none
СТАРАЯ ДОБРАЯ БЕДА С ISA 2006 RRS feed

  • Общие обсуждения

  • Всё таже старая история вернулась в наш дом. Шлюз перестал работать - не отрабатывают пинги и днс запросы. Уже и войти терминалом на него не получается. Сквозь него можно пройти терминалом - тоесть tcp сессия создаётся и по RDP можно залезть куда нибудь. Началось как всегда с ничего - просто раз и в 12 часов стоп игра. Перезагружал шлюз. На самом шлюзе ошибок нету, кроме того что он ненашёл домен и всё в таком же духе. С самого шлюза интернет так же не работает да что там интернет - не пингуются никакие машины из локальной сети - вообще ничего и внутрь ни наружу. Из локалки не пингуется шлюз и не пингуется интернет. Днс запросы которые перенаправляются на шлюз или через шлюз не отрабатывают. не зайти на шлюз никак. Плюс сеть зафлужена попытками шлюза разрешить имена которые ему запрашивают на разрешение по средствам широковещательных SMB запросов, что тоже зашибись. Выключаем службу файервола на шлюзе и вуаля - всё прекрасно и удивительно. Со шлюза сразу всё видно. Интернет работает и всё замечательно. Порты пробрасываются, тоесть опубликованый почтовый сервер продолжает работать. Идеи? Что делать?
    13 сентября 2011 г. 12:23

Все ответы

  • 16.45 Запинговался шлюз, но не более того. Днс не работает - интернет не работает на шлюз по RDP не зайти (
    13 сентября 2011 г. 12:48
  • 17.00 Заработал интернет.

    Зашёл на шлюз в логах ничего пару ошибок, от нетлогона пара штук что неполучилось установить соединение с контроллером домена и от винтайм32 что не удалось синхронизовать время пару раз с сервером времени.

    13 сентября 2011 г. 13:11
  • клиентский доступ по впн не включен? вообще rras не запущен?

    13 сентября 2011 г. 16:22
    Отвечающий
  • RRAS не запущен.

    VPN клиентов нету только наоборот изнутри наружу по openVpn - по UDP, работают даже когда происходит описанный сбой.

    14 сентября 2011 г. 7:33
  • может сетевуха или дрова к ней?
    14 сентября 2011 г. 9:57
    Отвечающий
  • У меня такое было и именно с ISA Server 2006. Причина - DNS-flood, т.е. вал пакетов UDP 53, как из внутренней сети на ISA, так и с ISA во внутреннюю и внешнюю сети. Это стало происходить потому, что умирал один из наших внешних ns-серверов и ISA (кэширующий DNS) вынуждена была сильно флудить, чтобы добиться от него хотя бы чего-нибудь. В итоге она и имена не разрешала, и внутренний домен теряла (пользователей не аутентифицировала), и по Flood Mitigation вообще давала отказы в обслуживании. Поменяли внешний ns-сервер и проблема решилась.

    А вообще я бы начал с изучения трафика на ISA и попыток выделить в нем какие-либо подозрительные вещи.

    14 сентября 2011 г. 10:27
  • DNS флуд очень возможен.

    Конфигурация следующая - 3 контроллера домена на них днс сервера подняты разумеется и форвардят на шлюз. На шлюзе секондари зона домена есть + форвард на провайдерские ДНС сервера (2 штуки) а на интерфейсах стоит днс 127.0.0.1 как и на всех контроллерах домена.

    КАк вариант может быть поменять ворвард с провайдерских скажем на гугл 8.8.8.8 но гугл если пользуешься его днсом начинает сканить порты, сеть и ведёт себя подозрительно. МОжет вообще убрать форвард пусть работает через руты?

    14 сентября 2011 г. 10:33
  • Или может можно как нибудь отключить Flood mitigation
    14 сентября 2011 г. 10:33
  • Да отключить-то все можно, только ведь Flood mitigation полезное дело делает.

    У Вас ведь наверняка не один DNS провайдера? Попробуйте оставить какой-нибудь один и посмотреть, что будет.

    Далее, какие у Вас сетевые карты на ISA (на некоторых картах лучше отключать определенные аппаратные возможности)?

    Если RSS включено, то лучше везде выключить, связка ISA + Windows Server 2003 с ним не совместима.


    • Изменено Mickwel 14 сентября 2011 г. 11:13
    14 сентября 2011 г. 10:55
  • Сетевые карты к сожалению самые обычные внешняя D-Link DGE-530T Gigabit Ethernet A

    Внутренняя Realtek RTL8168C(P)/8111C(P) Family PCI-E GBE NIC

     

    Попробовал убрать вообще форвард сейчас - на пол часа вырубил инетрент )

    Вернул всё как было на 2 адреса прова - через 20 минут интернет появился.

     

    14 сентября 2011 г. 11:12
  • RSS выключен и был
    14 сентября 2011 г. 11:18
  • И на сетевухе и  системе?


    Через 20 минут? Многовато что-то.

    Посмотрите плз, что у них есть из аппаратных возможностей. Large Send Offload нужно отключать точно, с остальным - экспериментировать. И буфера на них тоже можно бы увеличить.

    • Изменено Mickwel 14 сентября 2011 г. 11:42
    14 сентября 2011 г. 11:40
  • Отключил на обоих сетевухах: Разгрузка при большой отправки, наскока я понял это то.
    14 сентября 2011 г. 12:16
  • А Receive и Transmit буфера?

    14 сентября 2011 г. 12:32
  • DNS флуд очень возможен.

    Конфигурация следующая - 3 контроллера домена на них днс сервера подняты разумеется и форвардят на шлюз. На шлюзе секондари зона домена есть + форвард на провайдерские ДНС сервера (2 штуки) а на интерфейсах стоит днс 127.0.0.1 как и на всех контроллерах домена.

    КАк вариант может быть поменять ворвард с провайдерских скажем на гугл 8.8.8.8 но гугл если пользуешься его днсом начинает сканить порты, сеть и ведёт себя подозрительно. МОжет вообще убрать форвард пусть работает через руты?


    никогда не понимал зачем люди такую схему делают? что мешает разрешить контроллерам ходить наружу за резолвом и не ставить на исе никаких левых кэширующих dns? форвардерами кстати вообще пользоваться необязательно, хотя в большиснтве случаев форвардинг отрабатывает быстрее чем прямая рекурсия.
    14 сентября 2011 г. 12:54
    Отвечающий
  • никогда не понимал зачем люди такую схему делают? что мешает разрешить контроллерам ходить наружу за резолвом и не ставить на исе никаких левых кэширующих dns? форвардерами кстати вообще пользоваться необязательно, хотя в большиснтве случаев форвардинг отрабатывает быстрее чем прямая рекурсия.


    Пробовал и такой вариант, но NS-трафик в канале до провайдера возрастает на порядок. На мой взгляд, лучше вместо этого употребить канал на что-нибудь более полезное. А вот держать зону на сервере ISA - действительно не есть хорошо хотя бы с точки зрения безопасности.
    14 сентября 2011 г. 13:01
  • Ну так просто исторически сложилось, сначала собственно был 1 сервер и он был всё. В итоге просто клиенты все настроены на днс сервер - шлюз + один из контроллеров.
    14 сентября 2011 г. 13:41
  • Кстати на счёт безопасности - есть ли какая нибудь возможность закрыть снаружи видение этой доменной зоны.

    Ко всему прочему на шлюзе ещё есть и внешняя зона.

    14 сентября 2011 г. 13:46
  • Кстати на счёт безопасности - есть ли какая нибудь возможность закрыть снаружи видение этой доменной зоны.

    Ко всему прочему на шлюзе ещё есть и внешняя зона.


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

    Подождите, у Вас ISA - еще и внешний DNS? Если так, то скорее всего Вас просто пробили :)

    14 сентября 2011 г. 13:59
  • Стоит такой кб

    Пробили? тоесть и что делать как оследить?

    15 сентября 2011 г. 7:46
  • Стоит такой кб

    Пробили? тоесть и что делать как оследить?


    Трафик смотреть и выискивать все, что Вам может показаться подозрительным.
    15 сентября 2011 г. 10:01
  • Итак этим занимаюсь в последнее время всё чаще и чаще. Но подозрительный трафик обычно бывает dns а вот понять что за приложение этот трафик генерит не всегда оказывается возможным.

    Кстати решил всё таки убрать dns со шлюза - вернее убрать внутреннюю зону - а оставить только внешнюю.

    Порекомендуйте правильную схему решения вопроса разрешения имён в такой сети. Шлюз, 3 контроллера домена, exchange, клиенты. Настрийки днс есть соответственно на контроллерах домена на самом шлюзе на exchange и внутри smtp сервиса ексченда + антиспам стоит который тоже активно dns юзает для всяких RBLей и тому подобное.

    15 сентября 2011 г. 10:32
  • Правильность каждой конкретной схемы зависит от архитектуры Вашей сети.

    У меня сделано так: во внутренней сети есть контроллеры домена, на них - внутренние dns. На TMG - поднят только(!) кэширующий dns (слушает только на внутреннем IP), т.е. никаких зон на нем нет (и не рекомендуется из соображений безопасности). Внешняя зона хранится на собственных отдельных серверах, стоящих в DMZ (перед TMG). Соответственно ns-трафик ходит от DC на TMG и далее на наши внешние сервера, с которых по мере надобности форвардится на провайдера.


    Кстати кэширующий DNS на ISA может очень выручить, если на ней имеется интенсивно используемые правила, настроенные на Domain Name Set или URL Set. В этом случае для разрешения имен (в том числе и адресов в имя по мере надобности) ISA будет использовать доступные ему ns-сервера, т.е. либо постоянно лазать к серверам провайдера и генерить тем самым нехилый трафик, либо пользоваться своим кэширующим, который по мере наполнения будет использовать провайдерские dns по минимуму.
    • Изменено Mickwel 15 сентября 2011 г. 10:46
    15 сентября 2011 г. 10:39
  • Кэширующий днс на исе естественно есть, даже интересно как его можно отключить в случае если служба днс запущена и на нём есть зоны.
    16 сентября 2011 г. 6:35
  • Скажу больше, чтобы DNS был кэширующим, наличие зон тоже необязательно :)
    16 сентября 2011 г. 10:18
  • Сделал так:

    На шлюзе DNS сервер слушает только на внешнем интерфейсе на 1 ип адресе. Форвард и рекурсию запретил.

    На внешнем интерфейсе поставил днс сервера - провайдера.

    На внутреннем интерфейсе - 2 контроллера домена.

    На Контроллерах домена сделал форвард на днс сервера провайдера. На Почтовом сервере тоже прописал жёстко ип адреса серверов днс провайдера.

    Пока работает - смотрю что будет дальше :(

    19 сентября 2011 г. 8:07
  • Мне в свое время помогло вот что ( проблема 1 в 1 такая же)

    Играл с настройками дополнительными сетевых интерфейсов, поотключал там почти все и увеличил количество буфферов приема -передачи.

    уже с год как часы

    19 сентября 2011 г. 10:34
  • Увеличил с каких до каких значений в итоге? И на обоих картах?
    20 сентября 2011 г. 6:11
  • На обоих (прием передача) увеличил до 512, обшие до 256 + отключил все фичи, типа разгрузки, большых пакетов и т.п.
    20 сентября 2011 г. 8:25
  • Впечатление что всё плохо, возможно будет практичнее переустановить и сделать всё правильно начиная с ОС?

    Стоит ISA 2006 с начала 2008, проблем не когда не было, за исключением поломки HDD под cache, восстановление из образа заняло 20 минут + 5 мин восстановление настроек ISA, кроме того что так и не удалось пробросить «OpenVPN», больше нареканий не было.

    • Изменено Denis Shuman 21 сентября 2011 г. 8:23
    21 сентября 2011 г. 8:19
  • Как раз OpenVPN пробрасываетя на ура и делать то ничего ненадо 1194 udp пробросил или открыл наружу и всё.

    А с Исой большие проблемы и не у меня одного - сейчас правда больше обсуждают TMG Где такие же проблемы и даже хуже.

    Сегодня вот с 10 часов не рабоает иса. всё как обычно - полная блокировка.

    И ни днсы ни их наличие или отсутствие никакого влияния на этот процесс не оказывает. Проходит само - как не понятно совершенно. Бывает что неделя всё в норме потом раз и началось и раз началось то будет регулярно всплывать.

    25 октября 2011 г. 9:12
  • пошёл 5 час не работающей ИСЫ - рекорд.

    Периодически появляется пинг на внутренний интерфейс  - потом пропадает :(

    з.ы. Спасибо микросовту за всё )

    25 октября 2011 г. 10:30
  • Заработало - рекорд 6 часов тупика :(

    И кстати кто нибудь знает куда валятся логи от флуд митингейшена? если включить его логирование?

    25 октября 2011 г. 11:48
  • А все-таки, может сетевухи посмотреть ? особенно если интеловые, не помогло ?
    26 октября 2011 г. 13:21
  • Добавлю свои пять копеек. Крйане не рекомендуется на сетевых интерфейсах сервера с установленным DNS прописывать 127.0.0.1
    MCP:Exchange 2003
    1 ноября 2011 г. 11:46
  • Так как всё это вилами по воде - становиться совершенно очевидно что у ИСЫ это включается режим блокировки.

    У ТМГ проблемы такие же или ещё хуже  и об этом можно судить по количеству соответствующих топиков.

    Вопрос тогда назревает один и только один - как этот режим выключить вообще?

    Или научится его выключать временно.

    3 ноября 2011 г. 9:47