Отказоусточивый прокси-сервер на базе Squid в домене Windows

    UPD: различия в потреблении памяти между моей конфигурацией и той, которая используется у авторов негативных комментариев, вызваны тем, что со Squid'ом помимо стандартного скрипта wbinfo_group.pl, с помощью которого определяется принадлежность доменного пользователя доменной группе, используется скрипт, который определяет сам логин пользователя для того, чтобы squid умел предоставлять пользователю права, отличающиеся от тех прав, которые предоставлены его группе.

    imageОднажды дождливым серым вечером у меня появилась потребность внедрить прокси-сервер, но не простой, а такой, который бы обладал следующим функционалом:
    • предоставление/ограничение доступа в зависимости от членства учетной записи в определенной группе Active Directory;
    • предоставление/ограничение доступа в зависимости от прав, предоставленных учетной записи (например, чтобы можно было всей группе разрешить пользоваться поисковиками, а одному самому хитрому пользователю этой группы отключить строго определенный поисковик);
    • предоставление доступа без всяких ограничений для «VIP» MAC-адресов;
    • предоставление доступа к минимальному набору ресурсов всем пользователям (и недоменным в том числе);
    • количество движений, которые должен выполнить пользователь для работы с прокси-сервером, должно быть сведено к минимуму;
    • администрирование прокси-сервера производится посредством веб-интерфейса;
    • совокупная стоимость владения данным прокси-сервером должна быть минимальной.


    Естественно, взгляд мой упал на Squid с авторизацией по протоколу ntlmssp. Нашлась утилита конфигурирования Squid'а через веб-интерфейс — SAMS. Но как-то не срослось у меня с ним: то версию php приходилось откатывать с 5.3 на 5.2, то к домену он не цеплялся, то пользователей не видел. Я ни в коем случае не хочу сказать, что это плохой продукт, мой знакомый его разворачивал и настраивал (так что источник достоверный), просто расположение звезд не позволило мне стать адептом SAMS'а.
    Изрядно намучившись с гуглом, различными продуктами и решениями, я подумал: «суть конфигурирования состоит в генерации файла squid.conf, на php мне как-то доводилось писать, а почему бы не реализовать веб-интерфейс самому?» Сказано — сделано. В скором времени забегали пакетики, заругались пользователи, понесли мне служебные записки на открытие доступа к ресурсам сети интернет.
    Казалось бы, чего еще от жизни надо? Ан нет, по прошествии некоторого времени вылезло на поверхность несколько недочетов в инфраструктуре решения.
    1. При нарушении функционирования контроллера домена, при потере связи с ним, резервный канал связи с внешним миром, коим является интернет (а основной — корпоративная почта), переставал функционировать, ибо пользователи не могли авторизоваться.
    2. Пользователь авторизуется на прокси по протоколу ntlmssp с помощью helper’а (масло масляное) ntlm_auth, один экземпляр которого занимает в оперативной памяти около 60 мегабайт.

      Как видно, в авторизации участвует также и процесс winbindd, отъедающий столько же памяти. Итого, 120 мегабайт на запрос. Экспериментально выяснено, что параметр auth_param ntlm children, указывающий количество потоков для авторизации, должен превышать количество пользователей примерно на 10%. При auth_param ntlm children = 200 на прокси-сервере занято 600 мегабайт памяти.

      Экспериментально выяснено, что если при этом на прокси будут работать 150 пользователей с майл-агентами и прочей шалупонью, то сервер может вести себя непредсказуемо, например, подвисать, терять связь с контроллером домена и т.п. Снова замечу, что, возможно, это моя криворукость, но именно она подтолкнула меня к осмыслению темы данного опуса.
    3. Ресурсы процессора практически не задействуются, при этом происходит резервирование огромного количества оперативной памяти.

    Соответственно, появились новые хотелки.
    1. Снизить нагрузку на прокси-сервер и получить возможность расширять состав прокси-серверов легким движением руки.
    2. При проблемах с авторизацией переключаться на недоменную конфигурацию, а при исчезновении проблем переключаться обратно на доменную конфигурацию. По пути можно уведомлять администратора о появляющихся и исчезающих проблемах.

    Снижение нагрузки на прокси-сервер + возможность масштабирования

    Отправной точкой на пути к решению является возможность балансировки нагрузки в iptables.
    # iptables -t nat -A PREROUTING --dst $GW_IP -p tcp --dport 3128 -m state --state NEW -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination $PROXY1
    #iptables -t nat -A PREROUTING --dst $GW_IP -p tcp --dport 3128 -m state --state NEW -m statistic --mode nth --every 3 --packet 1 -j DNAT --to-destination $PROXY2
    #iptables -t nat -A PREROUTING --dst $GW_IP -p tcp --dport 3128 -m state --state NEW -m statistic --mode nth --every 3 --packet 2 -j DNAT --to-destination $PROXY3

    Код данного листинга позволяет равномерно распределить нагрузку между тремя прокси-серверами. Теперь нам нужно три прокси-сервера, которые будут скрываться за одним IP адресом. Мое решение представлено на рисунке ниже.

    Обозначения:
    • LAN 192.168.0.0/24 — локальная сеть;
    • PROXY — прокси-сервер, который видит пользователь;
    • LAN 192.168.1.0/24 — локальная сеть для прокси-серверов;
    • PROXY1..PROXYN — виртуальные машины на базе ОС Linux, на которых развернуты Squid, и Samba, интегрированная с Active Directory;
    • PROXY_CONFIG — виртуальная машина, на которой развернут интерфейс управления прокси-серверами.

    В данном случае «прокси-сервер», который видит пользователь, на самом деле является гипервизором виртуальных машин, на котором развернуто необходимое количество прокси-серверов и интерфейс управления ими.

    При такой структуре можно легко обеспечить:
    • прохождение пакетов от «VIP» MAC-адресов в обход прокси;
    • масштабируемость прокси-серверов;
    • быстрое восстановление после сбоя;
    • поле для экспериментов с конфигурацией Squid'а (для это достаточно развернуть новую виртуальную машину и тестировать все на ней);
    • быстрое выведение из пула прокси-серверов проблемной виртуальной машины;
    • более или менее оптимальное использование аппаратных ресурсов.

    Конфигурация Squid'а одинакова для всех прокси-серверов, поэтому файл squid.conf хранится на компьютере PROXY_CONF в nfs-шаре.

    Для воплощения данной схемы в жизнь использовались следующие программно-аппаратные компоненты:
    • компьютер CPU Core i3/RAM 4 Gb/HDD 500 Gb;
    • ОС Ubuntu-Server 11.04;
    • VirtualBox + phpvirtualbox.

    Для автоматизированного запуска и остановки виртуальных машин при включении и выключении компьютера были написаны скрипты vmstart и vmstop, которые поочередно включают и выключают все виртуальные машины. Приводить их содержание не стану, так как это просто использование команд VBoxHeadless и VBoxManage в совокупности с пингом для проверки статуса машины.
    Таким образом, решено несколько задач:
    • снижение нагрузки на прокси-сервер — пакеты с запросом нового соединения разбрасываются на N виртуальных прокси-серверов в порядке очередности, один прокси-сервер с RAM 650 Мб вполне комфортно себя чувствует при auth_param ntlm children = 200, при трех прокси-серверах количество потоков авторизации уже равно 600;
    • масштабируемость — при необходимости разгрузить сервера можно просто скопировать жесткий диск существующего прокси и за 5-10 минут создать новую машину в полной боевой готовности;
    • рациональное использование аппаратных ресурсов — две предыдущие задачи решены за счет повысившейся нагрузки на процессор;
    • отказоустойчивость — достаточно иметь копии машин PROXY_CONFIG и PROXY1 и после падения можно восстановить всю схему, неторопливо попивая кофе, а для полного спокойствия можно периодически бэкапить жесткий диск гипервизора, благо Linux не будет выпадать в синие экраны при попытке вставить жесткий диск в другой системный блок.

    Автоматическое переключение между доменной и недоменной конфигурациями

    Время показало, что в случае сбоев хорошо бы было, если бы прокси-сервер умел определять, все ли нормально с подключением к контроллеру домена, и в противном случае применял не зависящую от контроллера конфигурацию, а при восстановлении контроллера возвращался к тому функционалу, ради которого все это задумано.
    Меньше слов, больше дела!
    
    #!/bin/bash
    # Проверяем, локальный или сетевой конфиг сейчас в работе
    /bin/ls -la /etc/squid/squid.conf | /bin/grep 'local'
    LOCAL=$?
    echo Local configuration - $LOCAL
    # Проверяем, авторизует ли контроллер домена
    /usr/bin/ntlm_auth --username=ad_user --password=ad_pass 2>/dev/null 1>/dev/null
    if [ $? != 0 ]; then
           # Если контроллер не авторизует
           echo No connection with domain
           if [ $LOCAL -eq 1 ]; then
    		# Если при этом включена доменная конфигурация
    		# то меняем ее на локальную
    		echo Reconfigure to local
            	/bin/rm /etc/squid/squid.conf
            	/bin/ln -s /etc/squid/squid.conf.local /etc/squid/squid.conf
            	/usr/sbin/squid -k reconfigure
    		# уведомляем админа почтой о том, что случилось
                    /usr/bin/php5 /home/squiduser/mail/mail.php 'from' 'Proxy XX - Gone to non-domain mode' '=('
           fi
           # Пробуем автризоваться в домене 
           /etc/init.d/joindomain
    else
           # Если связь с доменом в порядке
           echo OK connection to domain
           if [ $LOCAL -eq 0 ]; then
    	       # Если при этом включена локальная конфигурация
    	       # то меняем ее на сетевую
                   echo Reconfigure to domain
                   /bin/rm /etc/squid/squid.conf
                   /bin/ln -s /var/www/squid/squid.conf /etc/squid/squid.conf
                   /usr/sbin/squid -k reconfigure
    	       # уведомляем админа о том, что все вернулось на круги своя
                   /usr/bin/php5 /home/squiduser/mail/mail.php 'from' 'Gone to domain mode' '=)'
           fi
    fi
    

    Примечания:
    • файл /etc/squid/squid.conf является символической ссылкой файлы с локальной или доменной конфигурацией (squid.conf и squid.conf.local);
    • для уведомления используется скрипт mail.php, который отправляет сообщение на корпоративную почту;
    • /etc/init.d/joindomain — скрипт ввода компьютера в домен.

    Логика скрипта представлена на рисунке ниже.

    Чтобы не синхронизировать скрипт в будущем на всех прокси-серверах, закидываем его в сетевую шару на машине PROXY_CONFIG, монтируем ее на всех проксиках и добавляем скрипт в cron на каждую минуту. Таким образом, при пропадании связи с доменом время простоя будет сокращено до одной минуты, то есть злые бухгалтера не успеют позвонить или успеют, но практически сразу возрадуются.
    Ну вот, собственно и все. Все работает, проблемы отсутствуют. Хотелось бы сразу ответить на часто задававшиеся мне вопросы по поводу описанной конфигурации.
    Вопрос 1
    не проще ли развернуть один реальный прокси-сервер на хорошей аппаратной платформе, чем заморачиваться с виртуальными машинами?
    Ответ
    развернуть — да, проще, управлять — нет. Конечно, если организация небольшая и вы отвечаете и за прокси, и за контроллеры, то городить такой огород нет смысла. В случае же присутствия распределенной сети отделений, филиалов, когда обязанности и ответственность админов разделены, то такая система, «ожидающая» лучшей инфраструктуры — лучшее, что пришло в голову. Если раньше при резком подключении двух новых отделений мне приходилось лезть в конфигурацию и увеличивать количество потоков авторизации, продираясь через жуткие тормоза ОС, развернутой на железе, потом при отказе КД отключать от прокси сетевой кабель, потому что без КД все висит даже локально, тратить несколько десятков минут на ожидание отвисания, то теперь я уже и забыл, как выглядит тот системник, на котором все это развернуто, помню только, что он был черный.
    Вопрос 2
    зачем надо проверять статус подключения к домену, не проще ли устранить неполадки с контроллером?
    Ответ
    см. ответ на вопрос 1 в части разделения полномочий.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 57

      +2
      Логики с более оптимальным использованием оперативной памяти не уловил. По-моему все осталось также + накладные расходы от вм.
        –1
        А я и не говорил, что оперативная память стала лучше использоваться. Меня досаждало только, что ОЗУ забита, а процессор (практически самая дорогая часть системника) отдыхает. Здесь же я загрузил процессор, за счет чего появилось больше времени на распитие кофе.
          0
          А исходя из чего делался вывод о том, что ОЗУ забито? Если один экземпляр ntlm_auth занимает в оперативной памяти около 60 мегабайт, то делать вывод о том, что десять экземпляров будут занимать 600 мегабайт, мягко говоря, неверно.
            0
            Вывод делался на основе показаний top'а:
            image

            Просто в моей конфигурации, как я написал под UPD, используется скрипт, аналогичный wbinfo_group.pl, для определения самого доменного логина пользователя, чтобы можно было каждому конкретному пользователю выдать привилегии, отличающиеся от привилегии его группы (дополнительный запрет или дополнительное разрешение), так как в коробочной поставке Squid'а такого функционала нет. Соответственно, файл squid.conf становится значительно больше в размерах и больше ресурсов тратится на его обработку, что, конечно, не есть гуд, но в моем случае это нужно.
              0
              По данному выводу видно, что в наличии куча памяти и система вообще ничем не загружена.
              p.s. А что такое «обработка squid.conf»? Это какой-то ресурсоёмкий процесс?
                0
                Я вижу, что из 641116 K занято 607148K, свободно 33968K, то есть свободно 5%.

                По поводу обработки squid.conf… Вообще, как мне кажется, чтение строки ACL и сравнение текущего запроса с этим ACL при большом количестве этих самых ACL, затем обработка http_access для этих ACL — довольно ресурсоемкий процесс. Особенно, если в конфиге содержится 1000 строк касательно http_access и 200 касательно ACL.

                При этом несколько раз в секунду запускаются два процесса, отбирающие 100М оперативной памяти.

                Это эмпирическое наблюдение, а не теоретические выкладки.
                  0
                  Системы unix-like используют «свободную» память под дисковый кеш и прочее.

                  Можете в этом убедиться, запустив htop. Он зеленым покажет использование памяти процессами userspace'а, а желтым — использование памяти под кеш.

                  Ну а по поводу памяти отдельного процесса, VIRT — это НЕ количество занимаемой физической памяти
        +3
        > В случае же присутствия распределенной сети отделений, филиалов, когда обязанности и ответственность админов разделены, то такая система, «ожидающая» лучшей инфраструктуры — лучшее, что пришло в голову.

        В таком случае лучшей идеей будет Forefront TMG в массиве, управляемом с Enterprise Management Server. IMHO.
          0
          Возможно так, только стоимость решения поболе будет :)
          +2
          Как-то все сложно у вас получается, у меня 30 потоков ntlm_auth обслуживает ~300 пользователей (по 8 мегабайт на поток) + 2 потока winbind по 12 мегабайт.

          Проблема с отваливанием контроллера домена и запросом авторизации решается через указание:

          krb5.conf
          dns_lookup_kdc = yes
          ну и для верности:
          admin_server=tcp/domain.local
          kdc=tcp/domain.local

          smb.conf
          security = ads
          password server = *
            0
            upd: не туда глянул, по 2.5 мегабайта на поток + по 2 мегабайта на winbind
              0
              Вот с памятью и потоками ничего не мог поделать. Как-то они ее сжирают, как — не знаю :) Скриншот не врет. При первом тестировании было 5 процессов ntlm_auth, 4 пользователя прокси уже не осилил (или 5 — точно не помню).
              За совет спасибо, обязательно потестирую, есть только один вопрос: когда проблема именно в контроллере домена (грубо говоря, из него выдернули сетевой кабель), приведенные вами опции спасут положение?
              Для меня важно, чтобы даже в таком случае (с кабелем) все автоматически перешло на недоменную конфигурацию и продолжило работу до лучших времен :)
                +2
                Может быть лучше на этот случай иметь бакап-контроллер (а еще лучше не один)? Если выдергивают кабель из контроллера домена при единственном контроллере — это беда для домена…
                  –1
                  Конечно, лучше, я не спорю :)
                  Но, во-первых, разделение полномочий :)
                  Во-вторых, пока есть глюки с доменом, есть глюки с проксей.
                  Здесь же, во-первых, уменьшается головная боль во время заскоков домена, во-вторых, есть отчетность, которая показывает, когда происходили заскоки и сколько они длились. Ну а третий фактор — легче администрировать. Может, он и очень субъективный, но радость доставляет :)
                  +2
                  Т.е. у вас 200+ пользователей и 1 контроллер домена? Если из него выдернуть кабель, вся сеть перестанет корректно работать, оставшись без авторизации и DNS.

                  То, что я предложил, это динамическое переключение между контроллерами домена, т.е. их должно быть больше одного в сети.
                    –1
                    Я знаю, что будет, если выдернуть кабель :) Но статья-то о проксях :)
                      +1
                      Тут просто нужно настучать по шее админу, кто следит за доменом, а не придумывать костыль, там где он не нужен, ИМХО.
                        +1
                        Я, конечно, согласен.
                        Но, есть несколько замечаний.
                        1. Тематика данного ресурса не включает в себя вопросы рукоприкладства.
                        2. Ситуации в жизни бывают разные, решения для них нужны тоже разные.
                        3. Добрая половина всех решений в администрировании — костыли. Кто-то их использует, потому что нет денег на покупку software+hardware, кто-то просто из своих принципов. Костыли собираются в сборники, публикуются в блогах. Какой-то костыль дает ознакомившемуся с ним человеку вдохновение написать какую-то софтину, которая потом становится известным и признанным костылем, автоматизирующим что-то и позволяющим устранить недоработки или недосмотры крупных производителей ПО, и уже никто не называет ее костылем, а называют «классная софтина».
                          0
                          Каждый опубликованный костыль вдохновляет ещё кого-то создать ещё один, а вовсе не написать клёвую софтину. А хочется чтобы распространялось больше информации о грамотном проектировании и реализации, потому что в большинстве случаев костыли возникают там, где всё спроектировано и реализовано вразрез с рекомендациями и бест практизами.
                            0
                            В большинстве случаев грамотно проектировать и реализовывать мешают финанасовые директора и существующая инфраструктура, в которой время простоя фактически сказывается на вашем здоровье. К сожалению, мы не в сферическом вакууме, где ИТ существует ради ИТ.
                  0
                  В вашем случае проверялась принадлежность пользователя группе? Или каждой конкретной пользовательской доменной учетной записи можно было назначить свои права и привилегии, отличающиеся от тех, которые были предоставлены группе, членом которой он является?
                +1
                Почему вы выбрали авторизацию ntlm_auth? Я после недолгого промежутка в работе с данной схемой решил отказаться от неё в пользу negotiate(kerberos).
                Так же интересует отличие локального режима от доменного? Или вы дублировали всех пользователей с их паролями в отдельный файл и использовали basic авторизацию?
                В итоге из 7 задач поставленных в начале — вы решили лишь две.
                  0
                  Контроллер домена находится не в моем ведении, и у меня нет особого желания погружаться в дебри, рискуя свалить какой-нибудь сервис, ибо простой даже в один час очень дорого обходится. Я выбрал тот инструмент, который показался более удобным в тот момент времени.

                  Насчет отличий локального и доменного режима.
                  Данный прокси вводился мной для решения задач более информационной безопасности, нежели администрирования, учета рабочего времени и т.п. Основная его задача — блокирование передачи файлов в интернет (через веб-формы, через mail.ru агент, через icq). Эти задачи выполняет iptables гипервизора в независимости от домена. Вторая задача — разграничение доступа к интернету. При отсутствии связи с доменом, для того, чтобы никто не звонил, не писал, не заходил, не кричал, не плакал, я жертвую решением второй задачи, но я на 100% уверен, что решение первой задачи работает в прежнем режиме.

                  Насчет семи перечисленных… Насчет настройки Squid'а на работу с AD, я думаю, писать уже не стОит, ибо все давно написано. Очень хороший мануал есть у lissyara. Как пробросить пакеты мимо прокси средставми iptables — вроде тоже не очень сложная задача. А вот повышение отказоустойчивости с как можно меньшей стоимостью владения решением — это и есть тема топика :)
                    0
                    Т.е. локальный режим разрешает доступ всем пользователям без авторизации, но с функцией блокировки?
                      0
                      Именно в данном случае — да. Естественно, никто не мешает накатать в качестве локального конфига что-то умопомрачительное, это вопрос времени и сил :) Хотелось рассказать и получить критику самой сути решения — пул прокси-серверов + переключение с уведомлением. Просто, как мне кажется, выпустить всех с блокировками гораздо лучше, чем, например, находясь на больничном или в отпуске, принять звонок со словами «у нас тут все поломалось, выходи срочно». А здесь — все работает и ждет своего часа. Все довольны.
                    0
                    >Автоматическое переключение между доменной и недоменной конфигурациями
                    Оно у вас запускается на каждом прокси сервере? Если нет — то получается, что реконфигурация запускается только на компьютере со скриптом. А другие сквиды работают с старым конфигом.
                      +1
                      >Чтобы не синхронизировать скрипт в будущем на всех прокси-серверах, закидываем его в сетевую шару на машине PROXY_CONFIG, монтируем ее на всех проксиках и добавляем скрипт в cron на каждую минуту.

                      Вот так выглядит отчетность:
                      0
                      У вас работает авторизация по kerberos, если пользователь находится в дружественном лесу, а не в основном?
                        0
                        К сожалению, не могу ответить на этот вопрос, потому что все в одном лесу.
                      0
                      > Изрядно намучившись с гуглом, различными продуктами и решениями, я подумал: «суть конфигурирования состоит в генерации файла squid.conf, на php мне как-то доводилось писать, а почему бы не реализовать веб-интерфейс самому?» Сказано — сделано.


                      А можно посмотреть, что сделано? Имею такие же проблемы с SAMS, думал в статье увидеть решение, а его там не оказалось. Спасибо
                        0
                        Это интерфейс в аскетическом стиле. Настройки хранятся в базе mysql. При нажатии ссылки «применить настройки» происходит генерирование файла squid.conf и реконфигурирование squid'а. Мне хватает :)
                        Скриншоты
                          0
                          А не мог бы выложить iptables правила очень интересно посмотреть!
                            0
                            Правила блокирования передачи файлов? Или какие?
                              0
                              Да передачи файлов и балансировка
                                0
                                Балансировка — как в топике, только еще плюс
                                iptables -t nat -A POSTROUTING --dst $PROXY_NET -p tcp --dport 3128 -j SNAT --to-source $GW_IP_2

                                Где $GW_IP_2 — адрес интерфейса гипервизора, который смотрит в сеть прокси-серверов.

                                Про блокировку завтра напишу, сейчас под рукой нет, а наизусть не помню :)
                                  0
                                  Создаем цепочки для обработки:
                                  iptables -N MRA_Packets
                                  iptables -N ICQ_Packets
                                  iptables -N WebForm_Packets


                                  Здесь сама логика обработки цепочек:
                                  # MRA_Packets rules
                                  iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j LOG --log-prefix "MRA File Transferring: " --log-level 7
                                  iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j REJECT
                                  # ICQ_Packets rules
                                  iptables -A ICQ_Packets -m string --algo bm --hex-string '|09 46 13 43 4c 7f 11 d1 82 22 44 45 53 54 00|' -j LOG --log-prefix "ICQ File Transferring: " --log-level 7
                                  iptables -A ICQ_Packets -m string --algo bm --hex-string '|09 46 13 43 4c 7f 11 d1 82 22 44 45 53 54 00|' -j REJECT


                                  А вот так iptables понимает, что пакеты нужно направить в соответствующие цепочки:
                                  iptables -A INPUT -s 192.168.100.0/24 -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
                                  iptables -A OUTPUT -d 192.168.100.0/24 -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
                                  iptables -A INPUT -s 192.168.100.0/24 -m u32 --u32 "38&0xFFFF=0x2A02 && 46=0x00040006" -j ICQ_Packets
                                  iptables -A OUTPUT -d 192.168.100.0/24 -m u32 --u32 "38&0xFFFF=0x2A02 && 46=0x00040007" -j ICQ_Packets
                                  iptables -A INPUT -s 192.168.100.0/24 -m string --algo bm --string 'Content-Disposition: form-data; name="' -j WebForm_Packets
                                  iptables -t nat -A PREROUTING -s 192.168.100.0/24 -m string --algo bm --string 'Content-Disposition: form-data; name="' -j WebForm_Packets
                                    0
                                    Забыл логику для цепочки WebForm_Packets:
                                    # WebForm_Packets rules
                                    iptables -A WebForm_Packets -m string --algo bm --string 'filename=""' -j ACCEPT
                                    iptables -A WebForm_Packets -m string --algo bm --string 'filename="' -j LOG --log-prefix "Uploading Packet: " --log-level 7
                                    iptables -A WebForm_Packets -m string --algo bm --string 'filename="' -j REJECT
                            0
                            простите коллега, но чушь…

                            auth_param ntlm children = 200? не многовато? у меня 200 человек без проблемм на ntlm аутентификации сидят… если имеется ввиду проблема отвала домена с ошибкой в лог а ля…

                            libsmb/ntlmssp.c:342(ntlmssp_update)
                            got NTLMSSP command 1, expected 3

                            то она при компиляции самбы решается так…

                            /usr/ports/net/samba3/work/samba-3.0.37/source/libsmb/ntlmssp.c

                            строка 333.
                            Было:
                            if (ntlmssp_command != ntlmssp_state->expected_state) {
                            DEBUG(1, («got NTLMSSP command %u, expected %u\n», ntlmssp_command, ntlmssp_state->expected_state));
                            return NT_STATUS_INVALID_PARAMETER;
                            }

                            Стало:
                            if (ntlmssp_command != ntlmssp_state->expected_state) {
                            DEBUG(1, («got NTLMSSP command %u, expected %u\n», ntlmssp_command, ntlmssp_state->expected_state));
                            return NT_STATUS_OK;
                            }

                            сам долго мучался… грабли, но работает как часики
                              0
                              200 человек на 15 чилдренах имею ввиду
                                0
                                Встречный вопрос.
                                Проверялась принадлежность пользователя группе? Или каждой конкретной пользовательской доменной учетной записи можно было назначить свои права и привилегии, отличали ющиеся от тех, которые были предоставлены группе, членом которой он является?
                                  0
                                  *отличающиеся
                                  курсор перескочил
                                +1
                                У нас в свое время прокси такого типа (squid+squidbalance+sams+AD) на более слабой машине и обслуживал более 200 клиентов и работал нормально.
                                Так что с вашей машиной «компьютер CPU Core i3/RAM 4 Gb/HDD 500 Gb;» вообще не должно было быть проблем с нормальной настройкой.
                                А по трафику у вас нет ограничений и по скорости?
                                  0
                                  Здесь тоже работал нормально на более слабой машине.
                                  Я сделал запас ресурсов из-за постоянно появляющихся новых пользователей.
                                  По трафику и скорости ограничений нет.
                                    0
                                    В вашем случае проверялась принадлежность пользователя группе? Или каждой конкретной пользовательской доменной учетной записи можно было назначить свои права и привилегии, отличающиеся от тех, которые были предоставлены группе, членом которой он является?
                                      0
                                      по группам, привилегии у нас были по IP+MAC, да и давно было уже.
                                        0
                                        А в моем случае привязка прав идет к группе+логину. Доступ к социальным сетям, почтовым серверам, файлообменникам ограничен. И вообще, руководителями выдвигаются различные требования к привилегиям доступа их сотрудников.
                                        IP-адрес как критерий отбора я сразу отбросил, потому что на DHCP он уже не критерий.
                                        MAC'и тоже есть как критерии, но у iptables на гипервизоре.

                                        В общем, разобрались, куда память уходит :)
                                    0
                                    ntlm это прошлый век, kerberos лучше использовать
                                      0
                                      Никогда не встречал «белых» MAC-адресов =)
                                      Устойчивая фраза «белый адрес» в моём понимании — глобально маршрутизируемый IP адрес.

                                      Ошибка или некорректное использование «термина»? Работаю с сетями и эта фраза ой как глаз режет.

                                      Правильно ли я понял, что все прокси выходят в интернет под одним IP адресом? Т.е. прокси имеют серый IP адрес на внешнем интерфейсе и потом пограничный маршрутизатор их NAT`ит?

                                      Если на разных прокси будет настроен свой белый IP адреса, то будет плохо работать. Веб-сервера в интернете будут получать запрос с разных IP адресов для одной сессии пользователя, а многие привязывают сессию к IP адресу… СтОит добавить в текст.
                                        0
                                        Прошу прощения, это внутренняя терминология. Исправил «белый» на «VIP».

                                        Между прокси и внешним миром есть пограничный маршрутизатор. Только гипервизор знает, что прокси несколько.
                                        0
                                        А как в такой реализации выглядела авторизация со стороны клиента. Я так понимаю сквозная авторизация не работает? То есть открывая браузер нужно еще и логин с паролем вводить, но только доменные? А если сдохло AD, то логин с паролем те-же? Если нет, то как пользователи должны об этом узнать? Если да, то как вы дублируете пароли из AD?

                                        А про падения AD вы говорите так, как будто оно раз в неделю происходит. На моей памяти еще ни один DC не падал, и при этом их всегда было минимум два. А что до разделения обязанностей, так оно много где так. Должна быть плотная и постоянная коммуникация между сотрудниками/отделами/компаниями-оутсорсерами.
                                          0
                                          > А как в такой реализации выглядела авторизация со стороны клиента.


                                          > А если сдохло AD, то логин с паролем те-же?
                                          Комментарий выше

                                          > А что до разделения обязанностей, так оно много где так. Должна быть
                                          А деятельность законодательной, исполнительной и судебной властей должна быть направлена на защиту интересов граждан государства. Аналогию можете провести сами.
                                          0
                                          /usr/bin/ntlm_auth…
                                          if [ $? != 0 ]; then

                                          Сам так раньше писал. Но в shell-скриптах можно проще и красивее:

                                          if ! /usr/bin/ntlm...... ;then

                                          срабатывает, как раз когда код возврата ($?) не равен 0
                                            0
                                            Спасибо, записал :)
                                            0
                                            А вот ктобы подсказал, как сделать отказоустойчивый кластер из squid с Kerberos аутентификацией… Пока сделал через 3 сквида, один из которых child с ACL и авторизацией и 2 parent, к которым не разрешен доступ напрямую.
                                            Вот только failover тут нету никакого — падает child прокси и все…
                                              0
                                              А если по такому же принципу? ACL в отдельном месте, дети получают доступ к ним по сети, а от клиентов такой же разброс на child'ов?
                                                0
                                                Kerberos аутентификация подразумевает наличие SPN fqdn-имени прокси. Выставлен будет в настройках один адрес, а по факту — обращение будет к другому. Есть мнение, что так работать не будет…
                                                  0
                                                  Мне кажется, стоит попробовать. Я через некоторое время после написания статьи переводил прокси на Kerberos, у меня со стороны клиента ничего не менялось, и никаких новых проблем не появлялось. Правда и старые не решались, но это другая история ))

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое