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

Victor Safronov

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

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

  • Посещение

1 подписчик

О Victor Safronov

  • Звание
    Абитуриент
    Абитуриент
  • День рождения 07/21/1984

Контакты

  • ICQ
    Array

Информация

  • Пол
    Array

Город

  • Город
    Array

Посетители профиля

1510 просмотров профиля
  1. Какой объем трафика направляете через фильтр? Не рекомендую отправлять весь трафик на фильтр, т.к. механизм nfqueue достаточно медленный. Немного, в пределах ста мегабит. Только я не очень понял две вещи, тут много говорилось о каких-то скриптах, которые могут что-то откуда-то нагенерировать. Мне нет необходимости на таких трафиках выделять отдельный тазик, можно обойтись ipset-ом. И откуда нужно брать адреса для фильтра, из дампа РКН или периодически резолвить адреса из url в список?
  2. А nf_queue full at xxx entries лечится только запуском нескольких копий демона и раскидыванием трафика по разным очередям?
  3. Подскажите навскидку, а для IPv4 (pptp в частности) есть аналогичная для IPv6 функциональность "делегирования" префикса? Мне нужно, чтобы при подключении клиенту выдавался Framed-IP-Address и дополнительно на туннель маршрутизировалась ещё дополнительная подсеть. Или это только костылями через ip-up?
  4. Одного скрипта достаточно для навешивания статичного шейпинга. accel же умеет "динамическое" шейпирование в зависимости от времени суток, а это значит, что нужно навешивать свои доп. скрипты в крон, которые будут "бегать" по туннелям, изменяя там скорость. Тот же IPoE на мой взгляд тоже изначально stateless и DHCP как сигнализация притянут за уши, но это не мешает поддерживать эту технологию в accel-ppp. Грубо говоря, чисто теоретически можно по аналогии с реализацией того же IPoE просто ждать пакеты с протоколом 94 (как discover) на определённых интерфейсах, через LUA преобразовывать SRC IP в логин и лезть с ним в радиус, и в этот момент создавать IPIP-туннель. А потом гасить его по истечении "аналога" lease-time — вот и вся сигнализация Просто это опять потребует вмешательства в ядерный код родного модуля ipip, да и нафик не нужно. Поэтому я и говорю о полустатическом подходе, когда туннели создаются при запуске и на них навешиваются стандартные штатные шейперы accel, одинаково действующие на всех интерфейсах. Опционально можно периодически повторно лезть в радиус с целью узнать, не изменилось ли состояние и в случае чего гасить туннель обратно, или заворачивать в ipset и т.д.
  5. Это явно выходит за рамки accel-ppp. Изначально рамки были ограничены одним только протоколом PPTP. Потом они расширились до L2TP, PPPoE, IPoE. Не вижу никаких противоречий с реализацией других туннелей.
  6. А вот у меня назрел очень неожиданный фичереквест. Почти все наши VPN-щики подключаются по PPTP/L2TP, как им бог на душу положит. При этом есть некоторое количество клиентов, для которых настроены IPIP-туннели. Проблема в том, что у нас нет какого-то механизма устанавливать шейпинг на эти туннели по информации из биллинга. Даже если вешать правила при загрузке системы своими костылями, то нет возможности штатно менять скорость по временным интервалам, например. Поэтому возникает соблазн запихнуть управление этими туннелями внутрь accel-ppp, чтобы независимо от способа туннелирования все настройки шейпинга применялись единообразно. Как это могло бы выглядеть: некий конфиг-файл, где перечислены необходимые данные для поднятия туннелей (например, логин и удалённый IP). При старте accel-ppp читает эти данные и делает запросы к радиусу для получения клиентского IP и настроек шейпинга, а затем поднимает эти IPIP-туннели. Свой адрес для туннелирования задаётся, например, где-нибудь в секции [ipip], там же шаблон для именования интерфейсов. Насколько сложно и вообще возможно, и имело бы смысл такое реализовать?
  7. А зачем у вас в подсказке ключ сменился с правильного -dd на неправильный -bb? :)
  8. На самом деле такое большое количество кусков в диффе вызвано лишь переиначиванием форматирования. Собственно два года назад я всё это вычистил, оставив чистый патч с непосредственными изменениями. Попробовал его сейчас применить к версии 4.2.6 - сработал весь кроме одного последнего куска, где патчится подсказка по ключам запуска сервера :) Не знаю как на 4.2.5, но на той версии, что прямо сейчас является последней стабильной мой (ну то есть, я тут конечно не приписываю себе его авторство :D) патч сработает. dhcp-4.2.6.dd.patch.txt
  9. большое спасибо, запилил, работает. Cейчас хлебаем полными ложками проблему с новым ядром Centos 6.5 - давно не перезагружали серв и на тебе. Пока резервный трудится. Используйте ядро kernel-lt из elrepo, там уже есть модуль
  10. Скажите, в ipoe есть возможность реализовать одновременную работу клиентского компьютера и STB, так чтобы можно было для приставки (основываясь на заранее заданном мак-адресе или какой-либо опции дхцп) выдавать один адрес, а для всего остального другой? Забыл уточнить, речь про схему vlan per user. Сейчас у нас используется isc dhcp и там нагорожена городьба из host {} для приставок и class/pool для клиентов. Хочется уйти от этой схемы.
  11. xeb хоть как-нибудь отзовитесь по проблеме :) просто нужно понимать, есть ли смысл ждать фикса через сам модуль, или ничего не остаётся как использовать в центосе свежее ядро, с уже включённым модулем?
  12. а можно линк? Он относится к ветке kernel и потому закрыт по дефолту от посторонних. https://bugzilla.redhat.com/show_bug.cgi?id=1044593 вот линк, который вас, скорее всего пошлёт :)
  13. xeb а есть мысли что делать с центос/рхел 6.5? проблема в том, что они бэкпортировали в новое своё ядро 2.6.32-431 модуль gre.c, причём ни в одном из ванильных ядер с 2.6.37 по 3.12 этого файла нет в том виде, в котором он у RH. Судя по содержимому это их вольная компиляция из gre_demux.c и gre_offload.c. Если при этом пробовать собрать поверх этого pptp.c из какого-нибудь из свежих ядер, то оно ругается на отсутствующий хедер-файл ppp_ioctl.h В общем, надо что-нибудь делать :)
  14. Засабмитил баг в redhat по поводу их косяка с ядром в 6.5. Пока идут в несознанку.