WIFI в библиотеке: результаты.

Система, описанная ранее работает уже более квартала и можно делать некоторые выводы.

1. Endian Firewall уступил место более простому IPCOP. Причиной тому стал вывод из строя сервера внешними силами. Примерно за четыре часа брутфорса (который происходил в ночь с воскресенья на понедельник) /var/log переполнился (логи ротейтились раз в 100 мегабайт, и в итоге получилось 55 гигабайт гзипованного текста!), lvm начал любезно сдвигать остальные разделы и в итоге система тщетно засыпая мой ящик предупреждениями перестала отвечать на внешние запросы. Погибла, но не сдалась короче.

Поковыряв и реанимировав EFW, решил попробовать более простой IPCOP, прозрачный прокси которого решил использовать исключительно как гейт до вышестоящего прокси сервера. Syslog сервер теперь внешний, а логи прокси ротейтятся более интеллектуально. Пока вроде работает…. в IPCOP изрядно доставила одна особенность — если выбрал во время установки в качестве WAN что-то типа PPPoE, то через веб интерфейс на DHCP ETHERNET уже не переключить, а переставить ОС полностью оказалось несколько быстрее чем разобраться с CLI этого самого IPCOP.

2. Точки дступа оказались вовсе WAP54G v.3.1 а не WRT54G, как я считал ранее. Просто прошивка DD-WRT разницы между WAP54 и WRT54 не замечает. Разница с точки зрения частоты процессора, объёма оперативной и энергонезависимой памяти минимальна, так что, под DD-WRT нет особой разницы как устройство было названо производителем 🙂

3. Проверка боем показала достаточную живучесть системы. На четвертом месяце количество уникальных MAC адресов, получивших IP на контроллере (Acer Altos 600) перевалило за 10 000 (десять тысяч). Во время проведения крупных конференций и фестивалей на площадке, которая находится этажом выше библиотеки, сеть обслуживала в пике 159 (сто пятьдесят девять) пользователей. Судя по логам, медленно и с перебоями, но все чего-то скачали! Физическим интерфейсом выступал как раз WAP54G v.3.1 (пара в WDS+AP). При этом ни одного сбоя системы не было. Аптайм на данный момент составляет 58 дней, плановое выключение контроллера было связано с процедурой чистки от пыли в выходной день.

4. Похоже, мы имеем проблемы с внутренней сетью университета. Аренда серого статического адреса основного сервера (HP Proliant ML 370 G3) составляет двое суток. В момент обновления адреса, сервер зачастую не получает шлюз. Адрес есть, маска тоже, DNS’ы… всё есть, а шлюза нет. Если бы проблема случалась раз в двое суток, то всё было бы не так страшно и решалось бы простым назначенным заданием, но в последнее время мы столкнулись с тем, что шлюз может теряться несколько раз в день, а может и не теряться неделю. Гирлянда управляемых коммутаторов разных фирм, которые имели место между контроллером сети университета и нашим сервером была заменена на один хороший каталист, но ситуации это не исправило. Наши сетевики пока думают в чём дело, время аренды адресов уменьшили до нескольких часов, что в принципе должно было устранить некоторые проблемы нашего сегмента с большим количеством клиентов, но пока результата это не дало. Пока я делаю ipconfig /release и ipconfig /renew раз в два часа в будние дни с восьми утра и до восьми вечера.

2 комментария для "WIFI в библиотеке: результаты."

    Библиотека ХГУПТ | 03.05.2012 в 1:18 пп

    Спасибо! Очень интересно!
    Собираемся ставить у себя WiFi этот опыт может пригодится, сейчас покажу статью нашему админу.

    IdeaFix | 03.05.2012 в 6:41 пп

    Если что — готовы делиться опытом не только в коментах…. обращайтесь.

    Да, это http://ideafix.name/?p=13 и это http://library-bat.ru/2012/02/15/wifi-%d0%b2-%d0%b1%d0%b8%d0%b1%d0%bb%d0%b8%d0%be%d1%82%d0%b5%d0%ba%d0%b5-%d0%b2%d0%be%d1%81%d0%ba%d1%80%d0%b5%d1%88%d0%b5%d0%bd%d0%b8%d0%b5/ — одно и то же.

Ваш отзыв на Библиотека ХГУПТ