3APA3A 3proxy tiny proxy server HowTo
В стадии разработки

- Компиляция
  - Как скомпилировать 3proxy Visual C++
  - Как скомпилировать 3proxy с помощью CMake
  - Как скомпилировать 3proxy GCC под Unix/Linux
- Установка и удаление 3proxy
  - Как установить/удалить 3proxy под Windows NT/2000/XP/2003 как службу
  - Как установить/удалить 3proxy под Unix/Linux
  - Как установить/удалить 3proxy под macOS
  - Как использовать 3proxy с Docker
- Конфигурация сервера
  - Как заставить 3proxy запускаться
  - Как заставить ограничения (по ширине канала, трафику, ACL и. т.п.) работать
  - Как заставить 3proxy запускаться как службу
  - Как разобраться с internal и external
  - Как починить ведение журналов в ODBC?
  - Как заставить IPv6 работать
  - Как сделать чтобы 3proxy не крешился
  - Как посмотреть пример файла конфигурации
  - Как настроить ведение журнала
  - Как настроить формат журнала
  - Как использовать лог-анализаторы с 3proxy
  - Как запустить конкретную службу (HTTP, SOCKS и т.д)
  - Как повесить службу на определенный интерфейс или порт
  - Как разрешать имена на родительском прокси?
  - Как настроить FTP прокси?
  - Как настроить SNI proxy (tlspr)
  - Как настроить DNS proxy (dnspr)
  - Как настроить TLS/SSL (https прокси, mTLS)
  - Как создать CA и сертификаты для SSL
  - Как использовать PCRE-фильтрацию (регулярные выражения)
  - Как ограничить доступ к службе
  - Как создать список пользователей
  - Как ограничить доступ пользователей к ресурсам
  - Как управлять перенаправлениями
  - Как управлять локальными перенаправлениями
  - Как организовать балансировку между несколькими каналами
  - Как составлять цепочки прокси
  - Как ограничивать скорости приема
  - Как ограничивать объем принимаемого трафика
  - Как пофиксить некорректный подсчет трафика
  - Как управлять разрешением имен и кэшированием DNS
  - Как использовать IPv6
  - Как использовать connect back
  - Как использовать протокол HAProxy PROXY
  - Как установить максимальный размер сегмента TCP (MSS)
- Конфигурация и настройка клиентов
  - Как использовать 3proxy с Internet Explorer или другим браузером
  - Как настраивать FTP клиент
  - Как использовать SMTP через 3proxy
  - Как использовать службу POP3 Proxy
  - Как использовать 3proxy с программой, не поддерживающей работу с прокси-сервером
  - Как использовать 3proxy с играми
- Администрирование и анализ информации
  - Где взять свежую версию
  - Как управлять службой 3proxy в Windows NT/2000/XP
  - Коды ошибок в журнале
- Как задать вопрос, которого нет в HowTo

- Компиляция

  - Как скомпилировать 3proxy Visual C++

    Извлеките файлы из архива 3proxy.tgz (например, с помощью WinZip) или используйте git.

            nmake /f Makefile.msvc

    Исполняемые файлы будут помещены в каталог `bin/`.
  - Как скомпилировать 3proxy с помощью CMake

    CMake предоставляет кроссплатформенную систему сборки. Работает на Windows (MSVC, MinGW), Linux, macOS и BSD.
    Базовые шаги сборки:

            mkdir build
            cd build
            cmake ..
            cmake --build .

    На Windows с Visual Studio можно также сгенерировать файл решения:

            cmake -G "Visual Studio 17 2022" -A x64 ..
            cmake --build . --config Release

    Опциональные функции можно включить через параметры cmake:

            cmake -D3PROXY_USE_OPENSSL=ON -D3PROXY_USE_PCRE2=ON ..

    Доступные опции: 3PROXY_USE_OPENSSL, 3PROXY_USE_PCRE2, 3PROXY_USE_PAM, 3PROXY_USE_ODBC.
    Исполняемые файлы будут помещены в каталог `build/bin/`.
  - Как скомпилировать 3proxy GCC под Unix/Linux

  Для Linux используйте:

          ln -sf Makefile.Linux Makefile
          make

  Для FreeBSD используйте:

          ln -sf Makefile.FreeBSD Makefile
          make

  Для других Unix-подобных систем используйте Makefile.unix. На BSD-производных системах убедитесь, что используете GNU make; иногда он называется gmake вместо make.
  Компиляция проверена на FreeBSD, NetBSD, OpenBSD, Linux, Solaris и macOS.
  Для поддержки ODBC необходимо установить Unix ODBC, убрать -DNOODBC из флагов компиляции и добавить ODBC-библиотеку к флагам линковщика.
  Исполняемые файлы будут помещены в каталог `bin/`.

- Установка и удаление 3proxy

  - Как установить/удалить 3proxy под Windows NT/2000/XP/2003 как службу

    Извлеките файлы из архива 3proxy.zip в любой каталог (например, c:\Program Files\3proxy). Если необходимо, создайте каталог для хранения файлов журналов. Создайте файл конфигурации 3proxy.cfg в каталоге 3proxy (см. раздел Конфигурация сервера). Откройте командную строку (cmd.exe). Перейдите в каталог с 3proxy и дайте команду 3proxy.exe --install:

          D:\>C:
          C:\>cd C:\Program Files\3proxy
          C:\Program Files\3proxy>3proxy.exe --install

    Сервис должен быть установлен и запущен. Если сервис не запускается, попробуйте запустить 3proxy.exe вручную и проанализировать сообщения об ошибках.

    Для удаления 3proxy необходимо остановить сервис и дать команду 3proxy.exe --remove:

          D:\>C:
          C:\>cd C:\Program Files\3proxy
          C:\Program Files\3proxy>net stop 3proxy
          C:\Program Files\3proxy>3proxy.exe --remove

    после чего каталог 3proxy можно удалить.
  - Как установить/удалить 3proxy под Unix/Linux

    С помощью Makefile:
    Скомпилируйте 3proxy (см. раздел Компиляция), затем выполните:

          sudo make install

    Это установит исполняемые файлы в `/usr/local/3proxy/sbin/`, конфигурацию в `/etc/3proxy/` и настроит chroot-каталоги. Файл конфигурации по умолчанию: `/etc/3proxy/3proxy.cfg`.

    С помощью CMake:

          mkdir build && cd build
          cmake ..
          cmake --build .
          sudo cmake --install .

    С помощью готовых пакетов из GitHub:
    Скачайте .deb или .rpm пакеты со страницы GitHub Releases.
    Для Debian/Ubuntu:

          sudo dpkg -i 3proxy_*.deb

    Для RHEL/CentOS/Fedora:

          sudo rpm -i 3proxy-*.rpm

    Добавьте 3proxy в скрипты автозапуска или используйте systemd:

          sudo systemctl enable 3proxy
          sudo systemctl start 3proxy

  - Как установить/удалить 3proxy под macOS

    С помощью CMake (рекомендуется):

          mkdir build && cd build
          cmake ..
          cmake --build .
          sudo cmake --install .

    Это установит:
    - Исполняемые файлы в `/usr/local/bin/`
    - Конфигурацию в `/etc/3proxy/`
    - Плагины в `/usr/local/lib/3proxy/`
    - Launchd plist в `/Library/LaunchDaemons/org.3proxy.3proxy.plist`

    С помощью Makefile:

          ln -sf Makefile.FreeBSD Makefile
          make
          sudo make install

    Это установит исполняемые файлы в `/usr/local/3proxy/bin/` и конфигурацию в `/usr/local/etc/3proxy/`.

    Управление службой через launchd:
    После установки через cmake службой можно управлять с помощью launchctl:

          # Загрузить и запустить службу
          sudo launchctl load /Library/LaunchDaemons/org.3proxy.3proxy.plist

          # Остановить службу
          sudo launchctl stop org.3proxy.3proxy

          # Запустить службу
          sudo launchctl start org.3proxy.3proxy

          # Выгрузить и отключить службу
          sudo launchctl unload /Library/LaunchDaemons/org.3proxy.3proxy.plist

    Служба запускается от имени пользователя `proxy` (создаётся при установке). Файл конфигурации: `/etc/3proxy/3proxy.cfg`
  - Как использовать 3proxy с Docker

    Использование готовых образов из GitHub Container Registry:

          docker pull ghcr.io/3proxy/3proxy:latest

    Сборка Docker-образов:
    Предоставляются два Dockerfile:

    - `Dockerfile.minimal` - минимальная статическая сборка без плагинов, конфигурация из stdin:

            docker build -f Dockerfile.minimal -t 3proxy.minimal .
            docker run -i -p 3129:3129 --name 3proxy 3proxy.minimal

      Затем введите конфигурацию, завершив командой "end".
    - `Dockerfile.full` - полная сборка с плагинами (SSL, PCRE, Transparent):

            docker build -f Dockerfile.full -t 3proxy.full .
            docker run -p 3129:3129 -v /path/to/config:/usr/local/3proxy/conf 3proxy.full

      Файл конфигурации должен находиться по пути `/path/to/config/3proxy.cfg`.

    По умолчанию 3proxy работает в chroot-окружении с uid/gid 65535. Используйте `nserver` в конфигурации для DNS-разрешения в chroot. Для запуска без chroot монтируйте конфигурацию в `/etc/3proxy`.

