Что значит скрипт прокси сервера скачивается. Настройка прозрачной работы. Что он умеет

В общем, я таки решился его выкатить. Инструмент очень мощный как я считаю, разрабатывался и шлифовался около года.

Что он умеет?

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

• Он умеет поднимать прокси на centos (6,7), debian и ubuntu (любых версий). То есть на любой из популярных ОС на хостингах он может поднять прокси. Но при наличии выбора рекомендуется Centos 7.
• Он читает на вход только лишь список IP-адресов. Рядом с ним должен быть файл ip.list со списком адресов. Скрипт разбирает этот список, определяет настроены ли адреса на сетевом интерфейсе и предлагает настроить те адреса, что есть в списке, но недоступны (не «подняты», т.е. не сконфигурированы в самой OS). Если вы соглашаетесь на эти настройки, то всё поднимается и прописывается в автозагрузку.
• Скрипт разбирает IPv6 и IPv4 в списке. И конфигурит все соответствующим образом.
• Он умеет поднимать SOCKS и HTTP прокси. По-умолчанию только http, о соксах он спрашивает, и можно согласиться на их поднятие.
• Скрипт генерирует для каждого прокси отдельную пару — логин-пароль. Логины вида user1, user2, .., userN. Пароли рандомные, из 8 символов.
• Все прокси он поднимает на разных портах, которые берутся из заранее определенного диапазона портов. Для socks можно указать диапазон.
• Скрипт загружает и компилирует из исходников актуальную версию 3proxy. Вся настройка именно на нём. Это очень хороший легкий прокси-сервер, созданный специально для подобных нужд. Может выдерживать очень большие нагрузки при относительно небольших ресурсах. (1000 прокси на каждый 1 GB RAM). Обкатано на десятках клиентов. У топовых клиентов поднимали до 16к прокси на одном сервере с 8 гб RAM.
• В случае если прокси сервер уже был ранее установлен — скрипт это определит, и спросит нужно ли переустанавливать. Удобно при повторных запусках, если нужно переделать. В таких случаях скрипт перемещает старые конфиги и списки прокси, помечая их текущей датой-временем. Так что, в случае чего всегда можно вручную откатить с бэкапов, даже если что-то пойдёт не так.
• Позволяет включить логгирование (интерактивно спрашивает об этом при настройке)
• Создаёт удобный скрипт для запуска-перезапуска.
• Прописывает старт прокси в автозагрузку
• Прописывает задание в планировщик (cron) для рестарта проксей каждый час, во избежание зависаний.

Бонусом к скрипту идёт ещё один скрипт, который позволяет сгенерить список уникальных IP-адресов для сети IPv6 /48 — из каждой /64 сети получается один прокси. Поскольку IPv6 тоже набирает популярность, прокси на них получаются очень дешёвыми, поэтому продукт умеет работать и с этим.

Чего не умеет

• Добавлять прокси на уже настроенный сервер(в планах).
• Изменять настройки существующего сервера. Только полная перенастройка.
• Настраивать авторизацию не по логину-паролю, а по ip, например.
• Задавать единый логин-пароль на всю пачку адресов.
• Задавать единый порт для всех прокси.

Вот эти фичи возможно в скрипте появятся когда-нибудь, возможно даже в недалёком будущем.

И очень важная вещь. Я думаю это очевидно, но скорей всего не всем. Поэтому всё же считаю необходимым чётко оговорить:

• Скрипт НЕ УМЕЕТ создавать и настраивать прокси без IP-адресов 🙂

Скрипт этого не умеет, и не будет уметь никогда. Ибо для каждого прокси нужен отдельный IP. Даже если где-то вам выдавали много прокси на одном IP — скорей всего вам выдавали только входной интерфейс, с разными портами. А на выходе должны быть разные IP. Если вы хотите поднять прокси на своём VPS где у вас сайты работают — вы сможете это сделать, конечно. Но покупать его для сего нецелесообразно. Ибо на таком сервере вы поднимете 1 прокси, ну или сколько там у вас есть адресов. ()

Планы на развитие

Скрипт постоянно развивается, покуда у меня есть клиенты на настройку прокси-серверов. Более того, я планирую развить этот скрипт в полноценную панель управления проксями. Чтобы можно было все настраивать, мониторить и управлять через веб-интерфейс. Совсем уж в далёких планах — прикрутить даже биллинг, для продажи прокси. Но это не точно 🙂

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

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

