Выдаём предупреждение о необходимости использования прокси

    Иногда в локальной сети появляется необходимость выпускать пользователей в интернет через прокси-сервер. Например, для учёта трафика или ограничения доступа к определённым ресурсам. При этом использование прозрачного прокси невозможно или нежелательно.

    Информируем пользователей


    Можно, конечно, просто сделать рассылку на всех с указанием параметров. Но, как показывает практика, это не избавляет полностью от лишних вопросов.

    Облегчаем жизнь


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

    Выбираем сервер


    Особо продвинутые могут спросить: а зачем что-то выбирать, когда есть Apache? Отвечаю заранее: Apache в данном случае сильно избыточен и будет только зря расходовать ресурсы, которых на шлюзе, скорее всего, и так немного. Поэтому будем использовать более лёгкий вариант. От сервера потребуется умение слушать 80 порт (ибо inetd нам не нужен) и поддержка пользовательских сообщений об ошибках (нам понадобится реагировать на 404). Вполне подходящим вариантом является thttpd.

    Установка и настройка


    В дальнейшем предполагается, что на шлюзе установлен Debian Etch. Ставим thttpd обычным способом:

    # aptitude install thttpd


    Создаём файл /var/www/index.html и в нём описываем всё необходимое для того, чтоб пользователь мог спокойно настроить свой браузер: адрес прокси-сервера, порт, пожелания приятно провести время и тому подобное.

    Для того, чтобы пользователь при попытке вылезти наружу видел не сообщение об ошибке, а нашу красивую инструкцию, добавляем правило в iptables:

    # iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT


    Теперь любая попытка выбраться наружу через 80 порт попадёт на thttpd. Открываем habrahabr.ru и видим вместо него то, что мы и хотим увидеть.

    Ловим 404


    Как можно заметить, при попытке зайти на какую-то страницу, не являющуюся корнем домена, мы получим 404. В thttpd собственный обработчик ошибок устанавливается очень просто. Нам даже нет необходимости что-то менять в конфиге.

    # mkdir /var/www/errors
    # cd /var/www/errors
    # ln -s ../index.html err404.html


    К сожалению, thttpd пытается показать свою значимость и дорисовывает внизу страницы свой баннер, портящий наш красивый валидный XHTML Strict. К счастью, это лечится.

    Практическая хирургия


    Берём машину с той же версией дебиана, что и на шлюзе. Идём на packages.debian.org и качаем оттуда исходники пакета в виде трёх файлов:

    $ wget -c http://ftp.de.debian.org/debian/pool/main/t/thttpd/thttpd_2.23beta1-5.dsc http://ftp.de.debian.org/debian/pool/main/t/thttpd/thttpd_2.23beta1.orig.tar.gz http://ftp.de.debian.org/debian/pool/main/t/thttpd/thttpd_2.23beta1-5.diff.gz


    Ставим утилиты для разработчика:

    $ sudo aptitude install dpkg-dev build-essential fakeroot debhelper


    Распаковываем пакет:

    $ dpkg-source -x thttpd_2.23beta1-5.dsc
    $ cd thttpd-2.23beta1


    Редактируем файл config.h. Находим там следующую строку:

    #define ERR_APPEND_SERVER_INFO


    И комментируем её:

    /*#define ERR_APPEND_SERVER_INFO*/


    Используем именно такой тип комментария, т. к. это C, а не C++.

    Также можно провести ещё некоторые настройки. Например, отключить поддержку CGI и установить кодировку по умолчанию в UTF-8. Читайте комментарии в конфиге.

    Далее таким же образом открываем файл debian/changelog. Необходимо увеличить номер версии пакета, чтобы при следующем обновлении он не оказался перезаписан версией из репозитория. Это может произойти даже в том случае, если пакет на самом деле не обновлялся.

    В начале файла видим запись следующего вида:

    thttpd (2.23beta1-5) unstable; urgency=high

    * Applied patch from Steve Kemp <skx@debian.org> on thttpd.logrotate to fix
    the insecure use of temporary files when invoked by logrotate
    [CVE-2006-4248] (Closes: #396277).

    -- Daniel Baumann <daniel@debian.org> Tue, 31 Oct 2006 20:13:00 +0200


    Добавляем перед ней свою. Обращаем внимание на форматирование и оставлям одну пустую строку перед тем, что в файле уже было.

    thttpd (2.23beta1-5pupkin1) unstable; urgency=low

    * Minor configuration changes required for Company X

    -- Vasily Pupkin <pupkin@example.com> Mon, 17 Nov 2008 13:18:00 +0200


    Собираем пакет:

    $ dpkg-buildpackage -rfakeroot


    В каталоге уровнем выше образовался файл thttpd_2.23beta1-5pupkin1_i386.deb. Заливаем его на шлюз, устанавливаем и радуемся результату.

    upd.: freefd написал статью про автоконфигурацию и предоставил пример страницы с настройками.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        чё-т не хочет, предлагает только персональный и Linux не для всех
        –1
        Пожалуйста, убери инструкции по настройке системы для компиляции, она работает совсем не для всех.
          0
          А что там может не работать? Я на голом vds тестил, всё работает.
            0
            Просто это неправильно. В разных системах это делается по-разному, например, в Дженте собирать программы можно всегда.
              +3
              Я дал пример для дебиана, у кого другой дистр, уже разберётся, как что делать. А так заодно показывается отсутствие необходимости засирать систему путём make install.
                0
                В любом случае любой пользователь линукса должен разбираться путём чтения документации к дистрибутиву.
          0
          Есть еще вот такое:
          www.ossg.ru/wiki/Admin/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F%20%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0%20proxy

          в конце написано, как под ie автоматизировать настройку прокси.
            +1
            Так то под IE, а такой вариант будет работать под всеми браузерами.
              0
              ну под IE как дополнение к вышеописанному, чтобы исключить лишнюю ручную работу.
            0
            Если уж лезть в исходники, можно было и самому соорудить мини-прогу на абсолютно любом языке, которая тупо отвечает на все запросы на 80-ый порт нужной страничкой. Такая прога займёт несколько строк :) Ну и естественно, через iptables на неё попытки пролезть во внешний мир перебрасывать.

            Это я по поводу экономии ресурсов :-D
              0
              Одно дело пару строк в конфиге исправить, а совсем другое — писать с нуля сервер, разбираться с потоками и т.д.
              0
              автоконфигурация прокси на основе dns и dhcp вполне дополнит этот метод.
              работает в ie и firefox… к сожалению в опере нужно самому прописывать путь к скрипту автоконфигурации прокси
                +1
                Во-во… Зачем что-то изобретать, если есть wpad?
                  +1
                  ну как вариант информация для тех, у кого не работает wpad… увы всяко быть может. кто то галочку не поставил, гном например тоже не понимает автоконфигурацию… нужно прописывать путь к скрипту…
                    0
                    Wpad иногда не срабатывает, а такой метод даст пользователю нормальное объяснение с инструкцией вместо пустой страницы.
                  0
                  если наружу 80 порт напрямую выпускать нельзя то что может остановить от прозрачного проксирования?
                    +1
                    Например, то, что на шлюзе 150 пень с 32 метрами рамы, а прокся находится в той же подсети, что и клиенты. Я так и не смог сделать в таких условиях прозрачное проксирование. Другой человек пытался, у него тоже не получилось.

                    К тому же прозрачный прокси будет работать только на 80 порт, а если надо https или просто порт нестандартный, то опять же бубут с вопросами бегать. А так всё сразу понятно.
                      0
                      прозрачный прокси будет работать на тех портах на каких вы его настроите, хоть на всех сразу.
                      а вопрос с редиректом на прокси отличным от localhost можно решить например установки на шлюз OpenBSD, для вышеупомянутой конфигурации будет самый раз.
                        +2
                        И каким образом на нём будет работать HTTPS? Если для HTTPS надо посылать запрос методом CONNECT, а для того, чтоб использовать этот метод, клиент должен явно знать, что обращается к прокси.
                      0
                      Авторизация на прокси, допустим.
                      0
                      хм… учтем-с…
                        0
                        вместо увеличения версии нужно юзать
                        aptitude hold thttpd
                          0
                          Так ты не узнаешь о возможных реальных обновлениях. В данном примере если дебиановцы найдут дыру и выпустят версию 2.23beta1-6, то это можно будет легко заметить и обновить свою сборку соответственно.

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