M-a-x-Z Опубликовано 22 июля, 2014 · Жалоба Несколько лет назад в одной сети у меня был настроен NAT на выход во внешнюю сеть. Те клиенты, которые не были прописаны в нате доступ не получали. Со стороны клиента это выглядело как длительное ожидание загрузки страницы. Потом я добавил ACL, который запретил выпускать неизменённые пакеты в сторону провайдера. После этого Cisco 2811 стала отправлять пакеты destination unreachable в сторону клиентов, не имевших NAT. Теперь со стороны клиента при попытке обратиться в сайту в сети Интернет стало моментально демонстрироваться сообщение о недоступности узла. Тогда я решил, что это происходит на основании icmp пакетов о недостижимости узла. Сейчас я снова настроил уже другую сеть на NAT и запрет выхода адресов без маскировки. Cisco точно так же формирует пакеты destination unreachable для недоступных страниц, но браузеры на это не реагируют, продолжая длительно ждать ответа. На что на самом деле может среагировать браузер и как настроить блокировку таким образом, что бы браузер (драйвер ОС) сразу знал что узел недоступен, а не обдумывал долго её загрузку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 22 июля, 2014 · Жалоба Если не путаю эти анричибл, если клиент с роутером бесполезны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
M-a-x-Z Опубликовано 22 июля, 2014 · Жалоба Если не путаю эти анричибл, если клиент с роутером бесполезны. Ну да, если будет промежуточный роутер они будут бесполезны. Но в данном случае шлюз 2811, который их генерирует передаёт их напрямую клиенту. Я их вижу в Wireshark достигающими сетёвки, но не вижу на них реакции. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
M-a-x-Z Опубликовано 24 июля, 2014 (изменено) · Жалоба Уточнил диагностику - Cisco действительно посылает destination unreachable, но очень редко. Когда пакет посылается - сброс соединения идёт сразу. Какой командор регулируется частота и выборочность отправки таких пакетов? UPD: Изменил частоту отправки сообщений: ip icmp rate-limit unreachable 1 Теперь они отправляются всегда. При пинге недоступного узла и трассировке ответ о недостижимости приходит мгновенно, всё работает красиво. Но при этом браузер не хочет реагировать на такие пакеты и продолжает грузить страницу, несмотря на то, что на каждый TCP пакет получает отказ. Я бы поверил, что он не умеет на них реагировать, если бы ранее своими глазами не видел как браузер сбрасывает попытку соединения на этих пакетах. Причём его поведение обусловлено не конкретным браузером. Обработка пакетов должна происходить на уровне драйвера ОС. Но печему-то не происходит. В чём может быть причина? Изменено 24 июля, 2014 пользователем M-a-x-Z Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VVSina Опубликовано 26 июля, 2014 · Жалоба Поменялись версии, драйвера и т. п. года идут. А отправлять unreachable на каждый пакет это дыра в безопасности, какой-нибудь вирус с syn-флудом, и ваша железяка будет заниматься только тем что генерировать эти unreachable. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 26 июля, 2014 · Жалоба Но при этом браузер не хочет реагировать на такие пакеты и продолжает грузить страницу, несмотря на то, что на каждый TCP пакет получает отказ. вероятно, этот icmp-ответ дропается фаервол. попробуйте выключить всё, что потенциально может фаерволить Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
M-a-x-Z Опубликовано 26 июля, 2014 · Жалоба Но при этом браузер не хочет реагировать на такие пакеты и продолжает грузить страницу, несмотря на то, что на каждый TCP пакет получает отказ. вероятно, этот icmp-ответ дропается фаервол. попробуйте выключить всё, что потенциально может фаерволить Только Каспер и он во время экспериментов отключен. Кстати опытным путём установлен факт: каспер перехватывает паекты раньше, чем wireshark и nmap. Т.е. если пакет срезан антивирусом - енго сетевые анализаторы уже не видят. Поменялись версии, драйвера и т. п. года идут. А отправлять unreachable на каждый пакет это дыра в безопасности, какой-нибудь вирус с syn-флудом, и ваша железяка будет заниматься только тем что генерировать эти unreachable. Приведённые выше команды всё-равно не позволяют отправлять их чаще, чем 1 раз за 1 мс. За 1 мс 1 пакет - не так много ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 26 июля, 2014 · Жалоба Только Каспер и он во время экспериментов отключен. я редко пользуюсь виндой для сетевых экспериментов, но как-то пробовал полностью выключить касперского - не получилось. да и винде тоже какой-то фаервол встроенный есть попробуйте заставить генерить cisco port unreachable вместо dst unreachable. в идеале конечно tcp syn rest Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
M-a-x-Z Опубликовано 27 июля, 2014 · Жалоба Только Каспер и он во время экспериментов отключен. я редко пользуюсь виндой для сетевых экспериментов, но как-то пробовал полностью выключить касперского - не получилось. да и винде тоже какой-то фаервол встроенный есть Если эксперименты с поведением типичного клиента, то на чём же ещё их делать, как не на винде?)) попробуйте заставить генерить cisco port unreachable вместо dst unreachable. в идеале конечно tcp syn rest А команды не подскажете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 27 июля, 2014 · Жалоба попробуйте через ip tcp intercept Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
M-a-x-Z Опубликовано 31 июля, 2014 · Жалоба попробуйте через ip tcp intercept Через intercept можно сбрасывать соединения к контролируему серверу. А в данном случае - наоборот - сброс соединения к неконтролируемоуму серверу во внешней сети. Даже если установить intercept на все исходящие соединения (хотя я не представляю, какая комбинация команд нужна) то будет смерть процессору. Видимо задача действительно не решимая разумными средствами. Жаль. Думал раз раньше такое работала - может какая-то хитрость есть в отправке пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...