Belize

Радиус, скрещенный с билингом, уже есть. То есть юзер, который вводит существующий логин и пароль из билинга, благополучно подключается к WPA сети и сразу имеет доступ в инет. Проблема в том как пустить в WPA сеть гостя и ограничить его только своим сайтом. Не работает свзяка freeradius + jradius так как описано по ссылке с сайта coova, выдает access-reject вместо того чтоб выдавать access-accept + дополнительный аттрибут require-uam-auth. P.S. Хотелось бы иметь один контроллер доступа независимо от того сколько точек доступа будет и где бы географически они не находились.

Здравствуйте. Хочу организовать хотспот. Работать должен так - юзер видит WPA сеть, вводит логин и пароль для подключения к WiFi сети (WPA Enterprise) - если логин и пароль есть в билинге, то юзер сразу идет в инеты, если нет такого логина в билинге, то юзер перенаправляется на сайт, где ему рассказывается о том, что это за сеть и как ему получить логин и пароль для доступа в инет. Остановился на связке Coovachilli + freeradius + jradius. Схема настройки описана тут - http://coova.org/CoovaChilli/WPACaptivePortal . Но не заводится в том варианте как описано на этой странице (если интересно, опишу детали) Вопросы такие: у кого-нибудь получилось успешно настроить эту связку (возможно сотрудничество за материальное вознаграждение)? Какие еще есть варианты кроме coovachilli?

Имеется похожая ситуация: надо выбрать новое оборудование в ядро сети. Абонентов около 50 тысяч. Несколько домов собираются в районный узел, оттуда гигабитным линком уходят на писюковый роутер. На роутере L3, OSPF, терминация PPTP, фаервол, DHCP-relay. Все роутеры вторым интерфейсом смотрят в ядро (суммарный pps на этом интерфейсе порядка 200к). Также в ядро входят аплинки, bgp-бордеры, шейперы, СОРМ, несколько L2 коммутаторов. В ядре только L2, всё L3 на писюках. Сейчас роутеров около 50 штук, прогнозируется до 100. В связи с некоторыми ограничениями текущей схемы (сейчас ядро это стек из 4-х D-link DGS-3627), было решено поменять железо в ядре. Подобрали такую конфигурацию: WS-6509-E - шасси. 102411 руб WS-SUP720-3B (PFC3B,MSFC3) - управляющий модуль, 2 штуки (1 для резерва) - 202242 руб за 1 штуку WS-X6748-SFP - модуль 48 SFP портов по 1G. 2 штуки (1 для резерва) - 325727 руб за 1 штуку WS-X6748-GE-TX - модуль 48 медных 1G портов. 4 штуки (1 для резерва) - 166850 руб за 1 штуку WS-CAC-6000W - блок питания, 2 штуки (1 для резерва) - 43295 за 1 штуку WS-C6K-6SLOT-FAN2 - блок вентиляторов, 2 штуки (1 для резерва) - 11 563 руб за штуку Итого: 1 935 465 руб Вопросы: Стоит ли сразу озаботиться установкой dfc3 на модули? Немного непонятно со пропускной способностью одного слота под модуль : 20 гигабит или 40 ? Хотелось бы попробовать прозрачное проксирование, поддержка WCCP заложена в IOS или в железо? Какие еще ньюансы могут всплыть в будущем? Как насчет варианта в перспективе отказаться от писюковых роутеров и перенести L3 на каталист, а PPTP терминировать на ASR ? P.S. D-link DES-3627 соединены в стек через CX4 модули, как можно посмотреть объем траффика между свичами?

Выложьте, пожалуйста, интересно что за зверь.

# pfctl -s info Status: Enabled for 80 days 11:33:15 Debug: Urgent State Table Total Rate current entries 757173 searches 1811386980866 260496.5/s inserts 52036862171 7483.4/s removals 52036396277 7483.4/s Counters match 79799958980 11476.1/s bad-offset 0 0.0/s fragment 296913 0.0/s short 477152 0.1/s normalize 0 0.0/s memory 629466894 90.5/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 20363 0.0/s proto-cksum 38500113 5.5/s state-mismatch 71464873 10.3/s state-insert 13233368 1.9/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s 110 kpps, 500 mbits. Но, похоже, это уже почти предел, начинает в пике периодически сыпать ошибки.

Надо поставить вот это perl-Expect-1.21-3mdv2009.0.noarch - это модуль для Perl.

Так и сделали, с радиусом проблем нет, запросы и ответы оседают на съемнике. Но. Вот на съемнике осело что абонент pupkin подключился и получил адрес 10.x.x.x. А когда pupkin хулиганит в интернете и пишет гадости про чиновников на форумах, то там "светится" белый адрес из натовского пула. Потому УФСБ и требует таблицу соответствий "серого"/"белого" адресов.

Спасибо за ответ. Динамические пулы - это первое что проверили, очень хотелось их внедрить. Не вышло. /21 мало, вчера около 6 сессий было в пике. Так что не жирно, ведь 16к это на 3 года движения вперед :-)

Здравствуйте, коллеги. Прошу совета. Ситуация такая. Имеется сеть на 11 тысяч абонентов. Недавно получили LIR и PA сеть /18. УФСБ с прошлой осени напрягает установить СОРМ. Договорились с вышестоящим провайдером использовать их оборудование СОРМ. Согласовали с УФСБ. Прокинули канал от УФСБ до нашей сети. И вот встала задача сделать так чтоб этот самый СОРМ заработал. Radius запросы-ответы победили, прогнав их через петлю с сормовской коробкой. И упёрлись в NAT... УФСБ надо однозначно знать соответствие логина - "белого" IP-адреса. Попробовали такие варианты: Первый вариант: Сделать всё красиво - использовать динамическое выделение "белых" IP-адресов. Попробовали внедрить. Оказалось билинг UTM5 cовсем не годится для этой задачи: пуляет трафик не в того юзера, начинает зависать, падать каждые 2 часа. C freeradius-ом подружить так, чтоб выполнялось всё что надо - тоже не вышло. Второй вариант: Согласно требованиям, оборудование СОРМ должно стоять до того места где делается NAT. Возможно было бы вынести свои натилки вместе bgp бордером на площадку аплинка, но эта схема откровенно "колхозная", ни о каком резервировании каналов не может быть и речи. Плюс такой момент - на сормовской коробке видно соответствие логина-"серого" IP и УФСБ затребовало "хранить где-то соответствие серого-белого адресов в таблице NAT". Честно говоря, не представляю как обрабатывать эту информацию: как извлекать еще более менее понятно, а вот где её хранить, какие там будут объемы и как привязывать это к СОРМ совсем туммано. Третий вариант: выдать каждому абоненту по "белому" адресу сейчас рассматривается. Тут возникают новые вопросы. Отправляли в RIPE план освоения адресного пространства на 3 года вперед. План писался честно и по нему через 3 года будут использованы 14 тысяч адресов из 16. Если сейчас выдать каждому абоненту по "белому" адресу, то через 3 года понадобится 30 тысяч адресов. Если через полгода начать просить у RIPE еще сеть /18, то как они к этому отнесутся? Могут ли быть проблемы из-за нарушение плана освоения? Выдадут ли в итоге еще сеть, если обосновать грамотно?. Какие еще проблемы могут быть? Ну и конечно есть еще варианты с покупкой своего оборудования СОРМ или своего вменяемого билинга. Заранее спасибо за помощь.

svn checkout https://accel-pptp.svn.sourceforge.net/svnroot/accel-pptp/branch/0.8 accel-pptp-0.8