Все, сдаюсь братцы.
Сори (где манеры). Всем доброго времени суток.
Сил больше нет. Нашел несколько разрозненных примеров по настройке authpf+pf для авторизации доступа в инет. НО создалось такое впечатление, что либо писали для гениев (которые умеют читать мысли и смотреть сразу между пятью строчками), либо я непроходимы тупица :-?.
Задача проста:
Есть сетка из десяти компов. Нужно каждому юзВЕРю дать доступ через OpenBSD доступ в инет без лишнего выпендрежа, но по авторизации (собственно с этой целью и был выбран вариант authpf+pf).
ПОМОГИТЕ!!! Киньте ссылку где бы доступно (для тупых) был описан шаг за шагом. И вконце все ОК (в смысле все проверено и будет работать).
За ранее спасибо. Очень надеюсь на помощ.
Всем удачных удач.
Последние комментарии
-
OlegL, 17 декабря в 15:00 → Перекличка 21
-
REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
-
fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
-
Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
![ecobeing ecobeing](/uploads/ad/image/d543f002e66d5f1767eb81016544b976336e76e5.png)
Мне почему-то видится, что выбран как раз-таки гемморойный способ.
Для случая FreeBSD задача достаточно тривиально решается посредством SQUID + OpenLDAP.
Не думаю, что на OpenBSD будет сложнее.
Для 10 пользователей (и случая ТОЛЬКО доступа в Internet) можно обойтись и без LDAP’а. Но если авторизацию (с централизованным хранением информации о пароле) делать для нескольких сервисов, то даже для 2-х пользователей имеет смысл LDAP.
Чем детальнее инструкция — тем больше трудоёмкость её написания.
Выше вероятность ошибки и неприличная скорость устаревания.
+ слишком часть — неудобочитаемость при наличии знаний (и собственного мнения не тождественного с мнением автора инструкции).
Посему рекомендую приобрести (он того стоит) и прочитать Эви Немет (сотоварищи) «Unix. Руководство системного администратора».
Для случая SQUID 2.6.19 и OpenLDAP задача решается следующим образом:
В /usr/local/etc/squid/squid.conf пишется
SQUID (как и Apache) использует для авторизации соответствующее поле в заголовке пакета. Согласно стандарту допускается указание только одного заголовка, содержащего авторизационные данные. Следовательно через SQUID с авторизацией доступ к ресурсам использующим HTTP-авторизацию типа Basic невозможен. При этом данные для авторизации передаются в незашифрованном виде!
Доступ к FTP-ресурсам с авторизацией возможен только на чтение (SQUID всё равно не обеспечивает возможности полноценной работы с FTP) возможен через браузер при указании логина/пароля в адресной строке.
Для случая списка пользователей в файле — почти аналогично: Read the Fuck.
Это — полный бред. О том, что помимо Authorization: существует еще Proxy-Authorization:, Вы просто не знаете.
Традиционный бред бздишника.
Я бы просил ограничить его рамками ресурса opennet.ru. Здесь нам такой радости не нужно.
Искать цитату в FAQ на http://wiki.squid-cache.org мне лень (там говорится не только про заголовок типа Proxy-Authentication request).
Поэтому просто задам вопрос: Вы когда-нибудь пробовали обратиться через squid с авторизацией (схема Basic) к Апачевскому виртуальному хосту, тоже требующему авторизации (тоже по схеме Basic)?
Попробуйте. Узнаете много интересного. :)
Ничего интересного, все работает, как задумано — в request header клиент посылает Authorization и Proxy-Authorization, и получает желаемый документ с хоста.
Учите матчасть!
Знания теории удовлетворительные.
Вот только далеко не всегда теория совпадает с практикой.
По косвенным признакам — утверждение носит чисто теоретический характер.
Подобными заявлениями opennet.ru полнится.
Поэтому предлагаю вместо громких фраз привести конфиг сквида, информацию об используемом браузере, версию Apache и цитату из конфига описывающую авторизацию.
Где же пример из практики, опровергающий теорию?
Так… Сквид с авторизацией знаем только в теории. Ясненько.
Базовая часть squid.conf — практически дистрибутивная.
В части авторизации:
В httpd.conf доступ к каталогу виртуального хоста описан следующим образом
Мимо прокси — работает замечательно.
Через SQUID — 403 Forbidden
Воспроизвести проблему с такими исходными данными невозможно, это раз. Покажите request headers, которые получает сервер от клиента с и без прокси, это два.
:)))
Не указал очевидного: используется основная по версии портов FreeBSD ветка SQUID’а (ну совершенно неочевидный момент).
Сквид никогда не настраивали, сквида с авторизацией (или web-серверов, требующих авторизацию в Apache) не видели. Суть проблемы знакома хорошо если условно. Понятно.
Вы невменяемы. Прощайте.
Клиент поставит себе поразительно точный диагноз.
Ну и подтвердил отсутствие навыков/понимания конфигурирования SQUID.
Различные типы заголовков авторизации корректно отрабатываются если
Если же
ресурс требующий авторизации прописать в тэге «always_direct», то SQUID отрабатывает как я описал выше.
ЗЫ: Столь «компетентным» (и самовлюблённым) бздунишкам должно сидеть на опеннете и не вякать.