none
Существенные задержки в Protocol rule UDP Send Receive RRS feed

  • Вопрос

  • Коллеги, не посчитайте некрофилом - речь пойдёт о MS ISA 2000. Конфигурация проблемы описана здесь. И суть проблемы такова. Имею правило разрешающее на протокол UDP 87 Send Receive. И через некоторое время network monitor даёт мне любопытную картинку - клиент отправляет запрос, скажем с 1100 порта на 87 порт получателя по UDP. Ответа нет. Через 9 секунд клиент уже с другого порта повторно пытается - скажем с 1101 на 87 получателя. Приходит ответ, но на предыдущий запрос. Он где-то "отдыхал" 9 секунд. Провайдер смотрел логи - по его логам (я их видел) запрос ушёл и вернулся ответ в течение нескольких милисекунд. Я за isa уже вижу 9 секунд. то есть ответ на предыдущий запрос isa Отдаёт только после  следующего запроса от того же клиента. Причём глюк не постоянный - раза с 30 (а то и хуже) вернёт ответ сразу - и дальше у меня всё хорошо, с этого порта отправителя и обратно всё ходит за несколько милисекунд, с другого порта - та же ситуация.

    Перезапускаю ISA Server Control - всё восстанавливается (ответы приходят мнгновенно), но на время. Через некоторое время ситуация возобновляется.

    Не посоветуете коллеги, куда копать по данному вопросу? Тот факт, что дело в isa, подтверждён сниффером до и после isa хоста одной и той же сессии обмена. До isa всё дошло вовремя, она отдала с огромной задержкой (после следующего пакета от клиента).


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    18 октября 2011 г. 14:15

Ответы

  • Итого, проблема решена. Причина была именно в том, что для "проблемного" сервера банка (с получением ответов от которого возникали задержки) не было PTR записи в обратной зоне DNS.

    Итого, решение:

    • либо отключаем логгирование на isa для firewall service ("отключение" полей с fqdn не помогает, проверено)
    • либо заставляем админов банка добавить ptr запись в обратную зону для своего сервера
    • либо создаём на своих dns серверах обратную зону для адресов их сервера (да, это неправильно, но от них реакции ждать долго, а это решение можно реализовать за несколько секунд).
    • возможно, есть решение с отключением rdns запросов на isa (для логгирования) через реестр, но пока его не нашёл. Буду рад подсказкам.

    После добавления обратной зоны даже перезапускать ничего не надо - задержки тут же пропадают.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    26 октября 2011 г. 4:47
  • Однако, хочется верить, что я ошибаюсь, но проблема, похоже, решена. Завтра подтверждение смогу напечатать. А суть в следующем. Видимо, ISA Firewall при логгировании действительно пытается выполнить rdns при КАЖДОМ открытии udp сессии. Отрицательные ответы dns у меня не кешировались (кстати, видимо придётся подумать над их кешированием, блин), в результате чего возникала задержка с доставкой ответа в начале каждой сессии!!! (в результате - клиент и рвал сессию в самом начале, не дождавшись ответа).

    Дописал на своих dns обратную зону для серверов банка (да, такая вот заглушка, так как банк не позаботился о своей обратной зоне) - и всё полетело! Задержки просто исчезли!.

    Сейчас залез в настройки логгирования файрвола на isa, отключил все поля, связанные с dns запросами адреса назначения, буду проверять завтра, достаточно ли этого, или всё-таки придётся оставить иммитацию обратной зоны для адресов банка на своих серверах.

    Завтра по результатам отпишусь.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    25 октября 2011 г. 18:06