Ибо инструмент довольно востребованный, судя по рынку, но сейчас у меня нет времени на то чтобы его развивать, потому что занимаюсь другими задачами. Если же я буду получать фидбек от людей, пользующихся инструментом — мне будет гораздо проще его дорабатывать и поддерживать. Тут даже как — я не смогу этого не делать 🙂

Оплата и ценовая политика

Покупать скрипт лучше всего в . Его, кстати, планируется постепенно пополнять новыми ништяками, коих скопилось уже пару десятков в закромах. Пока там доступна оплата только с помощью Webmoney, но в ближайшее время буду подключать и другие способы. Сейчас если есть необходимость оплатить другим способом — можно стучаться по контактам ко мне — там уже решим, это без проблем — яндекс, киви или даже paypal.

Именно по такой цене я продавал его людям по запросу, которых можно считать альфа-тестерами 🙂 От некоторых из них поступали заказы на разработку дополнительных фич, которые вошли в текущую версию скрипта. А какие-то возможно ещё войдут. Когда (и если) скрипт вырастет в полноценную панель управления — цена поднимется, скорей всего.

Презентация и инструкция — поднимаем свой сервер с любым количеством прокси за 10 минут!

1. Введение

В данной статье пойдет речь о нестандартном использовании PHP: для создания сжимающего трафик PHP-скрипта, который можно использовать в качестве виртуального прокси-сервера. Профессионалы PHP-фронта здесь вряд ли найдут что-то новое: такое применение php не мое ноу-хау и никаких особых функций php не используется. Остальные в этой статье узнают о новом способе экономии кило-мега-гигабайтов во время веб-серфинга. Не удивлюсь, если кто-то предприимчивый, прочитав эту статью, начнет уже завтра экономить свои мегабайты. Особенно после того, как узнает, каким образом можно построить схему прозрачной работы этой виртуальной прокси.

На заре моей диалап-юности модемы обменивались сжатыми данными, из-за чего конечная скорость веб-серфинга была выше в сравнении со скачиванием zip-архива. Таким образом экономились время и деньги клиента за счет нагрузки на процессоры модемов во время компрессии. Настали другие времена: диалап постепенно сдает свои позиции под натиском выделенных линий. А тут уже ни о каком сжатии трафика на чьих-либо процессорных мощностях речи не ведется как правило: трафик идет в своем первозданном виде, ни на байтик не сжат
(если этим не озаботились на стороне
сервера). А ведь его можно сжать!..

Для этого нам понадобится еще одно звено между браузером и веб-сервером, которое, как модем, будет сжимать весь входящий (входящий для браузера) трафик. Звеном этим будет являться обычный с виду php-скрипт на удаленном веб-сервере. Именно этот скрипт в ответ на специально составленный запрос и будет скачивать необходимую вам страницу и уже в сжатом виде отдавать ее браузеру. Основные требования к хостингу, на котором расположен этот php-скрипт: отсутствие баннеров хостера, возможность использования CURL и GZIP (проверить их доступность можно запуском скрипта с вызовом функции
phpinfo).

Чтобы лучше понять механизм работы системы промежуточного сжатия трафика, рассмотрим более подробно технологию ее работы.

На рисунке ниже представлена схема трех вариантов загрузки страницы: обычный вызов, сжатие данных на промежуточном сервере и прозрачная работа со сжатием страницы на промежуточном сервере. Рассмотрим что происходит в каждом из случаев.

2. Получение браузером страницы из сети

2.1. Обычный вызов

Допустим пользователя заинтересовала страница page.html на сервере site.com . Он набирает URL site.com/page.html в строке адреса. Браузер после этого производит по сети http-запрос страницы http://site.com/page.html (на рисунке — тонкая пунктирная стрелка, первая слева). В ответ на этот запрос веб-сервер site.com выдает http-ответ браузеру и следом за ним тело страницы page.html (на рисунке – жирная стрелка, вторая слева). После этого браузер отображает пользователю на экране монитора содержимое полученной страницы.

2.2. Сжатие данных на промежуточном сервере