- Конфигурация сервера

  - Как заставить прокси работать

  Для работы требуется корректный файл конфигурации. Если прокси не запускается, значит в конфигурации есть ошибка.

  - Как заставить работать ограничения (контроль доступа, ограничения ширины канала, счетчики и т.п.)

  A: Обычные ошибки - использование auth none (для работы любых функций, основанных на ACL, требуется auth iponly, nbname или strong), нарушение порядка ввода команд (команды выполняются последовательно, запуск сервиса proxy, socks, tcppm и т.д. должен осуществляться после того, как указана его конфигурация), неправильный порядок записей в ACL (записи просматриваются последовательно до первой, удовлетворяющей критериям). Если в ACL имеется хотя бы одна запись, то считается, что последняя запись в ACL - это неявная deny *.

  - Как починить запуск 3proxy службой

  Чаще всего 3proxy не запускается службой (но запускается вручную) по одной из следующих причин:

  - Использование относительных (неполных) путей файлов в файле конфигурации При использовании файлов журналов, файлов вставок ($filename) используйте полные пути, например, $"c:\3proxy\include files\networks.local". Тоже самое относится к файлам журналов и любым другим. Для отладки лучше запускать 3proxy с ведением журнала на стандартный вывод. Не забудьте в таком случае отключить daemon и service в файле конфигурации. Для чистоты эксперимента запускать 3proxy из коммандной строки в таком случае следует, находясь в другой папке.
  - Отсутствие у системной записи прав на доступ к исполняемому файлу, каким-либо файлам конфигурации, журнала и т.п.
  - Отсутствие файла конфигурации по стандартному расположению - 3proxy.cfg в одном каталоге с исполняемым файлом. Если файл расположен по другому пути, необходимо использовать команду

            3proxy --install path_to_configuration_file

  - Отсутствие у пользователя прав на установку или запуск службы
  - Служба уже установлена или запущена
  - Как разобраться с internal и external

  Убедитесь, что выправильно понимаете что такое internal и external адреса. Оба адреса - это адреса, принадлежищие хосту, на котором установлен 3proxy. Эта опция конфигурации необходима в классической ситуации, когда 3proxy установлен на граничном компьютере с двумя (или более) подключениями:

             LAN connection +-------------+ Internet connection
        LAN <-------------->| 3proxy host |<-------------------> INTERNET
                           ^+-------------+^
                           |               |
                     Internal IP      External IP

  Если 3proxy работает на хосте с одним интерфейсом, то его адрес будет и internal и external.
  Интерфейс с адресом internal должен существовать и быть рабочим на момент запуска 3proxy, и не должен отключаться. Если internal интерфейс периодически отключается, то не следует его указывать, или можно указать адрес 0.0.0.0. При этом прокси будет принимать запросы на всех интерфейсах, поэтому при наличии нескольких интерфейсов для ограничения доступа следует использовать фаервол или хотя бы ACL.

  Интерфейс с адресом external, если он указан, должен быть рабочим на момент получения запроса клиента. При отсутствии external или адресе 0.0.0.0 внешний адрес будет выбираться системой при установке соединения. При этом, может быть возможность доступа через прокси к ресурсам локальной сети, поэтому для предотвращения несанкционированного доступа следует использовать ACL. Кроме того, могут быть проблемы с приемом входящих соединений через SOCKSv5 (SOCKSv5 используется в клиентах исключительно редко). В случае, если адрес динамический, можно либо не указывать external, либо использовать адрес 0.0.0.0, либо, если необходима поддержка входящих соединений в SOCKSv5, использовать скрипт, который будет получать текущий адрес и сохранять его в файл, который будет отслуживаться через команду monitor.

  - Как починить ведение журналов в ODBC

  Убедитесь, что используется системный, а не пользовательский DSN. Убедитесь, что выполняется правильный SQL запрос. Наиболее распространенная проблема связана с отсутствием кавычек или неправильным форматом данных. Самый простой способ - сделать ведение журнала в файл или на стандартный вывод, просмотреть выдаваемые SQL запросы и попробовать дать такой запрос вручную.

  - Как починить IPv6

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

  - Как починить падения 3proxy

  Возможно, недостаточен размер стека потока по-умолчанию, это может быть при использовани каких-либо сторонних плагинов (PAM, ODBC) или на некоторых платформах (некоторые версии FreeBSD на amd64). Можно решить проблему с помощью опции 'stacksize' или '-S', поддерживаемых в 0.8.4 и выше.

  - Как посмотреть пример файла конфигурации

    Пример файла конфигурации 3proxy.cfg.sample поставляется с любым дистрибутивом программы.

  - Как настроить ведение журнала

    3proxy поддерживает ведение журнала на экран (stdout), в файл, через ODBC и через службу syslog (только для Unix/Linux/CygWin). Можно управлять либо общим файлом журнала, задаваемым в файле конфигурации 3proxy.cfg и единым для всех служб, либо индивидуальными файлами для отдельных служб (например, команда socks -l/var/log/socks.log запускает SOCKS прокси и задает для него индивидуальный журнал). Для общего файла журнала поддерживается ротация (т.е. периодическое создание новых файлов журнала с предопределенными именами и удаление файлов старше определенного срока) и архивация файлов журнала. Тип журнала определяется параметром log в файле конфигурации либо ключом -l при вызове конкретной службы (например, socks прокси). log или -l без параметров соответствуют ведению журнала на экран (stdout).

          log filename

    и

          -lfilename

    соответствуют записи журнала в файл filename. Если при указании имени файла в log в нем содержится символ %, то имя рассматривается как форматный спецификатор (см. logformat). Например, log c:\3proxy\logs\%y%m%d.log D создаст файл типа c:\3proxy\logs\060725.log, для образования даты будет использовано местное время.

          log @ident

    и

          -l@ident

    соответствуют ведению журнала через syslog с идентификатором ident.

          log &connstring;

    соответствует ведению журнала через ODBC, connstring задается в формате datasource,username,password (последние два параметра опциональны, если datasource не требует или уже содержит сведения для авторизации). При этом команда logformat должна задавать SQL запрос, который необходимо выполнить для добавления записи в журнал, см Как настроить формат журнала.

    Управление ротацией общего файла журнала происходит с помощью команд файла конфигурации log, rotate и archiver.

          log filename LOGTYPE

    задает тип ротации. LOGTYPE может принимать значения:
    - M, ежемесячная ротация
    - W, еженедельная ротация
    - D, ежедневная ротация
    - H, ежечасная ротация
    - C, ежеминутная ротация

          rotate NUMBER

    указывает на число файлов, участвующих в ротации (т.е. сколько последних журналов хранить).

          archiver EXT COMMAND PARAMETERS

    задает параметры архивации журнала. EXT указывает на расширение архива (например, zip, gz, Z, rar и т.д.) COMMAND указывает на программу и PARAMETERS - на параметры командной строки. Архиватор должен сам удалять исходный файл, также ему можно передать имя файла с помощью макроса %F и ожидаемое имя архива с помощью макроса %A. В качестве архиватора вполне можно задать пакетный файл, который, например, будет загружать данные из журнала в базу данных. Примеры команды archiver для популярных архиваторов можно найти в 3proxy.cfg.sample

          logdump OFFSET_BYTES_FROM_SERVER OFFSET_BYTES_FROM_CLIENT

    Задает смещение в байтах на входящий и исходящий трафик, при достижении которого необходимо создавать запись в журнале даже в том случае, если соединение еще не завершено. Если logdump не указан или значения OFFSET_BYTES_FROM_SERVER OFFSET_BYTES_FROM_CLIENT нулевые - в журнале будет создана единственная запись по окончании обработки запроса клиента (при разрыве соединения). Пример:

          logdump 1048576 1048576

    создает в журнале запись на каждый мегабайт входящего или исходящего трафика.
  - Как настроить формат журнала

    Начиная с версии 0.3, формат журнала может быть настроен с помощью команды logformat со строкой формата. Первый символ строки должен быть L или G, что указывает на формат, в котором будет указываться время и даты, L - текущее локальное время, G - абсолютное время по Гринвичу. Строка формата может содержать следующие модификаторы:

    - %y - Год (последние две цифры)
    - %Y - Год (четырехзначный)
    - %m - Номер месяца (01-12)
    - %o - Трехбуквенная аббревиатура месяца
    - %d - День (01-31)
    - %H - Час (00-23)
    - %M - Минута (00-59)
    - %S - Секунда (00-59)
    - %t - Временная метка (число секунд с 00:00:00 1 января 1970 г. по Гринвичу)
    - %. - Миллисекунды
    - %z - Временная зона в почтовом формате (от Гринвича, '+' восток, '-' запад ЧЧММ), например, Московское зимнее время +0300.
    - %U - Имя пользователя ('-', если отсутствует).
    - %N - Название прокси сервиса (PROXY, SOCKS, POP3P, и т.д.)
    - %p - Порт прокси сервиса
    - %E - Код ошибки (см. Коды ошибок в журнале)
    - %C - IP клиента
    - %c - Порт клиента
    - %R - IP сервера (исходящего соединения по запросу клиента)
    - %r - Порт сервера (исходящего соединения по запросу клиента)
    - %Q – IP, запрошенный клиентом
    - %q – Порт, запрошенный клиентом
    - %I - Принято байт от сервера
    - %O - Отправлено байт на сервер
    - %n - Имя хоста из запроса
    - %h - Число звеньев до конечного сервера (при использовании перенаправлений или чейнинга см. Как составлять цепочки прокси)
    - %T – Текст, специфичный для прокси сервиса (например, запрошенный URL). Можно использовать %X-YT, где X и Y положительные числа, тогда отображаются только поля с X по Y текста. Поля считаются разделенными пробельным символом.
    Пример:

          logformat "L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

    будет генерировать в журнале записи типа

          1042454727.0296 SOCK4.1080 000 3APA3A 127.0.0.1:4739 195.122.226.28:4739 505 18735 1 GET http://3proxy.ru/ HTTP/1.1

    (без переноса строк) При использовании ODBC, logformat должен задавать формат SQL команды, которую необходимо дать для внесения записи в журнал, например:

          logformat "-\'+_GINSERT INTO proxystat VALUES (%t, '%c', '%U', %I)"

    префикс -\'+_ указывает, что символы \ и ' следует заменить на _ .
  - Как использовать лог-анализаторы с 3proxy

    Просто сделайте формат ведения журнала совместимым с одним из форматов, поддерживаемых анализатором. Это позволяет использовать практически любые анализаторы. Примеры совместимых форматов:
    Формат Squid access.log:

          "- +_G%t.%. %D %C TCP_MISS/200 %I %1-1T %2-2T %U DIRECT/%R application/unknown"

    Более совместимый формат, но без %D

          "- +_G%t.%. 1 %C TCP_MISS/200 %I %1-1T %2-2T %U
          DIRECT/%R application/unknown"

    Формат ISA 2000 proxy WEBEXTD.LOG (поля разделены табуляцией):

          "- + L%C %U Unknown Y %Y-%m-%d %H:%M:%S
          w3proxy 3PROXY - %n %R %r %D
          %O %I http TCP %1-1T %2-2T - -
          %E - - -"

    Формат ISA 2004 proxy WEB.w3c (поля разделены табуляцией):

          "- + L%C %U Unknown %Y-%m-%d %H:%M:%S
          3PROXY - %n %R %r %D %O
          %I http %1-1T %2-2T - %E -
          - Internal External 0x0 Allowed"

    Формат ISA 2000/2004 firewall FWSEXTD.log (поля разделены табуляцией):

          "- + L%C %U unknown:0:0.0 N %Y-%m-%d
          %H:%M:%S fwsrv 3PROXY - %n %R %r
          %D %O %I %r TCP Connect - -
          - %E - - - - -"

    Стандартный лог HTTPD (Apache и другие):

          "-""+_L%C - %U [%d/%o/%Y:%H:%M:%S %z] ""%T"" %E %I"

    Более совместимый, но без кода ошибки:

          "-""+_L%C - %U [%d/%o/%Y:%H:%M:%S %z] ""%T"" 200 %I"

  - Как запустить конкретную службу (HTTP, SOCKS и т.д)

    3proxy поставляется в двух вариантах: как набор отдельных модулей (proxy, socks, pop3p, tcppm, udppm) и как универсальный прокси-сервер (3proxy). Универсальный прокси сервер - это законченная программа, которой не требуются отдельные модули.
    Отдельный модуль управляется только из командной строки. Поэтому для отдельного модуля не поддерживаются многие функции, такие как управление доступом и ротация журнала. Запуск модуля осуществляется из командной строки. Например,

          $/sbin/socks -l/var/log/socks.log -i127.0.0.1

    запускает SOCKS на порту 127.0.0.1:1080 с ведением журнала /var/log/socks.log Справку по опциям командной строки можно получить запустив модуль с ключом -?.

    Если используется 3proxy, то запускаемые службы указываются в файле 3proxy.cfg. Файл 3proxy.cfg просматривается 3proxy построчно, каждая строка рассматривается как управляющая команда. Синтаксис команд описан в 3proxy.cfg.sample. Например,

          log /var/log/3proxy.log D
          rotate 30
          internal 127.0.0.1
          external 192.168.1.1
          proxy
          socks
          pop3p -l/var/log/pop3proxy

    запускает 3 службы - PROXY, SOCKS и POP3 Proxy. Каждая слушает на интерфейсе 127.0.0.1 порт по-умолчанию (3128 для proxy, 1080 для socks и 110 для pop3p). Журналы всех служб кроме pop3p ведутся в файле /var/log/3proxy.log, который ежедневно меняется. Хранятся 30 последних файлов. Для pop3p ведется отдельный журнал /var/log/pop3proxy (см. Как настроить ведение журнала).
  - Как повесить службу на определенный интерфейс или порт

    Опция -i позволяет указать внутренний интерфейс, -p - порт (пробелы в опциях не допускаются). Например, чтобы служба proxy висела на порту 8080 интерфейсов 192.168.1.1 и 192.168.2.1 необходимо дать команды

          proxy -p8080 -i192.168.1.1
          proxy -p8080 -i192.168.2.1

  - Как разрешать имена на родительском прокси?

  A: Для этого надо использовать тип родительского прокси http, connect+, socks4+ и socks5+. Однако, при это надо помнить, что самому 3proxy требуется разрешение имени для управления ACL. Поэтому, если с прокси-хоста не работают разрешения имени, необходимо в конфигурации дать команду

        fakeresolve

  которая разрешает любое имя в адрес 127.0.0.2.
  - Как настроить FTP прокси?

  Есть поддержка как FTP через HTTP (то, что называется FTP прокси в браузерах) так и настоящего FTP прокси (то, что называется FTP proxy в командных оболочках и FTP клиентах). В браузерах в качестве FTP прокси следует прописывать порт службы proxy, т.е. FTP организован через http прокси, дополнительного прокси поднимать не надо. Для FTP-клиентов необходимо поднять ftppr. FTP прокси всегда работает с FTP сервером в пассивном режиме.

  - Как настроить SNI proxy (tlspr)

  SNI proxy может быть использован для транспарентного перенаправления любого TLS трафика (например HTTPS) на внешнем маршрутизаторе или локальными правилами. Так же можно использовать его для извлечения имени хоста из TLS хендшейка с целью логгирования или использования в ACL. Еще одна задача которую может решать модуль - требование наличия TLS или mTLS (mutual TLS). Если tlspr используется как отдельный сервис без использования плагина Transparent, то необходимо задать порт назначения через опцию -P (по умолчанию 443), т.к. TLS хендшейк не содержит информации о порте назначения. Примечание: tlspr не поддерживает аутентификацию пользователей (в TLS-хендшейке нет учетных данных); используйте ACL по IP или родительский прокси с аутентификацией, если требуется контроль доступа.

  Опции:

      -P <порт>  - порт назначения (по умолчанию: 443)
      -c <уровень> - уровень проверки TLS:
        0 (по умолчанию) - пропустить трафик без TLS
        1 - требовать TLS, проверять наличие client HELLO
        2 - требовать TLS, проверять наличие client и server HELLO
        3 - требовать TLS, проверять наличие серверного сертификата (не совместим с TLS 1.3+)
        4 - требовать взаимный (mutual) TLS, проверять что сервер запрашивает сертификат и клиент его отправляет (не совместим с TLS 1.3+)
      -Ximap | -Xpop3 | -Xsmtp - режим explicit TLS (STARTTLS): tlspr говорит с клиентом
        на plaintext-протоколе (приветствие, команда STARTTLS), затем поднимает TLS с обеих сторон

  Implicit и explicit TLS:

  Implicit TLS означает TLS с первого байта соединения: https (443), imaps (993), SMTP submission secure (submissions) (465). Explicit TLS означает, что соединение начинается в plaintext и поднимается до TLS командой STARTTLS/STLS: imap (143), SMTP submission (587), pop3 (110). tlspr поддерживает оба варианта: для implicit TLS хост назначения берется из SNI, а порт из -P; для explicit TLS опция -X заставляет tlspr говорить с клиентом на plaintext-фазе протокола (приветствие, команда STARTTLS) перед поднятием TLS с обеих сторон. Пример:

      # https (implicit)
      tlspr -p443 -P443 -c1
      # imaps (implicit)
      tlspr -p993 -P993 -c1
      # submissions (implicit)
      tlspr -p465 -P465 -c1
      # imap STARTTLS (explicit)
      tlspr -p143 -P143 -Ximap
      # submission STARTTLS (explicit)
      tlspr -p587 -P587 -Xsmtp
      # pop3 STLS (explicit)
      tlspr -p110 -P110 -Xpop3

  Примечание: для explicit TLS вместо tlspr -X можно использовать протокольные сервисы smtpp, imapp и pop3p; они также поддерживают STARTTLS.

  Рекомендуемая конфигурация - перенаправление трафика: наиболее универсальная конфигурация - перенаправлять TLS-трафик (порты 443, 993, 465, 143, 587, 110) на tlspr правилами внешнего маршрутизатора или локальными правилами (плагин Transparent). Исходные адрес и порт назначения сохраняются, -P и отдельные сервисы для каждого порта не требуются, implicit и explicit TLS работают в рамках одной установки.

      auth iponly
      allow *
      tlspr -p1443 -c1

  например, с iptables:

      iptables -t nat -A PREROUTING -p tcp -m multiport --dports 443,993,465 -j REDIRECT --to-port 1443

  Также, если клиенты используют dnspr в качестве DNS-резолвера, трафик можно перенаправлять через DNS — см. Как настроить DNS proxy (dnspr).

  SNI Break (обход DPI):
  tlspr может использоваться как родительский прокси типа "tls" для реализации SNI-фрагментации (аналог NoDPI/GoodByeDPI). Клиент отправляет первую часть TLS ClientHello, tlspr разбивает его на расширении SNI и отправляет двумя TCP-пакетами, что позволяет обойти некоторые DPI-системы, ищущие заблокированные имена хостов в TLS-рукопожатиях.
  Для включения SNI break используйте `parent ... tls 0.0.0.0 0` и опцию `-s` на слушающем сервисе с TCP_NODELAY:

      auth iponly
      allow *
      parent 1000 tls 0.0.0.0 0
      allow *
      proxy -s -i127.0.0.1 -ocTCP_NODELAY -osTCP_NODELAY -p1443

  TCP_NODELAY необходим, чтобы ядро не объединяло разделенные пакеты.

  Примеры конфигурации:

  1. Отдельный SNI proxy на порту 1443 с перенаправлением на порт назначения 443:

      tlspr -p1443 -P443 -c1

  2. Использование tlspr как родительского прокси в SOCKS для обнаружения hostname из TLS (даже если клиент подключается по IP):

      allow * * * 80
      parent 1000 http 0.0.0.0 0
      allow * * * * CONNECT
      parent 1000 tls 0.0.0.0 0
      deny * * some.not.allowed.host
      allow *
      socks

  3. Использование tlspr с HTTP proxy для ACL по имени хоста TLS:

      allow * * * * HTTP_CONNECT
      parent 1000 tls 0.0.0.0 0
      deny * * blocked.example.com
      allow *
      proxy

  - Как настроить DNS proxy (dnspr)

  dnspr - сервис пересылки DNS-запросов. Он отвечает на запросы из кэша имен 3proxy (включая статические записи nsrecord), пересылает остальные запросы на резолверы, заданные командой nserver, и кэширует результаты, если настроены nscache/nscache6. Опции:

      -s  - простая пересылка DNS: не использовать резолвер / кэш имен 3proxy
      -F<ip> - fake: отвечать на все A (или AAAA) запросы заданным IP-адресом.
        Может быть указана дважды - один раз с IPv4 и один раз с IPv6 адресом.

  dnspr можно использовать для перенаправления трафика по имени хоста, например, чтобы направить почтовых клиентов на установку tlspr, добавив записи nsrecord для имен почтовых сервисов (nscache/nscache6 сохраняют ответы для всех остальных имен):

      nscache 65536
      nscache6 65536
      dnspr -p53

      # google
      nsrecord smtp.gmail.com 10.0.0.1
      nsrecord imap.gmail.com 10.0.0.1
      nsrecord pop.gmail.com 10.0.0.1
      # mail.ru
      nsrecord smtp.mail.ru 10.0.0.1
      nsrecord imap.mail.ru 10.0.0.1
      nsrecord pop.mail.ru 10.0.0.1
      # yandex.ru
      nsrecord smtp.yandex.ru 10.0.0.1
      nsrecord imap.yandex.ru 10.0.0.1
      nsrecord pop.yandex.ru 10.0.0.1

  где 10.0.0.1 - адрес, на котором слушает tlspr. Если перенаправлять нужно все имена, вместо отдельных записей nsrecord можно использовать один fake-адрес:

      nscache 65536
      nscache6 65536
      dnspr -p53 -F10.0.0.1

  - Как настроить TLS/SSL (https прокси, mTLS)

    Начиная с версии 0.9.7 поддержка TLS/SSL встроена в 3proxy при компиляции с OpenSSL (WITH_SSL). Ранее доступная как SSLPlugin, функциональность теперь интегрирована в основной бинарный файл. Строка plugin больше не нужна. TLS/SSL может использоваться для:

    - Создания https:// прокси (TLS-шифрованное соединение между клиентом и прокси)
    - Реализации MITM для инспекции TLS-трафика
    - Соединения с вышестоящими серверами через TLS с аутентификацией по клиентскому сертификату
    - Требования аутентификации по клиентскому сертификату (mTLS)

    Создание https:// прокси:
    Для создания https:// прокси требуется сертификат и ключ сервера. Сертификат не должен быть самоподписанным и должен содержать альтернативные имена (SAN) для имени хоста/IP прокси.

        ssl_server_cert /etc/3proxy/certs/server.crt
        ssl_server_key /etc/3proxy/certs/server.key
        ssl_serv
        proxy -p3129
        ssl_noserv
        proxy -p3128

    Создаётся https:// прокси на порту 3129 и http:// прокси на порту 3128. Настройте клиенты на использование https://proxy-host:3129/ в качестве URL прокси.

    Аутентификация по клиентскому сертификату (mTLS):
    Чтобы требовать от клиентов аутентификацию по сертификату, используйте ssl_server_verify и укажите CA-сертификат:

        ssl_server_cert /etc/3proxy/certs/server.crt
        ssl_server_key /etc/3proxy/certs/server.key
        ssl_server_ca_file /etc/3proxy/certs/ca.crt
        ssl_server_verify
        ssl_serv
        proxy -p3129

    Только клиенты с действительным сертификатом, подписанным CA, смогут подключиться.

    MITM для инспекции TLS-трафика:
    Для перехвата и расшифровки TLS-трафика требуется CA-сертификат для генерации подделанных серверных сертификатов:

        ssl_server_ca_file /etc/3proxy/certs/ca.crt
        ssl_server_ca_key /etc/3proxy/certs/ca.key
        ssl_client_verify
        ssl_client_ca_file /etc/ssl/certs/ca-certificates.crt
        ssl_mitm
        proxy -p3128
        ssl_nomitm
        proxy -p3129

    CA-сертификат должен быть доверенным для клиентов. ssl_client_verify обеспечивает проверку реальных серверных сертификатов. Без ssl_client_verify прокси уязвим для MITM-атак.

    TLS-клиент (соединение с вышестоящим сервером через TLS):
    Для соединения с вышестоящими серверами через TLS с аутентификацией по клиентскому сертификату:

        ssl_client_cert /etc/3proxy/certs/client.crt
        ssl_client_key /etc/3proxy/certs/client.key
        ssl_client_verify
        ssl_client_ca_file /etc/ssl/certs/ca-certificates.crt
        ssl_cli
        proxy -p3128

    Условное TLS для parent прокси (ssl_client_mode 3):
    При ssl_client_mode 3 TLS-рукопожатие с родительским прокси выполняется только если тип parent прокси заканчивается на 's' (защищённые типы). Это позволяет смешивать защищённые и незащищённые родительские прокси в одной конфигурации:

        ssl_server_cert /etc/3proxy/certs/server.crt
        ssl_server_key /etc/3proxy/certs/server.key
        ssl_client_mode 3

        auth strong
        allow user1
        parent 1000 https parent1.example.com 443
        allow user2
        parent 1000 socks5 parent2.example.com 1080
        ssl_serv
        ssl_cli
        proxy -p3128
        ssl_noserv
        ssl_nocli

    Создаётся HTTPS-прокси (ssl_serv), принимающий TLS-соединения от клиентов. Для соединений с родительским прокси трафик user1 идёт через https родитель с TLS-шифрованием (защищённый тип), а трафик user2 — через обычный socks5 родитель без TLS. Защищённые типы parent прокси: tcps, https, connects, connect+s, socks4s, socks5s, socks4+s, socks5+s, pop3s, smtps, ftps.

  - Как создать CA и сертификаты для SSL

    Создание удостоверяющего центра (CA):
    Для MITM или mTLS требуется CA. Сгенерируйте закрытый ключ CA и сертификат:

        # Генерация закрытого ключа CA
        openssl genrsa -out ca.key 4096

        # Генерация сертификата CA (действителен 10 лет)
        openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
            -subj "/C=RU/ST=Region/L=City/O=MyOrg/CN=My CA" \
            -out ca.crt

    Для MITM импортируйте ca.crt в браузеры/ОС клиентов как доверенный корневой CA.

    Создание серверного сертификата для https:// прокси:
    Серверный сертификат должен иметь правильные альтернативные имена (SAN):

        # Генерация закрытого ключа сервера
        openssl genrsa -out server.key 2048

        # Создание запроса на подпись сертификата (CSR)
        openssl req -new -key server.key \
            -subj "/C=RU/ST=Region/L=City/O=MyOrg/CN=proxy.example.com" \
            -out server.csr

        # Создание файла расширений для SAN
        cat > server.ext << 'EOF'
        authorityKeyIdentifier=keyid,issuer
        basicConstraints=CA:FALSE
        keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
        extendedKeyUsage = serverAuth
        subjectAltName = @alt_names

        [alt_names]
        DNS.1 = proxy.example.com
        DNS.2 = proxy
        IP.1 = 192.168.1.100
        EOF

        # Подписание сертификата CA
        openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
            -CAcreateserial -out server.crt -days 365 -sha256 \
            -extfile server.ext

    Для публичного https:// прокси используйте CA вроде Let's Encrypt вместо самоподписанного.

    Создание клиентского сертификата для mTLS:

        # Генерация закрытого ключа клиента
        openssl genrsa -out client1.key 2048

        # Создание CSR
        openssl req -new -key client1.key \
            -subj "/C=RU/ST=Region/L=City/O=MyOrg/CN=client1" \
            -out client1.csr

        # Создание файла расширений
        cat > client.ext << 'EOF'
        basicConstraints=CA:FALSE
        keyUsage = digitalSignature, nonRepudiation, keyEncipherment
        extendedKeyUsage = clientAuth
        EOF

        # Подписание CA
        openssl x509 -req -in client1.csr -CA ca.crt -CAkey ca.key \
            -CAcreateserial -out client1.crt -days 365 -sha256 \
            -extfile client.ext

        # Создание PKCS#12 для импорта в браузер
        openssl pkcs12 -export -out client1.p12 \
            -inkey client1.key -in client1.crt -certfile ca.crt

    Импортируйте client1.p12 в хранилище сертификатов браузера или ОС клиента.

    Скрипт быстрой настройки для разработки/тестирования:

        #!/bin/sh
        # Создаёт CA, серверный и клиентский сертификаты для тестирования SSLPlugin

        # CA
        openssl genrsa -out ca.key 4096
        openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
            -subj "/CN=3proxy CA" -out ca.crt

        # Сервер
        openssl genrsa -out server.key 2048
        openssl req -new -key server.key -subj "/CN=localhost" -out server.csr
        cat > server.ext << 'EOF'
        basicConstraints=CA:FALSE
        keyUsage = keyEncipherment
        extendedKeyUsage = serverAuth
        subjectAltName = DNS:localhost,DNS:proxy,IP:127.0.0.1
        EOF
        openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
            -CAcreateserial -out server.crt -days 365 -sha256 -extfile server.ext

        # Клиент
        openssl genrsa -out client.key 2048
        openssl req -new -key client.key -subj "/CN=client" -out client.csr
        cat > client.ext << 'EOF'
        basicConstraints=CA:FALSE
        extendedKeyUsage = clientAuth
        EOF
        openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
            -CAcreateserial -out client.crt -days 365 -sha256 -extfile client.ext
        openssl pkcs12 -export -out client.p12 -passout pass: \
            -inkey client.key -in client.crt -certfile ca.crt

  - Как использовать PCRE-фильтрацию (регулярные выражения)

    Начиная с версии 0.9.7 фильтрация PCRE встроена в 3proxy при компиляции с поддержкой PCRE2 (WITH_PCRE). Ранее доступная как PCREPlugin, функциональность теперь интегрирована в основной бинарный файл. Строка plugin больше не нужна.

    PCRE-фильтрация может использоваться для создания правил поиска и замены с регулярными выражениями для запросов клиентов, заголовков клиента и сервера, а также данных.

    Команды:

        pcre TYPE FILTER_ACTION REGEXP [ACE]
        pcre_rewrite TYPE FILTER_ACTION REGEXP REWRITE_EXPRESSION [ACE]
        pcre_extend FILTER_ACTION [ACE]
        pcre_options OPTION1 [...]

    - TYPE - тип фильтруемых данных (список через запятую):
      - request - содержимое запроса клиента (например, строка HTTP GET-запроса)
      - cliheader - содержимое заголовков запроса клиента
      - srvheader - содержимое заголовков ответа сервера
      - clidata - данные полученные от клиента (например, данные POST-запроса)
      - srvdata - данные полученные от сервера (например, HTML-страница)
    - FILTER_ACTION - действие при совпадении:
      - allow - разрешить запрос без проверки остальных правил
      - deny - запретить запрос без проверки остальных правил
      - dunno - продолжить проверку правил (полезно для pcre_rewrite)
    - REGEXP - регулярное выражение PCRE (Perl). Используйте * если проверка не требуется.
    - REWRITE_EXPRESSION - строка замены. Может содержать Perl-подстановки $1, $2 и т.д. $0 - вся найденная подстрока. \r и \n для вставки новых строк.
    - ACE - элемент списка контроля доступа (имена пользователей, IP источника, IP назначения, порты и т.д.), аналогичный командам allow/deny/bandlimin. Регулярное выражение проверяется только при совпадении ACL с данными соединения.

    Примеры:

        # Блокировать запросы с определёнными ключевыми словами для некоторых пользователей
        pcre request deny "porn|sex" user1,user2,user3 192.168.0.0/16

        # Блокировать ответы с определённым content-type
        pcre srvheader deny "Content-type: application"

        # Замена содержимого в обоих направлениях (цензура)
        pcre_rewrite clidata,srvdata dunno "porn|sex|pussy" "***" baduser
        pcre_extend deny * 192.168.0.1/16

    Примечание: Регулярные выражения не требуют авторизации и не могут заменить авторизацию и/или ACL allow/deny.

  - Как ограничить доступ к службе

    Во-первых, для ограничения доступа необходимо указать внутренний интерфейс, на котором прокси-сервер будет принимать соединения. Внутренний интерфейс указывается с помощью команды internal в файле конфигурации или с помощью ключа -i конкретного модуля. (см. Как запустить конкретную службу (HTTP, SOCKS и т.д)). Отсутствие указания внутреннего интерфейса может привести к тому, что ваш прокси будет открытым.

    Указание внешнего интерфейса (т.е. IP, с которого сервер будет устанавливать внешние соединения) так же является полезным. Для этого служит команда external и ключ -e соответственно. Для универсального прокси возможна дополнительная авторизация доступа с помощью имени/пароля, NetBIOS имени пользователя и по спискам доступа (по IP клиента, IP и порту назначения, см. Как ограничить доступ пользователей к ресурсам). Тип авторизации устанавливается командой auth в файле конфигурации.

          auth none

    Отсутствие какой-либо авторизации. Списки доступа не проверяются.

          auth iponly

    Будет идти проверка по списку доступа с использованием IP клиента, IP и номера порта назначения.

          auth nbname

    Перед проверкой по списком доступа будет произведена попытка получить NetBIOS имя клиента. Для этого используется NetBIOS код службы messager (0x03). Если имя определить не удалось (служба messager для Windows NT/2000/XP или WinPopUP для 95/98/ME не запущена), то имя будет считаться пустым. Далее следует проверка по спискам доступа. Данный тип авторизации не зависит от платформы сервера (т.е. прокси сервер, запущенный под Unix, сможет определять NetBIOS имена). Его рекомендуется использовать в однородных сетях, где у всех клиентов установлена Windows NT/2000/XP и пользователи не имеют доступа к привелегированным учетным записям. Этот вид авторизации не является надежным.

          auth strong

    Проверяется имя и пароль, переданные пользователем при подключении к прокси. Данный вид авторизации работает только с proxy и socks. Необходимо задание списка пользователей (см Как создать список пользователей). Соединения от неизвестных пользователей не принимаются. После проверки имени пользвоателя и пароля происходит проверка списков доступа.

    Для разных служб можно установить различные типы авторизации, например,

          auth none
          pop3p
          auth iponly
          proxy
          auth strong
          socks

    не накладывает ограничений на использование POP3 Proxy, производит проверку по спискам доступа для пользователей HTTP Proxy и требует авторизации с именем и паролем для SOCKS.

    С версии 0.6 возможно использвоать двойную авторизацию, например,

          auth iponly strong
          allow * * 192.168.0.0/16
          allow user1,user2
          proxy

    будет использовать авторизацию только в том случае, если не удалось пропустить пользователя с авторизаций iponly, т.е. для доступа к ресурсам 192.168.0.0/16 авторизация не требуется.

    С версии 0.6 так же можно использвоать кэширование авторизации (имени пользователя) с целью повышения производительности. Использовать кэширование для strong практически не имеет смысла, она полезно для nbname и авторизации через внешние плагины, типа WindowsAuthentication. Кэширование настраивается командой authcache с двумя параметрами - типом кэширования и временем, на которое кэшируется пароль. Возможные типы: ip - после успешной авторизации в течение времени кэширования все запросы пришедшие с того же адреса считаются запросами от того же пользователя, name - после успешной авторизации от пользователя с тем же именем требуют указания имени, но реально аутентификации не производится, ip,name - запрос должен придти от того же IP и с тем же именем. user,password - имя и пароль пользователя сверяются с кэшированными. Возможны и другие сочетания. Для авторизации должен использоваться специальный метод авторизации - cache. Пример:

          authcache ip 60
          auth cache strong windows
          proxy -n

    Кэширование влияет на безопасность доступа. Ни в коем случае не следует использовать кэширование для доступа к критичным ресурсам, в частности к интерфейсу администрирования.

    authcache так же может использоваться для привязки сессий пользователя к ip с с помощью опции limit

          autchcache ip,user,pass,limit 120
          auth cache strong

    запретит пользователю использовать более одного адреса в течении времени кеширования.
  - Как создать список пользователей

    Список пользователей задается с помощью команды users.

          users USERDESC ...

    С помощью одной команды можно задать несколько пользователей, можно давать несколько команд users. USERDESC - описание пользователя. Описание пользователя состоит из трех полей разделенных : (двоеточием) - имени (login) типа пароля и пароля. Например:

          users admin:CL:bigsecret test:CL:password test1:CL:password1
          users "test2:CR:$1$lFDGlder$pLRb4cU2D7GAT58YQvY49."
          users test3:NT:BD7DFBF29A93F93C63CB84790DA00E63

    Обратите внимание на двойные кавычки - они необходимы для второго пользователя, т.к. в его пароле встречается знак $, который для файла 3proxy.cfg означает включение другого файла. Поддеживается следующие типы паролей:
    - тип не указан - использовать системную авторизацию для данного пользователя (пока не реализовано).
    - CL - пароль в открытом тексте
    - CR - пароль в формате crypt() (только MD5)
    - NT - пароль в формате NT в шестнадцатеричной кодировке
    NT и crypt пароли могут быть использованы для импорта учетных записей из Windows/Samba и Unix соответственно (для Windows можно использовать утилиты семейства pwdump). Учетные записи удобно хранить в отдельном файле (в таком случае можно хранить их построчно в формате, типичном для файлов паролей). Включить файл можно с помощью макроса $:

          users $/etc/.3proxypasswd

    или

          users $"c:\Program Files\3proxy\passwords"

    Шифрованные NT и crypt пароли можно создавать с помощью утилиты 3proxy_crypt.
    Список пользователей един для всех служб. Разграничение доступа по службам необходимо производить с помощью списков доступа.
  - Как ограничить доступ пользователей к ресурсам

    Для построения списков доступа используются команды allow, deny и flush. Команды имеют следующую структуру:

          allow <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> <weekdays> <timeperiodslist>
          deny <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> <weekdays> <timeperiodslist>
          flush

    Команда flush используется для сброса существующего списка доступа (это необходимо для того, чтобы можно было задать различные списки доступа для различных служб). allow служит для разрешения соединения, deny - для запрета соединения. Команда parent используется в качестве расширения команды allow для управления перенаправлениями соединений (о перенаправлении см. Как управлять перенаправлениями). В момент установки исходящего соединения просматривается список доступа и находится первая запись, соответствующая запрошенному клиентом соединению. Если запись соттветствует allow - соединение разрешается, deny - запрещается. Если список пуст, то соединение разрешается. Если список не пуст, но подходящей записи нет, то соединение запрещается. При этом:
    - <userlist> - список логинов пользователей через запятую
    - <sourcelist> - список сетей клиентов через запятую. Сеть задается в формате xxx.yyy.zzz.mmm/l, где l - длина маски сети (количество ненулевых байт). Например, 192.168.1.0/24 соответствует сети с маской 255.255.255.0.
    - <targetlist> - список сетей назначения через запятую
    - <targetportlist> - список портов назначения через запятую. можно задать диапазон портов через -, например, 80,1024-65535
    - <commandlist> - список команд, через запятую, для которых применяется правило:
      CONNECT - установить исходящее TCP соединение (например, SOCKSv4/5, POP3 proxy, и т.д.)
      BIND - разрешить входящее TCP соединение (SOCKSv5)
      UDPASSOC - создать UDP-ассоциацию (SOCKSv5)
      ICMPASSOC - создать ICMP-ассоциацию (не реализовано)
      HTTP_GET - HTTP GET запрос (HTTP proxy)
      HTTP_PUT - HTTP PUT запрос (HTTP proxy)
      HTTP_POST - HTTP POST запрос (HTTP proxy)
      HTTP_HEAD - HTTP HEAD запрос (HTTP proxy)
      HTTP_CONNECT - HTTP CONNECT запрос (HTTP proxy)
      HTTP_OTHER - другой HTTP запрос (HTTP proxy)
      HTTP - соответствует любому HTTP запросу кроме HTTP_CONNECT (HTTP proxy)
      HTTPS - тоже, что HTTP_CONNECT (HTTP proxy)
      FTP_GET - FTP get запрос
      FTP_PUT - FTP put запрос
      FTP_LIST - FTP list запрос
      FTP - соответствует любому FTP запросу
      ADMIN - доступ к интерфейсу администрирования
    - <weekdays> задает список дней недели, 1 соответствует понедельнику, 0 или 7 - воскресенье. 1-5 означает с понедельника по пятницу (включительно). 1,3,5 задает нечетные дни недели.
    - <timeperiodslist> список интервалов дня в формате ЧЧ:ММ:СС-ЧЧ:ММ:СС, например, 00:00:00-08:00:00,17:00:00-24:00:00 задает нерабочее время.
    Примеры использования листов доступа можно найти в файле 3proxy.cfg.sample.
  - Как управлять перенаправлениями

    Перенаправления имеет смысл использовать, например, чтобы перенаправить обращения определенных клиентов или на определнные сервера на другой сервер (например, при попытке доступа на Web сервер с недозволенным материалом перенаправить на собственный Web сервер, или для того, чтобы в зависимости от IP клиента перенаправлять его соединения на разные сервера (особенно при отображении портов через tcppm). Кроме того, перенаправление может быть использовано, например, для перенаправления все исходящих HTTP запросов, посланных через SOCKS, на HTTP прокси. Поскольку формат запроса к Web серверу и Proxy различается, не любой Proxy сервер способен корректно обработать перенаправленный запрос (HTTP proxy в комплекте 3proxy нормально обрабатывает перенаправленные запросы, что делает возможным его использования в качестве "прозрачного" прокси. Кроме того, HTTP прокси обнаруживает перенаправления на родительский прокси и генерирует нормальные заголовки. Пример простейшего перенаправления:

          auth iponly
          allow *
          parent 1000 http 192.168.1.1 3128
          proxy

    перенаправляет весь трафик службы proxy на родительский HTTP-прокси сервер 192.168.1.1 порт 3128.
    Если в качестве номера порта указан порт 0, то указанный IP адрес используется в качестве внешнего адреса для установки соединения (аналог -eIP, но только для запросов попадающих под allow).
    Специальным случаем перенаправлений являются локальные перенаправления, которые, как правило, используются совместно со службой socks. В локальных перенаправлениях IP адрес 0.0.0.0 порт 0. Например,

          auth iponly
          allow * * * 80
          parent 1000 http 0.0.0.0 0
          allow * * * 21
          parent 1000 ftp 0.0.0.0 0
          allow * * * 110
          parent 1000 pop3 0.0.0.0 0
          socks

    перенаправляет все содеинения, проходящие через SOCKS-сервер по 80 порту, в локальный HTTP прокси, 21-му - в FTP, и 110 - в POP3 прокси. При этом службы proxy, ftppr или pop3pr запускать не требуется. Это может быть полезно для того, чтобы видеть в логах записи о посещаемых пользвоателем ресурсах и загружаемых файлах даже в том случае, если он подключается через SOCKS.
  - Как управлять локальными перенаправлениями

    - Q: Для чего это надо?

    A: Чтобы иметь в логах URL запросов, если пользователь SOCKS пользуется Web, FTP или POP3.

    - Q: Какие недостатки?

    A: Перенапраление невозможно для web-серверов или FTP, висящих на нестандартных портах, для SOCKSv4 не поддрживается авторизация с паролем (IE поддерживает только SOCKSv4), но при этом IE передает имя пользователя по SOCKSv4 (имя, с которым пользователь вошел в систему). Для SOCKSv5 не поддерживается NTLM авторизация, пароли передаются в открытом тексте.

    - Q: Какие преимущества?

    A: Достаточно в настройках IE только указать адрес SOCKS прокси. В больших сетях можно для этого использовать WPAD (автоматическое обнаружение прокси). В 3proxy достаточно запускать только одну службу (socks). Если используется только Internet Explorer, то можно автоматически получать имя пользователя в логах, не запрашивая логин/пароль.

    - Q: Как настраивается?

    A: Указывается parent http proxy со специальным адресом 0.0.0.0 и портом 0. Пример:

          allow * * * 80,8080-8088
          parent 1000 http 0.0.0.0 0
          allow * * * 80,8080-8088
          #перенаправить соединения по портам 80 и 8080-8088 в локальный
          #http прокси. Вторая команда allow необходима, т.к. контроль доступа
          #осуществляется 2 раза - на уровне socks и на уровне HTTP прокси
          allow * * * 21,2121
          parent 1000 ftp 0.0.0.0 0
          allow * * * 21,2121
          #перенаправить соединения по портам 21 и 2121 в локальный
          #ftp прокси
          allow *
          #пустить все соединения напрямую
          socks

    - Q: Как взаимодействует с другими правилами в ACL?

    A: После внутреннего перенаправления правила рассматриваются еще раз за исключением самого правила с перенаправлением (т.е. обработка правил не прекращается). Это позволяет сделать дальнейшие перенаправления на внешний прокси. По этой же причине локальное перенаправление не должно быть последним правилом (т.е. должно быть еще хотя бы правило allow, чтобы разрешить внешние соединения через HTTP прокси). Например,

          allow * * * 80,8080-8088
          parent 1000 http 0.0.0.0 0
          #перенаправить во внутренний прокси
          allow * * $c:\3proxy\local.nets 80,8080-8088
          #разрешить прямой web-доступ к сетям из local.nets
          allow * * * 80,8080-8088
          parent 1000 http proxy.3proxy.ru 3128
          #все остальные веб-запросы перенаправить на внешний прокси-сервер
          allow *
          #разрешить socks-запросы по другим портам

  - Как организовать балансировку между несоклькими каналами

    Сам по себе прокси не может управлять маршрутизацией пакетов сетевого уровня. Единственная возможность для управления внешними соединениями - это выбор внешнего интерфейса. Сделать выбор внешнего интерфейса случайным начиная с версии 0.6 можно с использованием локальных перенаправлений (с номером порта равным нулю):

          auth iponly
          allow *
          parent 500 http 10.1.1.101 0
          parent 500 http 10.2.1.102 0

    будет использовать внешний интерфейс 10.1.1.1 или 10.2.1.1 с вероятностью 0.5. Внешний интерфейс это то же, что задается командой external или опцией -e. Чтобы это работало как ожидается, необходимо, чтобы локальным интерфейсам 10.1.1.1 и 10.2.1.1 соответствовали разные маршруты по-умолчанию.

    Если оба адреса принадлежат одной сети, например, 10.1.1.101 и 10.1.1.102 и нужно случайным образом выбирать один из шлюзов 10.1.1.1 и 10.1.1.2, то нужно управлять роутингом примерно так (при условии что маршрут по-умолчанию не задан):

          route add -p 10.1.1.1 10.1.1.101
          route add -p 10.1.1.2 10.1.1.102
          route add -p 0.0.0.0 mask 0.0.0.0 192.168.1.1
          route add -p 0.0.0.0 mask 0.0.0.0 192.168.1.2

    Если второго адреса на прокси сервере нет - его надо добавить. Под Linux/Unix лучше использовать source routing.
  - Как составлять цепочки прокси

    Для составления цепочек прокси так же можно использовать команду parent, которая является расширением команды allow (т.е. команде parent должна предшествовать команда allow). С помощью этой команды можно строить цепочки из HTTPS (HTTP CONNECT), SOCKS4 и SOCKS5 прокси (т.е. последовательно подключаться через несколько прокси), при этом возможна авторизация на родительском прокси, звено цепочки может выбираться случайным образом из несольких значений с вероятностью согласно их весу. Вес (от 1 до 1000) задается для каждого прокси. Сумма весов по всем перенаправлениям должна быть кратна 1000. Прокси с весами до 1000 группируются, и при построении цепочки один из них выбирается случайно согласно весу. Длина цепочки определяется из суммарного веса. Например, если суммарный вес цепочки 3000, в цепочке будет 3 звена (хопа). Синтаксис команды:

          parent <weight> <type> <ip> <port> <username> <password>

    weight - вес прокси, type - тип прокси (tcp - перенаправление соединения, может быть только последним в цепочке, http - синоним tcp, connect - HTTP CONNECT/HTTPS прокси, socks4 - SOCKSv4 прокси, socks5 - SOCKSv5 прокси), ip - IP адрес прокси, port - порт прокси, username - имя для авторизации на прокси (опционально), password - пароль для авторизации на прокси (опционально).
    Пример:

          allow *
          parent 500 socks5 192.168.1.1 1080
          parent 500 connect 192.168.10.1 3128

    Создает цепочку из одного звена (суммарный вес 1000), в котором один из двух прокси выбирается случайно с равной вероятностью (веса равны). В цепочку перенаправляются все исходящие соединения (определяется командой allow).

          allow * * * 80
          parent 1000 socks5 192.168.10.1 1080
          parent 1000 connect 192.168.20.1 3128
          parent 300 socks4 192.168.30.1 1080
          parent 700 socks5 192.168.40.1 1080

    Создает цепочку из трех звеньев (суммарный вес 3000). Первое звено - 192.168.10.1, второе - 192.168.20.1, а третье - либо 192.168.30.1 с вероятностью 0.3 либо 192.168.40.1 с вероятностью 0.7
  - Как применять ACL к UDP трафику

    Запрос SOCKSv5 UDP ASSOCIATE лишь просит 3proxy открыть порт для ретрансляции и не содержит адреса назначения. Адрес назначения берется из каждой датаграммы, отправленной клиентом, поэтому одна ассоциация может обращаться к любому числу адресов назначения. 3proxy авторизует адрес назначения каждой датаграммы, поэтому ACL, ограничивающие адрес, имя хоста или порт назначения, применяются и к UDP трафику.

    Отличия от TCP:

    - Датаграмма к запрещенному адресу назначения отбрасывается, ассоциация при этом не завершается.
    - Вышестоящий прокси и внешний адрес выбираются для адреса назначения датаграммы, а не для запроса ASSOCIATE, и устанавливаются заново, если последующий адрес назначения соответствует другой записи ACL. Для UDP могут использоваться только родители типа `socks5` и `socks5+`.
    - ACL проверяются только для датаграмм, отправленных клиентом. Датаграмма, полученная в рамках ассоциации, передается клиенту без проверки ACL: при использовании вышестоящего прокси принимаются только датаграммы от него, а ассоциация без вышестоящего прокси принимает датаграмму от любого источника. Клиенту сообщается фактический адрес источника датаграммы. В журнал записывается адрес назначения, на который клиент отправлял датаграммы, а не адрес источника полученных датаграмм.
    - Клиент может использовать одну ассоциацию для обращения ко многим адресам назначения. Запись ACL, ограничивающая адрес назначения, молча отбрасывает датаграммы ко всем остальным адресам назначения, поэтому ограничение адреса назначения для UDP может нарушить работу таких клиентов, и причину трудно установить. Ограничивайте его, только если это действительно необходимо.
    - Ограничители полосы и счетчики трафика, ограничивающие адрес назначения, выбираются при авторизации адреса назначения, поэтому они выбираются для адреса назначения первой датаграммы и не выбираются заново для каждого последующего адреса назначения. К входящему UDP трафику они не могут быть применены по адресу назначения вообще.
    - Каждое изменение имени хоста, адреса или порта назначения авторизуется заново и записывается в журнал. Используйте `nscache` для имен хостов и кэш аутентификации для всего, что дороже 'iponly'. Опция `-U` сервиса `socks` отключает журналирование и/или повторную авторизацию; при `-U0` или `-U1` авторизуется только первый адрес назначения ассоциации.

    Ограничить адреса назначения, куда клиент может отправлять датаграммы:

        auth iponly
        allow * * 8.8.8.8 53
        deny *
        socks -p1080

    Запрос ASSOCIATE выполняется успешно, датаграммы к 8.8.8.8:53 передаются, датаграммы к любому другому адресу назначения отбрасываются.

    То же самое с аутентификацией 'strong' (или RADIUS, или через плагин), при которой иначе каждый новый адрес назначения аутентифицировался бы заново:

        users user1:CL:password
        authcache user,pass,dstaddr,dstport 60
        auth cacheacl strong
        allow user1 * 8.8.8.8 53
        deny *
        socks -p1080

    При 'cacheacl' результат проверки ACL не вычисляется заново при попадании в кэш, поэтому каждое поле, ограничиваемое в ACL, должно входить в ключ кэша: 'user' и 'pass' для списка пользователей, 'dstaddr' и 'dstport' для списка адресов и списка портов назначения, 'ip' для списка источников, 'dsthost' для имен хостов в списке назначения, 'dstoper' для списка операций. Без адреса назначения в ключе результат, закэшированный для одного адреса назначения, применяется к любому другому, и адрес назначения не проверяется вообще. Используйте 'cache' вместо 'cacheacl', если ACL могут изменяться в течение времени жизни кэша или если используется вышестоящий прокси: при попадании в кэш 'cacheacl' обход ACL не выполняется, поэтому вышестоящий прокси не выбирается и датаграммы отправляются напрямую.

  - Как ограничивать скорости приема

    3proxy позволяет устанавливать фильтры ширины потребляемого канала. Для этого служат команды bandlimin/bandlimout и nobandlimin/nobandlimout (in в команде означает, что правило применяется к входящему трафику, out - к исходящему).

          bandlimin <bitrate> <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>
          nobandlimin <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>

    bitrate указывает ширину потока в битах в секунду (именно в битах). В остальном команды аналогичны командам allow/deny с тем отличием, что команды bandlim не имеют привязки к конкретному сервису, такому как HTTP прокси или SOCKS и действуют на все сервисы, трафик по всем соединениям, попавшим под действие правила суммируется независимо от того, через какой сервис это соединение установлено.

          bandlimin 57600 * 192.168.10.16
          bandlimin 57600 * 192.168.10.17
          bandlimin 57600 * 192.168.10.18
          bandlimin 57600 * 192.168.10.19

    устанавалиет канал 57600 для каждого из четырех клиентов,

          bandlimin 57600 * 192.168.10.16/30

    устанавалиает суммарный канал 57600 на 4-х клиентов. Если необходимо, чтобы на какой-то сервис не было ограничения ширины канала, следует указать nobandlim для этого сервиса, например:

          nobandlimin * * * 110
          bandlimin 57600 * 192.168.10.16/32

    разрешает клиентам неограниченный по скорости доступ по протоколу POP3.
  - Как ограничивать объем принимаемого трафика

          counter <filename> <type> <reportpath>
          countin <number> <type> <amount> <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>
          nocountin <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>

    countout <number> <type> <amount> <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> nocountout <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist>

    Команды позволяют установить лимит трафика на день, неделю или месяц. Сведения о трафике постоянно сохраняются в двоичном файле, указываемом командой counter, что делает подсчет трафика независимым от перезагрузки прокси. Можно управлять двоичным файлом, используя утилиту countersutil. Действие команд countin/nocountin аналогично действию bandlimin/nobandlimin, number - задает последовательный номер счетчика, номер должен быть уникальным положительным числом. Значение 0 указывает, что сведения для данного счетчика не надо сохранять в файле.
    reportpath - путь, по которому будут создаваться текстовые отчеты по потребленному трафику.
    type - тип ограничения или частота создания файлов отчета. D (На день), W (на неделю) или M (на месяц).
    amount - объем трафика на указанный период в мегабайтах.

  - Как пофиксить некорректный подсчет трафика

    Следует учитывать, что 3proxy считает трафик только на прикладном уровне и только проходящий через прокси-сервер. Провайдеры и другие средства учета трафика считают трафик на сетевом уровне, что уже дает расхождение порядка 10% за счет информации из заголовков пакетов. Кроме того, часть трафика, как минимум DNS-разрешения, различный флудовый трафик и т.д. идут мимо прокси. Уровень "шумового" трафика в Internet сейчас составляет порядка 50KB/день на каждый реальный IP адрес, но может сильно варьироваться в зависимости от сети, наличия открытых портов, реакции на ping-запросы и текущего уровня вирусной активности. По этим причинам, если 3proxy используется чтобы не "выжрать" трафик, выделенный провайдером, всегда следует делать некий запас порядка 15%.

    Если на одной с 3proxy машине имеются какие-либо сервисы или работает пользователь, то их трафик не проходит через proxy-сервер и так же не будет учтен. Если где-то есть NAT, то клиенты, выходящие через NAT мимо прокси, так же останутся неучтенными. Если расхождение с провайдером превышает 10% - нужно искать причину именно в этом.

  - Как управлять разрешением имен и кэшированием DNS

    Для разрешения имен и кэширования применяются команды nserver, nscache и nsrecord.

          nserver 192.168.1.2
          nserver 192.168.1.3:5353/tcp

    указывает 3proxy какие машины следует использвоать в качестве серверов DNS. Сервер 192.168.1.3 будет использоваться по порту TCP/5353 (вместо дефолтного UDP/53) только при недостижимости 192.168.1.2. Можно указать до 5 серверов. Если nserver не указан, будут использованы системные функции разрешения имен.

          nscache 65535
          nscache6 65535

    указывает размер кэша для разрешения имен (обычно достаточно большой) для IPv4 и IPv6 соответственно. Кэш исопльзуется только при явном указании nserver.

          nsrecord server.mycompany.example.com 192.168.1.1
          nsrecord www.porno.com 127.0.0.2
          ...
          deny * * 127.0.0.2

    добавляет статическую запись в кэш. Статические записи так же влияют на разрешение через dnspr если не указана опция -s. Начиная с версии 0.8 для dnspr могут быть сконфигурированы родительские прокси.
  - Как использовать IPv6

    IPv6 поддерживается с версии 0.8. Обратите внимание, что в некоторых видах прокси (например SOCKSv4) IPv6 не поддерживает на уровне протокола. В SOCKSv5 есть поддержка IPv6 с помощью отдельного вида запроса, который должен быть реализован в клиентском приложении или соксификаторе.
    Возможно проксирование из сетей IPv4 и IPv6 в сети IPv4, IPv6 и смешанные. Адреса IPv6 могут использоваться в командах internal, external, parent, ACL, опциях -i, -e и т.д. Команду external и опцию -e для каждого сервиса можно давать два раза - один раз с IPv4 и один раз с IPv6 адресом. internal и -i может быть указан только один, для биндинга ко всем адресам IPv4 и IPv6 можно использовать адрес [0:0:0:0:0:0:0:0] or [::].
    Кроме того, для каждого сервиса могут быть даны опции -4, -46, -64, -6 которые задают приоритет разрешения имен в адреса IPv4 и IPv6 (только IPv4, приоритет IPv4, приоритет IPv6, только IPv6).

  - Как использовать connect back

    Например, пользователю нужен доступ к прокси-серверу, который расположен на хосте 192.168.1.2 недоступном из внешней сети, но имеющем доступ во внешнюю сеть с внешним адрес 1.1.1.1. Так же у него есть машина с именем host.dyndns.example.org с внешним адресом 2.2.2.2. Пользователь запускает 2 экземпляра 3proxy, один на хосте 192.168.1.2 с конфигурацией

          users user:CL:password
          auth strong
          allow user
          proxy -rhost.dyndns.example.org:1234

    второй на хосте host.dyndns.example.org (2.2.2.2) с конфигурацией

          auth iponly
          allow * * 1.1.1.1
          tcppm -R0.0.0.0:1234 3128 1.1.1.1 3128

    В настройках браузера указывается host.dyndns.example.org:3128.
  - Как использовать протокол HAProxy PROXY

    3proxy поддерживает протокол HAProxy PROXY v1 как для приёма, так и для отправки информации об IP-адресе клиента. Это полезно, когда 3proxy находится за балансировщиком нагрузки или при передаче информации о клиенте родительскому прокси.

    Приём заголовка PROXY протокола:
    Используйте опцию `-H`, чтобы 3proxy ожидал заголовок PROXY протокола v1 на входящих соединениях. Это позволяет 3proxy получать реальный IP-адрес клиента от HAProxy или другого балансировщика нагрузки:

        proxy -H -p3128
        socks -H -p1080

    Заголовок PROXY протокола должен быть отправлен до любых протокольных данных.

    Отправка заголовка PROXY протокола родительскому прокси:
    Используйте тип родительского прокси `ha` для отправки заголовка PROXY протокола v1 родительскому прокси. Укажите `ha` перед родителем, который должен получить заголовок; после отправки заголовка продолжается хендшейк протокола родителя:

        allow *
        parent 1000 ha 0.0.0.0 0
        parent 1000 socks5 parent.example.com 1080
        proxy

    Эта конфигурация подключается к SOCKS5 родителю, отправляет PROXY заголовок с исходным IP клиента, затем выполняет SOCKS5-хендшейк и только после этого передаёт полезную нагрузку. Родитель должен использовать `-H` (например `socks -H`).

  - Как установить максимальный размер сегмента TCP (MSS)

    Используйте команду `maxseg` для установки максимального размера сегмента TCP (MSS) для исходящих соединений. Это может быть полезно для обхода проблем с Path MTU Discovery или для оптимизации трафика в специфических сетевых условиях:

        maxseg 1400
        proxy -p3128 -OcTCP_NODELAY,TCP_MAXSEG -OsTCP_NODELAY,TCP_MAXSEG

    Значение указывается в байтах. Эта настройка использует опцию сокета TCP_MAXSEG и может не поддерживаться на всех платформах. Типичный случай использования - уменьшение MSS для избежания фрагментации в VPN туннелях или для обхода проблем с MTU на определённых сетевых путях.

- Конфигурация клиентов

  - Как использовать 3proxy с Internet Explorer или другим браузером

    Мы будем рассматривать Interenet Explorer, т.к. у него больше особенностей настройки, с другими браузерами должно возникать меньше вопросов.

    Есть два основных способа работы с 3proxy - использовать HTTP прокси (сервис proxy) или SOCKS прокси (сервис socks). Обычно используется HTTP прокси. Для SOCKS прокси можно использовать встроенную поддержку браузера или программу-соксификатор (см. Как использовать 3proxy с программой, не поддерживающей работу с прокси-сервером), если встроенная поддержка SOCKS чем-то не устраивает или так удобнее. Не все соксификаторы поддерживают входящие соединения, поэтому чтобы не было проблем с протоколом FTP лучше использовать пассивный режим (в Internet Explorer 5.5SP2 и выше "Использовать пассивный FTP-протокол").

    Для конфигурации HTTP прокси необходимо указать внутренний адрес и порт, установленые для службы proxy в конфигурации 3proxy (либо как "Один прокси-сервер для всех протоколов" либо для HTTP, Secure, FTP). Поддержка Gopher в 3proxy в настоящий момент не реализована, но этот устаревший протокол в Internet практически не используется. Для нормальной работы FTP через HTTP прокси необходимо отключить представление для папок FTP (FTP folder view), он включен по-умолчанию, т.к. иначе FTP будет работать без использвания HTTP прокси. HTTP прокси использует пассивный режим для протокола FTP. В настройках 3proxy рекомендуется разрешть метод HTTP_CONNECT только для порта назначения 443. Если метод HTTP_CONNECT не разрешен, то не будет работать протокол HTTPS, если он разрешен для всех портов, то можно обойти журналирование запросов для протокола HTTP). Для работы с HTTP прокси может использоваться авторизация по паролю (strong).

    Для использования SOCKS необходимо настроить только SOCKS прокси (иначе для протоколов, для которых указан прокси сервер, он будет использоваться как HTTP прокси). Internet Explorer (включая IE 6.0SP1) поддерживает только SOCKSv4. В качестве имени пользователя передается имя пользователя, использованное для входа в систему. Передача пароля в SOCKSv4 не поддерживается, поэтому авторизация по паролю (strong) не доступна. Можно использовать имя пользователя, переданное браузером в ACL для iponly-авторизации, но при этом необходимо иметь ввиду ненадежность такого способа. При работе через SOCKS Internet Explorer (и большая часть других браузеров) используют пассивный режим работы для FTP. При использовании SOCKS можно получить в журнале (логах) URL запрашиваемых страниц, для этого необходимо создать внутреннее перенаправление в HTTP прокси для порта 80 (и других портов, используемых для HTTP) в локальный HTTP прокси (proxy), порт 21 (и другие порты, используемые FTP) в FTP прокси. При перенаправлении соединений в FTP прокси, нужно иметь ввиду, что FTP создает вторичные соединения для передачи данных. Для этого, во-первых, необходимо разрешить доступ к внутреннему интерфейсу прокси сервера через SOCKS (что не очень безопасно), во-вторых, принять меры, чтобы в SOCKS такие соединения на внутренний интерфейс не тарифицировались (т.к. иначе они будут тарифицироваться дважды - SOCKS и FTP прокси).

    Internet Explorer и другие продвинутые браузеры поддерживают автоматическую конфигурацию прокси-сервера в полностью автоматическом или полуавтоматическом режимах. Автоматическая конфигурация позволяет задать достаточно сложные правила, позволяющие клиентам использовать (или не использвоать) разные прокси-серверы для доступа к разным ресурсам. Эта возможность разбирается в статьях
    Microsoft: Q296591 A Description of the Automatic Discovery Feature
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;296591
    Netscape: Navigator Proxy Auto-Config File Format
    http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

  - Как настраивать FTP клиент

    Настройка FTP клиента для работы через SOCKS прокси не отличается от настройки браузера.

    Для работы с FTP клиентом через FTP прокси (ftppr) есть несколько возможностей. Допустим, нам необходимо подключиться ко внешнему FTP серверу со следующими параметрами:

          Адрес:  ftp.security.nnov.ru
          Username: ftpuser
          Password: ********

    Работа с клиентом, не поддерживающим FTP прокси - в качестве адреса FTP сервера указывается адрес прокси (например, proxy.security.nnov.ru), в качестве имени пользователя ftpuser@ftp.security.nnov.ru. Если для доступа к службе ftppr требуется авторизация по имени и паролю с именем pruser и паролем prpass, то в качестве имени пользователя необходимо указать pruser:prpass:ftpuser@ftp.security.nnov.ru. Если FTP клиент требует указания полной URL для подключения к серверу, то она должна выглядеть как

    pruser:prpass:ftpuser@ftp.security.nnov.ru:********@proxy.security.nnov.ru

    Не все клиенты обработают это корректно, но в большинстве случаев этого не требуется.

    Работа с клиентом, поддерживающим FTP прокси - если 3proxy не требует авторизации по паролю, то настройки стандартны для клиента. Если требуется доступ по паролю, то в качестве имени пользователя указывается pruser:prpass:ftpuser.

  - Как использовать SMTP через 3proxy

    В большинстве случаев достаточно установить отображение (tcppm) TCP порта 25 на аналогичный порт SMTP сервера провайдера. В конфигурации клиента указать внутренний адрес прокси в качестве адреса SMTP-сервера.

  - Как использовать POP3 proxy

    Предположим, у вас есть следующие настройки для получения почты:

          POP3 server: pop3.security.nnov.ru
          Login:  user
          Password: ********

    В настройках почтовой программы следует указать:

          POP3 server: (адрес прокси-сервера)
          Login:  user@pop3.security.nnov.ru
          Password: ********

    Имя пользователя может само по себе содержать знак '@'. Если в примере выше имя пользователя user@security.nnov.ru, то имя пользвоателя для доступа к прокси-серверу должно быть user@security.nnov.ru@pop3.security.nnov.ru. Если pop3pr требует авторизации по имени/паролю (например, pruser и prpass), то их необходимо указать в начале имени пользователя, отделив знаком ':', т.е для самого тяжелого случая pruser:prpass:user@security.nnov.ru@pop3.security.nnov.ru

  - Как использовать 3proxy с программой, не поддерживающей работу с прокси-сервером

    Можно использовать любую программу-редиректор. 3proxy поддерживает исходящие и обратные TCP и UDP соединения, но редиректоры могут иметь свои ограничения, кроме того, некоторые плохо написаные приложения не поддаются "соксификации". Если программе требуется обращаться к небольшому набору серверов (например, игровых), то проблему можно решить с помощью портмаппинга.

  - Как использовать 3proxy с играми

    Если по каким-то причинам соксификатор не работает или недоступен, то необходимо использовать отображения портов (обычно игры, кроме mood-подобных, работают по протоколу UDP, надо использовать udppm). Нужно иметь ввиду, что для udppm требуется отдельный маппинг для каждого серверного порта и каждого клиента. Например, если есть один сервер с портами 2115 и 2116 и три клиента, то нужно создать 6 разных маппингов, например

         udppm 12115 server 2115
         udppm 12115 server 2115
         udppm 22115 server 2115
         udppm 32115 server 2115
         udppm 12116 server 2116
         udppm 22116 server 2116
         udppm 32116 server 2116

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

- Администрирование и анализ информации

  - Где взять свежую версию

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

  - Как управлять службой 3proxy в Windows NT/2000/XP

    При установке 3proxy в качестве системной службы сервером поддерживаются команды запуска, остановки, временной приостановки и продолжения. При временной приостановке сервер перестает принимать новые запросы от клиентов, но обработка ранее поступивших запросов продолжается. Сервер не подерживает динамическое изменение конфигурации, т.е. после изменения конфигурации 3proxy необходимо перезапустить. Управлять запуском, остановкой, приостановкой и продолжением можно либо через служебную программу "Службы" (Services) либо через команду net:

          net start 3proxy
          net stop 3proxy
          net pause 3proxy
          net continue 3proxy

  - Коды ошибок в журнале

    - 0 - операция завершена успешно (в случае установленного соединения - соединение закрыто корректно одной из сторон).
    - 1-9 - ошибки авторизации
    - 1 - доступ закрыт ACL (deny)
    - 2 - перенаправление (не должно быть в журнале)
    - 3 - нет записи ACL для данного соединения
    - 4 - не определено имя пользователя для auth strong
    - 5 - не найдено имя пользователя для auth strong
    - 6 - неверный пароль (открытый текст)
    - 7 - неверный пароль (crypt)
    - 8 - неверный пароль (NT)
    - 9 - недостаточно данных для перенаправления (не должно быть в журнале)
    - 10 - превышен лимит трафика
    - 11-19 - ошибки соединения
    - 11 - невозможно создать сокет socket()
    - 12 - невозможно выбрать интерфейс bind()
    - 13 - сбой подключения connect()
    - 14 - сбой getpeername()
    - 20-29 - общие ошибки
    - 21 - ошибка выделения памяти
    - 30-39 - ошибки перенаправления CONNECT
    - 31 - невозможно послать запрос к CONNECT прокси
    - 32 - превышено ожидание или некорректный ответ CONNECT прокси
    - 33 - CONNECT прокси не может установить соединение
    - 34 - превышено ожидание или обрыв соединения при согласовании CONNECT соединения
    - 40-49 - ошибки перенаправления SOCKS4
    - 50-69 - ошибки перенаправления SOCKS5
    - 70-79 ошибки установки родительского соединения, аналогичны 1x
    - 90-99 - ошибки разрыва соединения
    - с версии 0.9
    - 90 - неожиданная системная ошибка (не должно происходить)
    - 91 - ошибка poll (не должно происходить)
    - 92 - соединение прервано по таймауту на сетевую операцию (см. timeouts)
    - 93 - соединение прервано по таймауту связанному с рейтлимитом или из-за превышения числа ошибок
    - 94 - клиент или сервер закрыли соединение или произошла сетевая ошибка, остались неотправленные данные
    - 95 - клиент "грязно" закрыл соединение или сетевая ошибка
    - 96 - сервер "грязно" закрыл соединение или сетевая ошибка
    - 97 - клиент и сервер "грязно" закрыли соединение или сетевая ошибка
    - 98 - исчерпан лимит данных сервера (не должно быть в журнале)
    - 99 - исчерпан лимит данных клиента (не должно быть в журнале)
    - до версии 0.9
    - 90 - ошибка сокета или соединение неожиданно прервано
    - 91 - общий сбой стека TCP/IP
    - 92 - соединение прервано по таймауту
    - 93 - ошибка получения данных от сервера
    - 94 - ошибка получения данных от клиента
    - 95 - таймаут из-за ограничения bandlimin/bandlimout
    - 96 - ошибка отправки данных клиенту
    - 97 - ошибка отправки данных серверу
    - 98 - исчерпан лимит данных сервера (не должно быть в журнале)
    - 99 - исчерпан лимит данных клиента (не должно быть в журнале)
    - 100 - не найден IP адрес по запросу клиента
    - 200-299 - ошибки UDP portmapper
    - 300-399 - ошибки TCP portmapper
    - 400-499 - ошибки SOCKS proxy
    - 500-599 - ошибки HTTP proxy
    - 600-699 - ошибки POP3 proxy
    - 999 - функция не реализована

- Как задать вопрос, которого нет в HowTo

  Задайте его на Github. Только не пытайтесь задавать какие-либо вопросы, если вы просто не поняли этот HowTo.