Все ответы

  • Есть предложение отключить или уменьшить до минимума кеш на сервере. Посмотреть результат. Когда-то помогло.


    MCITP. Знание - не уменьшает нашей глупости.
    18 октября 2011 г. 14:31
  • Секунду, кеш какой? кеш web proxy service? так он же к firewall service никакого отношения не имеет, или я не прав?

    Да и потом - откуда эпизодичность указанной проблемы? и почему пропадает при перезапуска isa server control?


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    18 октября 2011 г. 14:33
  • Перечитал вашу конфигурацию. Кеш тут не причем.

    По вопросу ISA Server Control. http://technet.microsoft.com/en-us/library/cc722759.aspx

    Есть предположение по модулю логирования.

    http://support.microsoft.com/kb/285807/j

    Посмотрел бы на работу правил с отключенным IP filter. Сталкивался с тем, что ISA воспринимала пакеты как UDP bomb. Поэтому отключал фильры.

    http://technet.microsoft.com/en-us/library/cc722755.aspx


    MCITP. Знание - не уменьшает нашей глупости.
    19 октября 2011 г. 6:46
  • Фильтрацию udp bomb отключил, перезапустил isa server control - эффект тот же. Так что дело не в этом. Пока обратно не поставил, верну, когда найдём решение...

    При этом в логах ip packet filter заблокированных пакетов от udp 87 не обнаружил...

    Указанный hotfix для логов уже был установлен...

    Однако, попробовал отключить фильтрацию пакетов полностью. - проблема осталась! Да, после перезапуска isa server control несколько секунд (до минуты, скажем) - всё было изумительно. Потом всё вернулось.

    Включил фильтрацию пакетов, но полностью отключил intrusion detection. Но проблема практические осталась - первый пакет с задержкой в 9 секунд (правда - не всегда), последующие нормально ходят. даже при отключенном модуле. Делаю вывод - дело не в нём.

    Ключевой момент вижу именно в том, что после перезапуска isa server control какое-то время всё живёт идеально. А потом?

    В общем - проблема осталась. Буду благодарен за любые идеи!


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    19 октября 2011 г. 11:13
  • Скрипт исключение по портам UDP.

    http://blogs.technet.com/b/isablog/archive/2008/12/09/exception-list-script-for-isa-server-and-forefront-tmg-udp-updates.aspx


    MCITP. Знание - не уменьшает нашей глупости.
    19 октября 2011 г. 13:57
  • Сама статья любопытна, но не в тему. А вот ссылка на обновление в ней - http://support.microsoft.com/kb/956637, похоже помогла (хотя ума не приложу, каким образом случайный выбор udp порта при nat сопоставлении может привести к исключению задержек с прохождением ответов.

    Ваш скрипт может оказать полезен при решении конфликтов с udp приложениями на самом isa хосте, но таковым у меня нет (dns не в счёт - он в роли сервера, динамические порты не использует) http://support.microsoft.com/kb/956188, http://support.microsoft.com/kb/812873.

    Мысль пришла в голову только одна. Уходит пакет в очередного (N+1) udp порта isa после NAT. ответ идёт туда же - на NAT+1. При следующей попытке - новый порт на клиенте, новый порт на isa - N+2. Не распоздаёт ли случаем сама isa подобные udp пакеты как попытку перебора портов (all ports scan)? может из-за этого и возникали задержки?

    В общем - сейчас (после установки обновления) задержки пропали. Но сейчас вечер (вечером всегда становилось всё лучше, нагрузки нет), однозначно смогу сказать только завтра днём.

    Также благодаря Вам наткнулся на информацию http://support.microsoft.com/kb/311777/en-us?fr=1 о включении full NAT для server publishing на isa 2000. Спасибо.

    Но в любом случае уже - спасибо Вам за поддержку!


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    19 октября 2011 г. 14:49
  • Однако, радовался рано. через час после перезапуска isa server control задержка вернулась - те же 9 секунд. так что хотфикс не повлиял. Буду рад новым предположениям.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    19 октября 2011 г. 17:03
  • День добрый.

    Пока незачто говорить спасибо. Просто интересно покопаться в ISA 2000, а то практически забыл. Давно ее не использовал.

    При тестирование отключались только IP Filter?

    Предлагаю посмотреть еще на http://technet.microsoft.com/en-us/library/cc512655.aspx.

    Вот именно этот фильтр по вопросу UDP bomb и возможных задержек.

     


    MCITP. Знание - не уменьшает нашей глупости.
    20 октября 2011 г. 9:36
  • Нет, отключал фильтрацию вообще.

    Статью прочитал, то, что описано - знаю, но за ссылку спасибо, прозрачно всё написано, сотрудникам дам почитать. Но статья никоим образом не разъясняет, откуда может возникнуть задержка именно на ISA (напомню, сниффер до isa показал, что на WAN всё приходит без задержек, а сниффер в LAN уже показал задержку в 9 секунд. Между ними была только isa), и что с ней делать?.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    20 октября 2011 г. 12:35
  • Вопрос. На какой ОС установлена ISA 2000? Версия билда?

    В августе 2007 были внесены изминения в работу протокола UDP.

    http://www.rfc-editor.org/rfc/rfc4993.txt


    MCITP. Знание - не уменьшает нашей глупости.
    20 октября 2011 г. 13:09
  • windows 2000 server 5.00.2195 (sp4 + обновления). А где почитать про изменения в UDP?
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    20 октября 2011 г. 13:11
  • http://support.microsoft.com/kb/263823
    MCITP. Знание - не уменьшает нашей глупости.
    20 октября 2011 г. 13:23
  • Я ж не могу ядро isa переписывать! это ж статья на разработчиков ориентирована.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    20 октября 2011 г. 13:28
  • :) Можно попытаться поставить хотфикс на систему, только забекапить старые DLL. по KB263823.

     


    MCITP. Знание - не уменьшает нашей глупости.
    20 октября 2011 г. 13:40
  • Дык ведь в статье указано, что проблема пофиксена в sp2, а стоит аж sp4 и плюс все обновления сверху... Так что это решение уже "стоит"... и не помогает. 


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 5:19
  • Эта ревизия 2007 года, в SP4 стоит более старая версия.  Это можно проверить по версиям DLL.
    MCITP. Знание - не уменьшает нашей глупости.
    21 октября 2011 г. 5:30
  • Осталось только найти её уже скомпилированной. в kb нет ссылки. ищу...
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 5:32
  • Указанный патч стоит, он входил в состав SP2. И то, что он собирался обновлять - уже более поздней версии имеется. от 2007 года только статья в kb, сам update действительно вошёл в состав sp2.
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 7:41
  • У меня больше нет идей по данной проблеме.

    Последнее.  Перейти на TMG проверить работу там. Если будет такая же проблема открыть кейс в MS.


    MCITP. Знание - не уменьшает нашей глупости.
    21 октября 2011 г. 7:52
  • по isa 2000 это уже врядли возможно, поскольку поддержка закончилась.
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    21 октября 2011 г. 8:10
  • Да я знаю, что ISA 2000 не поддерживаеться. Предложил перейти на TMG и проверить работу правила на нем, если не работает то открыть кейс. 
    MCITP. Знание - не уменьшает нашей глупости.
    21 октября 2011 г. 8:31
  • На TMG будем переходить, вариантов то особо нет других. Но до этого ещё несколько недель утечёт. А пока - дополнительная информация. Любопытную картину наблюдаю по netstat -na. Просто огромное количество открытых UDP портов на 0.0.0.0 (то есть - на всех интерфейсах). Номер крайнего открытого порта в несколько минут доходит до 65530. Портов открыто несолько тысяч!

    Беда в том, что на windows 2000 netstat не показывает процесс, открывший эти порты. Коллеги, может подскажете, чем на windows 2000 увидеть id процесса, открывшего порт?

    И пока закономерность обнаружил следующую: пока (в течение первых нескольких минут) UDP портов открыто не очень много - соединение устанавливается моментально, задержек нет. Как только номер последнего порта доходит до 65500+ - начинаются задержки.

    P.S. перезапуск dns сервиса на этом хосте портов не освободил, перезапуск isa server control - так же. Теперь и при перезапуске isa server control проблема никуда не уходит - задержки на месте.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 8:44
  • netstat PID

    http://support.microsoft.com/kb/907980


    MCITP. Знание - не уменьшает нашей глупости.
    21 октября 2011 г. 8:47
  • Блин, искал сторонние утилиты, а о том, что MS могла выпустить патч по запросу - и не подумал. Спасибо за ссылку!

    сам netstat.exe изменился, а вот справка к нему (/?) - нет. Поэтому приведу командную строку:

    netstat -ano > c:\temp\ports.txt

    В результате увидел, что огромное количество открытых UDP портов делится приблизительно поровну между двумя процессами - DNS.exe и WSPSRV.EXE. Я бы ещё понял dns (хотя на него вообще никакой нагрузки, разрешением имён занимаются dns серверы внутри сети, которые выходят к корневым, к этому не ходят). С wspsrv тоже всё понятно было бы - через него внутренние dns и ходят. Но почему они (порты) остаются открытыми?


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 9:12
  • DNS, как выяснил, сразу при запуске забирает себе огромный пул udp портов. Чего с этим делать и нужно ли с этим что-либо делать - подумаю. firewall service -  с ним тоже всё понятно. Его грузят внутренние dns серверы. Не понятно только одно - почему порты на нём остаются открытыми, и не закрываются? Может быть для этих целей следует на клиентах (dns серверах) что-либо поменять? (dns - на server 2003 standard server).


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 9:22
  • P.S. остановка dns сервера (и освождение портов, занятых им) исходную проблему не решает. Даже при выключенном dns на isa хосте задержка остаётся.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 9:23
  • http://support.microsoft.com/kb/816996

     


    MCITP. Знание - не уменьшает нашей глупости.
    21 октября 2011 г. 9:44
  • Уже пробегало. У меня нет разрешающих правил на udp 137. В логах пробегали только попытки самого isa хоста. на на windows 2000 этого не победить, - не будет доступа ни к DC, ни к сетевым ресурсам (служба tcp/ip helper for netbios). но пакеты за isa не уходят - они в лог уходят как заблокированные.

    Правда для служб netbt и netbios в реестре есть привязки (bind), можно попробовать отвязать их от внешнего интерфейса в реестре... Попробую, чтобы и сеть оставить на isa в порядке, и udp137 исключить в логах ip packet filter.

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

    Отвязываю netbt от wan (internet) интерфейса следующим образом. находим guid наших сетевых интерфейсов:

    reg query "HKLM\system\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}" /s
    


    убиваю для начала в этой ветке уже несуществующие интерфейсы. Определил guid WAN интерфейса. Далее смотрим привязки NetBT:

    reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Linkage" /v bind
    
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Linkage
        bind        REG_MULTI_SZ    \Device\Tcpip_{300960A7-D052-437A-9429-61F01C419DED}\0\Device\Tcpip_{61946F9A-233A-4A98-B75D-FF4F0E89EBB1}\0\Device\Tcpip_{E175D49E-4906-4001-BFA7-BE11053F5ABA}\0\Device\Tcpip_{EC76BE4E-03BE-4204-A045-8F392D8AE80C}\0\Device\Tcpip_{7FBC8DFA-B0F8-4F2C-94A5-D95DB2F254D8}\0\0
    

    Вижу привязку аж к 5ти интерфейсам. Мне оно зачем? Оставляю привязку только к LAN:

    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Linkage" /v Bind /t REG_MULTI_SZ /s " " /d "\Device\Tcpip_{300960A7-D052-437A-9429-61F01C419DED}" /f
    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Linkage" /v Export /t REG_MULTI_SZ /s " " /d "\Device\NetBT_Tcpip_{300960A7-D052-437A-9429-61F01C419DED}" /f
    


    Беда в том, что службу netbt перезапустить не получится, только перезагрузка поможет нам применить параметры. Перезагрузился.

     

    Но исходную проблему, опять-таки, никоим образом мы не решили.

    Ещё какие-нибудь идеи?

    Как и следовало ожидать, сеть доступна, контроллеры домена также доступны, в логах ip packet filter больше попыток на UDP 137 со стороны isa не наблюдается.
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 10:58
  • Как и раньше, сразу после перезагрузки задержек никаких нет. и, как и раньше - куча занятых udp портов на всех интерфейсах процессом dns.exe, и немножно занятых - firewall service, причём последний занимает порты только на внутреннем интерфейсе, а не на всех.

    Есть предложение отвязать dns.exe от всех интерфейсов, кроме внешнего. чтобы если он и занимал порты, то хотя бы не на всех интерфейсах. попробую...

    reg add "HKLM\System\CurrentControlSet\Services\DNS\Parameters" /v ListenAddresses /t REG_SZ /d "213.148.164.198" /f
    
    net stop dns
    net start dns

    Почему здесь привязки сделаны иначе, не через linkage - не могу сказать. Смотрим, что получили в netstat -ano. Однако... Он может быть сейчас и обрабатывает запросы только с внешнего интерфейса, но привязывается всё равно ко всем интерфейсам!!! В общем - не нашёл способа отвзять dns сервер от интерфейсов, всё равно вешается на 0.0.0.0. И занимает сразу 2500 портов (правда - цифра и не меняется со временем...) Судя по всему, порты резервируются для последующего "рандомного" их выбора при запросе, борьба с DNS cache poison, как я понимаю... Что подтверждается http://support.microsoft.com/kb/956188. Учитывая тот факт, что он у меня не занимается разрешением имён для моей сети, только для внешних клиентов (всякие там www, ftp и прочее), мне этот пул не нужен. Поэтому уменьшу ка я размер пула, занимаемого dns.

    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v SocketPoolSize /t REG_DWORD /d 1 /f
    
    net stop dns
    net start dns


    Да, теперь он (dns сервер) занимает только один порт, теперь вообще ничего криминального в netstat. А проблема на месте...

    Ещё идеи?


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru

    21 октября 2011 г. 11:25
  • Однако, с отвязыванием NetBT от внешнего интерфейса возникла проблема - RRAS перестал принимать PPTP соединения с внешнего интерфейса. Пришлось вернуть NetBT на него. Соответственно, опять буду видеть udp 137 в ip packet filter логе...


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    21 октября 2011 г. 12:17
  • Ещё немного информации. для адреса, с которым возникают задержки (для адреса ФПСУ сервера банка) нет PTR записей в обратной зоне. Для того, с которым нет задержек - есть записи в обратной зоне. Могут быть проблемы связаны с этим (скажем - сервис логгирования файрвола пытается RDNS выполнить, поэтому и задержки, не может быть такого)?
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    25 октября 2011 г. 14:00
  • Наткнулся на нечто похожее http://sysadmins.ru/topic279257-15.html. Также изредка наблюдаю невозможность подключения к ISA, проходит само или перезагрузкой.

    Можно ли отключить в isa rdns при записи в лог файрвола? складывается впечатление, что имеено isa и генерит огромный поток udp подключений (dns)...


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    25 октября 2011 г. 17:39
  • Однако, хочется верить, что я ошибаюсь, но проблема, похоже, решена. Завтра подтверждение смогу напечатать. А суть в следующем. Видимо, ISA Firewall при логгировании действительно пытается выполнить rdns при КАЖДОМ открытии udp сессии. Отрицательные ответы dns у меня не кешировались (кстати, видимо придётся подумать над их кешированием, блин), в результате чего возникала задержка с доставкой ответа в начале каждой сессии!!! (в результате - клиент и рвал сессию в самом начале, не дождавшись ответа).

    Дописал на своих dns обратную зону для серверов банка (да, такая вот заглушка, так как банк не позаботился о своей обратной зоне) - и всё полетело! Задержки просто исчезли!.

    Сейчас залез в настройки логгирования файрвола на isa, отключил все поля, связанные с dns запросами адреса назначения, буду проверять завтра, достаточно ли этого, или всё-таки придётся оставить иммитацию обратной зоны для адресов банка на своих серверах.

    Завтра по результатам отпишусь.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    25 октября 2011 г. 18:06
  • Однако, отключения "лишних" полей в логгировании недостаточно, работает только трюк с фальсификацией обратной зоны DNS. Есть ли возможность отключить в ISA rdns запросы при логгировании через реестр?
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    25 октября 2011 г. 18:11
  • Итого, проблема решена. Причина была именно в том, что для "проблемного" сервера банка (с получением ответов от которого возникали задержки) не было PTR записи в обратной зоне DNS.

    Итого, решение:

    • либо отключаем логгирование на isa для firewall service ("отключение" полей с fqdn не помогает, проверено)
    • либо заставляем админов банка добавить ptr запись в обратную зону для своего сервера
    • либо создаём на своих dns серверах обратную зону для адресов их сервера (да, это неправильно, но от них реакции ждать долго, а это решение можно реализовать за несколько секунд).
    • возможно, есть решение с отключением rdns запросов на isa (для логгирования) через реестр, но пока его не нашёл. Буду рад подсказкам.

    После добавления обратной зоны даже перезапускать ничего не надо - задержки тут же пропадают.


    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    26 октября 2011 г. 4:47
  • уже после того, как нашёл ответ, наткнулся на статью на ту же тему: http://www.itcommunity.ru/blogs/sie-wl/archive/2010/05/07/101757.aspx. Ка бы раньше знать, какие слова ключевые в поиске писать...
    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru
    26 октября 2011 г. 4:54