Введем промежуточный сервер webzip.com между браузером и веб-сервером site.com, на котором будет происходить сжатие данных. Алгоритм получения страницы page.html такой же, как и в предыдущем случае за исключением того, что браузер запрашивает страницу не непосредственно у site.com, а через webzip.com. Причем полноразмерные (несжатые данные) идут только между site.com и webzip.com, между браузером и webzip.com тело страницы идет в сжатом виде (на рисунке — жирная пунктирная стрелка, третья слева). Заметим, что по причине использования возможностей php для сжатия страницы её адрес, запрашиваемый браузером, примет вид http://webzip.com/myzip.php?url=http://site.com/page.html. Веб-сервер (webzip.com), получив этот запрос, вызывает скрипт myzip.php, а тот в свою очередь по get-параметру (пусть им будет параметр с именем «url») вызова производит запрос на http://site.com/page.html. Полученную страницу скрипт myzip.php отдает браузеру в сжатом виде.

2.3. Прозрачная работа со сжатием страницы на промежуточном сервере

От предыдущего случая данный отличается тем, что работа виртуальной сжимающей прокси для браузера, а соответственно и пользователя, не видны. Достигается это за счет введения еще одного звена, между webzip.com и браузером. Этим звеном является обычный http-прокси, который помимо всего прочего занимается переписыванием исходящих заголовков http-запросов (например, с http://site.com/page.html на
http://webzip.com/myzip.php?url=http://site.com/page.html).

3. Настройка прозрачной работы

3.1. Установка скриптов

Скачать скрипты, которые реализуют все вышеописанное, можно здесь. В
три файла: myzip.php, func.inc.php, log.php. Первый – основной файл, к которому обращается клиент. Второй – содержит определения функций для первого. Третий – предназначен для отображения статистики работы прокси (содержит шаблон страницы статистики, суть берется из файлов log.log и
count.log).

Как уже было сказано ранее, разместить скрипты следует на любом хостинге, где есть поддержка PHP, CURL, ZLIB и отсутствуют банеры. В интернете такое можно без труда найти за 30 рублей в месяц.

Не пугайтесь платности хостинга – он с легкостью будет окупаться. Например, если вы платите 0.05 $/МБ — потребуется 20 сэкономленных мегабайт для оплаты хостинга, дальше выгода. По моему опыту это порядка 100-150 МБ веб-серфинга (среднее сжатие – в 4-7 раз, хотя встречается и до 12).

Проверить правильность работы можно, набрав в браузере следующий адрес: http://webzip.com/myzip.php?url=http://ya.ru. Если всё сделано правильно – загрузится страница яндекса с немного видоизмененным заголовком
(title).

3.2. Настройка Proxomitron-а

Использовался Proxomitron ver. Naoko 4.4 (http://www.proxomitron.ru).

Итак, мы хотим добиться от проксомитрона возможности прозрачной работы с веб-проксей, иными словами скрытое преобразование исходящих URL-ов от браузера. Для этого в главном окне проксомитрона нажимаем клавишу «Заголовки» («Headers»). В открывшемся окне («Фильтры заголовков HTTP» / «HTTP Header Filters») пролистываем до строки «URL: Alias Redirector (Out)», выделяем ее. Жмем кнопку «Изменить» («Edit»), в
развернувшемся окне («Редактор фильтров заголовка» / «HTTP Header filter editor») заполняем поля следующим образом (все, кроме первого):

Заголовок HTTP (HTTP Header) (!не меняем!) URL: Alias Redirector (Out)
Совпадение с URL (URL Match) *
Значение заголовка (Header Value Match) *
Текст замены (Replacement text) $RDIR(http://webzip.com/myzip.php?url=\u)
Где http://webzip.com/ — URL вашего сайта, myzip.php – имя скрипта, который вы закачали на сайт.

Вся суть в последней строке: проксомитрон будет менять любой URL (параметр «\u») от браузера на http://webzip.com/myzip.php?url=\u. Если написать вместо $RDIR команду $JUMP, то работа проксомитрона будет полупрозрачной: браузер будет просто перенаправляться на новый URL. В случае использования $RDIR – перенаправление будет происходить незаметно для браузера.

Закрываем окна, нажимая последовательно «Ок», «Применить» («Apply»), «Ок». Если есть желание не повторять эту процедуру снова – сохраните настройки.

В браузере прописываем прокси сервер с IP=127.0.0.1 и портом 8080 (порт, прослушиваемый проксомитроном по умолчанию).
Убедиться в том, что система сжатия трафика работает, можно всё так же — по изменяющимся заголовкам страниц (новый