Перейти к содержимому
Калькуляторы

CoMax

Пользователи
  • Публикации

    13
  • Зарегистрирован

  • Посещение

Все публикации пользователя CoMax


  1. А фикс от сервиспака не зависит? Зависит, наверное. Но если у кого-то до сих пор не SP3 - то он уж сам себе буратино. Спасибо за патч! Файл действительно разный в разных service pack. И к сожалению, буратины находятся. =)
  2. А фикс от сервиспака не зависит?
  3. Проблема в том, что по телефону не получается никак объяснить абонентам, что надо делать. А звонков очень много =(
  4. блокировка lurkmore.to

    Мы вот тоже на стороне формального подхода - блокировать пару IP + url из реестра. Если пытаться сделать так, чтобы "мышь не проскочила" - то действительно "не имеем технической возможности", так как https, vpn, proxy, top, и т.д. Причем на этот подход нас навели не просто наши внутренние раздумья, а встреча с представителями мин. связи накануне вступления в силу закона, с операторами НАДИКС. Так вот там в вольном пересказе был как раз предложен метод - загоняете по BGP на фильтр те IP, которые в реестре, а уж там фильтруете по URL малую долю трафика, причем только исходящего. Так и делаем. Бегать за DNS не вижу смысла, можно только хуже сделать - проверяющий придет и скажет: "Вот почему тот IP, что в реестре, не заблокирован, и когда я в hosts прописываю, у меня дети голые открываются, что за вольности вы тут себе позволяете, где вы такое вычитали?" Далее было сказано, что они там в министерстве хотят "оценить" масштабы такого DPI на весь рунет, заказать его разработку, и потом поставить его у себя, подняв со всеми провайдерами BGP... Но вот что законодатели придумают, когда им доложат про CDN - мне страшно представить. Там видимо по /12 всяких hetzner будем заворачивать на DPI...но пока об этом ТАМ никто не подумал.
  5. А разве на 1228 есть dhcp_snooping?
  6. Summit-460-24(48) - это уже L3 аппараты, дороже, в заявленном функционале не нужны. Но может быть автору понадобится L3 - тогда это лучший вариант. А для чистого L2 я бы тоже рекомендовал DGS-3120, Link aggregation там работает как положено.
  7. А никто с таким не встречался: Длииинный ipfw, коротенький pf только для nat. На внешнем интерфейсе (только на нем включен pf, на остальных стоит set skip <interface>, теряются пакеты, причем tcpdump видит, например входящие, а ответные сервер уже не посылает. Стоит optimization aggressive, 3 правила no nat, потом 3 правила nat. Когда откатываюсь на natd - потери уходят, возврат на pf опять приводит к потерям. Машинка Xeon 2.4 dual core, карточки em* на pci-express, Free-BSD (ядро amd64 с поддержкой SMP) Нагрузка на нат прямо сейчас: State Table Total Rate current entries 2348 searches 35302083788 25522.5/s inserts 59620559 43.1/s removals 59618211 43.1/s Counters match 31512966696 22783.1/s bad-offset 0 0.0/s fragment 450 0.0/s short 20 0.0/s normalize 0 0.0/s memory 1993988 1.4/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 582898 0.4/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s Нагрузка вечером раза в 3 выше. Еще на гейте mpd в качестве VPN-терминатора, 400-500 пользователей. Для максирования прерываний стоят dev.em.*.*x.delay порядка 1000. Отключение оного картину не влияет, только проц прерываниями грузится активнее. Помогите, куда рыть? Потери только на интерфейсе, на котором нат, причем даже на трафике, который в сам нат не попадает.