Локальный прокси: Локальный прокси-сервер для фильтрации браузерного трафика / Хабр

Содержание

Локальный прокси-сервер для фильтрации браузерного трафика / Хабр

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

Первоначально была задача упростить посещение сайтов через медленное (около 5-10кбайт/с с лагами) подключение. Тут два основных направления: 1) вырезать всё что не нужно (в первую очередь рекламу), и 2) закешировать всё что можно закешировать без особого вреда для функционала посещаемых сайтов, даже когда сами сайты не разрешают кеширование в http-заголовках, а то и явно препятствуют ему, дописывая после урлов статических файлов знак вопроса с рандомным числом.

Предупреждение: реализация, описанная ниже, делалась для Linux-а, вроде бы работает на других *nix, но даже компиляция её на винде не рассматривалась (хотя возможность адаптировать, конечно, есть).

Черновой вариант: nginx + php-fpm

Тратить на всё это время не хотелось, поэтому было решено по-быстрому настроить связку nginx + php-fpm, из которых первый разбирал входящие подключения, включая https и перенаправлял их все, без разбора хостов и урлов, в один и тот же php-скрипт. Так же была маленькая программа на C, которая конвертировала http-proxy-протокол в обычный http(s)-трафик. То есть превращала запросы GET http://host/path HTTP/1.x в GET /path HTTP/1.x (имя хоста всё равно есть в Host-заголовке) и проксировала все https CONNECT’ы на локальный nginx. Как потом выяснилось, убирать http://host из http-запросов было не обязательно, nginx их принимает так же как и обычные.

PHP-скрипт, в свою очередь, собирал назад разложенный по разным переменным запрос, через fsockopen() подключался к целевому серверу (благо там поддержка SSL встроенная), слал собранный http-запрос, забирал ответ и отправлял его браузеру с помощью header() и echo. Скрипт делался не совсем с нуля, спасибо некоей Évelyne Lachance за https://github.com/eslachance/php-transparent-proxy (но всё же то, что по ссылке, имеет несколько другую цель и поэтому просто скопировать его было нельзя).

Тут возникли две проблемы

Во-первых, если собрать сам исходный URL труда не представляло, то содержимое POST-запросов собирать было уже сложнее, а если там ещё и необычный Content-Type и отправка файлов — то php-шный парсер почти необратимо терял исходные данные, собрать всё это назад из массива $_POST[] и уже залитых в серверную файловую систему загруженных файлов, ничего не потеряв, было почти нереально (по крайней мере по моей оценке). Но спасла положение весьма кстати появившаяся в php 5.4 опция enable_post_data_reading — если её поставить в off, то тело запроса парситься не будет и его можно будет просто прочитать блобом из файла ‘php://input’. При этом массивы $_POST и $_FILES, естественно, не будут инициализироваться, но они нам и не нужны.

Во-вторых, nginx не умеет генерить сертификаты на лету из коробки, а настройку «игнорировать все проблемы с сертификатами» я в firefox не нашёл. Проблема была на тот момент решена патчем браузера, заставлявшим его любой сертификат считать доверенным и подходящим. Наверно были и другие способы это сделать, но все они казались сложнее. Патч естественно был кривой и сделанный почти методом тыка (желания изучать весь браузерный код проверки сертификатов не было), но он делал своё дело, а больше было и не надо.

Между сборкой исходного запроса и отправкой проксированного тривиальным образом были добавлены два куска кода. Один проверял, что host или host/path не из чёрного списка (организованного в виде отдельного php-файла с массивом внутри). Второй проверял, нет ли страницы в кеше (если есть — отдаётся из кеша). Если страницы в кеше нет, то делается проксированный запрос. Если запрос был GET и статус ответа 200, то полученная страница — кандидат на запоминание в кеше. Запоминать или нет — решалось функцией, которая по хосту, урлу (там просто были прописаны конкретные адреса, которые меня интересовали и которые я знал что надо кешировать) и content-type выносила вердикт. Кешировалось немного: http-статус, content-type и тело ответа. И при отдаче из кеша, соответственно, отдавались только эти данные, а все остальные заголовки, которые были в исходном ответе, безвозвратно терялись.

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

В следующие полгода использования система дорабатывалась под решение возникающих проблем (как проблем из-за общей её кривости, так и проблем — возникающих задач).

Ещё через 3-4 месяца мне надоело патчить браузер после каждого апдейта и было решено сделать всё по-нормальному — nginx и php выкидываем и пишем всё на C.

Итоговый вариант

Маленькая программа (из старой версии), которая разбирала и перенаправляла прокси-протокол, была взята за основу. Первоочерёдной задачей было реализовать в ней разворачивание https, потому что всё остальное в общем-то уже известно как делать (делалось не раз в другим проектах), а с SSL где-то кроме php я на тот момент ни разу не работал.

Для этого взял библиотеку OpenSSL. Весь код, её использующий, было решено выделить в отдельные процессы. Потому что, во-первых, в ней тогда постоянно находились дыры (а межпроцессная изоляция может эту проблему иногда сгладить), во-вторых так проще делать (модульность и инкапсуляция на уровне сокетов), и в-третьих API OpenSSL местами весьма странное (мягко говоря), и для нейтрализации последствий то ли кривого API, то ли неправильного его применения (вследствие отсутствующей или двусмысленной документации) удобно просто убивать ssl-процесс после того как соединение завершилось (к сожалению, это плохо сказывается на производительности, но я с этим смирился).

Жалобы на OpenSSL и на SSL

Вообще, из-за регулярных уязвимостей и невнятного API я даже собирался написать свою реализацию TLS, и даже начал, но, дойдя до парсинга сертификатов (увы, без этого почти ничего не сделать, ибо сертификаты оказывается используются не только для защиты от подмены сервера, но и для согласования ключей, даже если защита от подмены не нужна), испытал ещё один дискомфорт от спецификации ASN1. Стало понятно, что API библиотеки это только вершина айсберга, а внутри оно всё такое уже начиная с RFC самого протокола. Хотя в последнее время я более менее с этим всем смирился.

SSL/TLS-обёртки

Итак, были сделаны две вспомогательные программы, одна для заворачивания клиентского нешифрованного сокета в SSL/TLS, и вторая для разворачивания зашифрованного сокета, принятого сервером, в незашифрованный. Принцип простой: у подпрограммы есть наследуемые от родительской программы файловые декрипторы, которые родительская программа может заранее открыть нужным образом так, что дочерний процесс будет выглядеть для неё просто сокетом, в который можно записывать и из которого можно читать. При этом практически никакого отличия этого межпроцессного сокета от сокета интернетного не будет.

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

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

Программы названы ssl-server-wrapper и ssl-client-wrapper. Кстати, второй можно запустить и отдельно вручную — тогда нешифрованный канал будет направлен в терминал, откуда его запустили, а установить SSL-соединение можно, набрав несколько простых команд.

Пример

Пишем

$ host ya.ru                        - узнаём ip-адрес
ya.ru has address 87.250.250.242
$ ./ssl-client-wrapper
T/etc/ssl/certs/ca-certificates.crt    - указать место где хранятся доверенные RootCA
C87. 250.250.242:443/ya.ru              - подключиться по указанному адресу с указанным SNI

Ответ (много отладочных логов, можно скомпилировать чтобы было без них): дамп сертификата и предоставленной цепочки

DEBUG: cert[-1] subject = /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: cert[-1] issuer = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[0] subject = /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: cert[0] issuer = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[1] subject = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[1] issuer = /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
DEBUG: cert[2] subject = /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
DEBUG: cert[2] issuer = /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA

Попытка собрать trusted цепочку

DEBUG: cert[-1] issued by cert[1]
DEBUG: cert[1] issued by cert[2]
DEBUG: cert[2]=cert[*0] was not issued by something from trusted-cert-store - chain incomplete, trying to recover
DEBUG: cache miss at . /cert-pin/cache/9nqv0qm41tlxyel95bbods0famxjagbx.0
DEBUG: downloading AIA issuer cert: http://repository.certum.pl/ca.cer
DEBUG: cert[*0] issued by cert[*1]
DEBUG: cert[*1] is self-signed, chain ended

Как видно, «Certum CA» нет в списке доверенных Root CA, поэтому на первый взгляд это обрыв цепочки, но во втором сертификате цепочки (cert[2]) нашлась ссылка http://repository.certum.pl/ca.cer откуда можно скачать этот неизвестный сертификат; сертификат скачан (cert[*1]), но оказался самоподписанным и таким образом ничему не помогающим. На самом деле, в Root CA есть «Certum Trusted Network CA», так что всё в порядке и можно было ничего не скачивать.

Проверка соответствия доменного имени:

DEBUG: check wildcard '*.yandex.az' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.tm' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.com.ua' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.de' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.  jobs' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.net' against needed name 'ya.ru'
DEBUG: check wildcard '*.xn--d1acpjx3f.xn--p1ai' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.com.ge' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.fr' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.fr' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.kz' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.aero' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.jobs' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.ee' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.com' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.tm' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.ru' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.ru' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.lv' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.lt' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.  az' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.net' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.lt' against needed name 'ya.ru'
DEBUG: check wildcard 'ya.ru' against needed name 'ya.ru'

Итог:

DEBUG: protocol = TLSv1.2
DEBUG: cipher = ECDHE-RSA-AES128-GCM-SHA256
DEBUG: verify_result = 0
DEBUG: server_cert subject: /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: server_cert issuer: /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
OK: connection to 87.250.250.242:443/ya.ru established

Теперь есть прозрачное подключение, шлём http-запрос и получаем ответ

GET / HTTP/1.0
Host: ya.ru
Connection: close
HTTP/1.1 200 Ok
Accept-CH: Viewport-Width, DPR, Device-Memory, RTT, Downlink, ECT
Accept-CH-Lifetime: 31536000
(...)

Основной функционал

С шифрованием разобрались, теперь можно приступить к обработке полезной нагрузки.

Так как nginx у нас больше нет, то парсинг запроса придётся реализовывать заново. В целом ничего сложного тут нет, сначала парсятся заголовки через \r\n или \n разделитель, до тех пор пока не встретится пустая строка, а затем, если был заголовок Content-Length, читается тело запроса указанного количества байт. Chunked encoding в запросах можно и не поддерживать — никакие нормальные браузеры, да и вообще http-клиенты, его не генерируют.

После того, как запрос распарсен, он попадает в обработчик запроса — это та часть, которая раньше была написана на php, весьма увеличившаяся в размерах и количестве файлов. И хотя списки правил (кого блокировать, кого кешировать, кому резать куки и т.д.), ранее бывшие оформлены в виде php-массивов и коротких скриптовых функций, были переделаны в отдельные текстовые файлы специального удобного формата, но часть «пользовательской» логики всё ещё защита в коде (только теперь на C а не PHP), а код в целом унаследовал много признаков «сделать побыстрее как-нибуть» от своего предшественника. Сейчас обработчик (кроме капитально переделанных списков правил) всё так же сделан в виде одного «потока» кода из «главного» файла и вставленных в него include (не заголовочных файлов а сам код).

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

Что получилось

Отдельные модули для разворачивания шифрованного SSL/TLS-туннеля, один из которых при желании можно использовать как самостоятельную программу типа ssl-telnet. Ещё можно заменить их на какие-то альтернативные реализации (например с другой крипто-библиотекой), при этом остальная часть прокси ничего не заметит. Аналогично с инкрементальными обновлениями, ничего даже не нужно перезапускать. А ещё можно их использовать как демки по работе с OpenSSL (я прочёл много документации и всяких обсуждений в процессе их написания, возможно кто-то сможет теперь всё это быстрее усвоить).
Код старался делать максимально понятным и простым.
- У клиента есть хранилище сертификатов для: белый список по сайтам (принимать и не проверять), чёрный список по сайтам (не проверять и не принимать), список вопросов (те, которые не входят ни в белый, ни в чёрный и не прошли валидацию — аналог браузерной страницы с предложением внести подозрительный сертификат в список исключений). Для сайтов можно включать режим белого списка (то есть принимать только сертификаты из него, остальные считать недоверенными). К сожалению, всё это делается путём манипуляций над файлами, интерактивного приложения пока нет.
- Серверная часть сама генерирует сертификаты ко всем сайтам на лету, ей нужен только корневой сертификат, добавленный как trusted root CA в браузер.
Возможность пробросить точку выхода в интернет через, например, ssh port forwarding (связанный с этим функционалом код расположен в helpers/remote.c и в proxy.c в месте где обрабатывается аргумент «—proxy».
Это не тоже самое что запустить само прокси на удалённом сервере. Тут важно что кеш и расшифровка SSL/TLS находятся на локальном компе, а пробрасывается только «внешний» конец. Хотя я давно не проверял работу этого режима, могла и сломаться.
Единообразный формат файлов правил для: блокировки загрузки страниц, блокировки куков, управления кешированием, включения сниффера, включения raw-режима (для real-time стримингов).

Аналог /etc/hosts но усовершенствованный: возможность сопоставления айпи-адреса не только по хосту, но и по порту и по протоколу, а так же сменить порт и протокол подключения.
Кеш, управляемый прописанными ему настройками, а не заголовками, присланными сервером. Заголовки управления кешированием часто не отражают действительность (или отражают мнение владельца сайта, которое может расходиться с критериями удобства пользования этим сайтом), поэтому сейчас они игнорируются. Думаю что стоит сделать их учёт по принципу «если сайт разрешил кешировать то значит можно, а если нет — разбираемся сами можно или нельзя», но пока руки не дошли.
Кеш хранится в интуитивно понятно организованном дереве директорий, хранится бессрочно, но можно либо вручную удалять отдельные сохранения, либо настройкой задать «игнорировать всё что сохранено раньше такого-то времени».
- Кроме кеша есть ещё сохранения — это те страницы, которые не берутся с диска при запросе к ним, но на всякий случай всё равно сохраняются. При включении оффлайн-режима они тоже смотрятся (в файл offline.flag надо прописать предпочтительное время, за которое будут искаться сохранённые страницы при обращении к ним). При настройке сохранений учтите, что, несмотря на то, что сохраняются только ответы (содержимое POST-запросов не сохраняется), в них всё же могут быть некоторые данные, которые стоит беречь от кражи, а сохранённые на диске страницы — дополнительный вектор атаки.
Возможность кастомных действий перед, после или вместо загрузки страницы проксированным запросом. Реализваны хардкодом, файл handle/inc.rewrite.c
Есть dashboard (двоичный файл со статусами всех потоков прокси) и программа для его вывода на экран в удобном виде.
./dashboard --basedir=/path/to/proxy/base --highlight --loop
Любой аспект работы прокси можно легко переделать при необходимости. Код, несмотря на то, что он весьма разросся по сравнению с первыми версиями, всё ещё занимает очень мало места, и не потребует много времени как на первоначальное изучение, так и на освежение в памяти забытых деталей. С другой стороны, кому-то это и минус — для пользования всеми возможностями программы предполагается её регулярная пересборка и правка кода, а не «скомпилировал и удалил исходники».

Плюсы и минусы
(+) Модульность
(-) Из-за изоляции OpenSSL работает медленнее чем могло бы
(+) Гибкая настраиваемость под конкретные нужды
(+-) Много настроек прямо в исходном коде в виде #define и не только
(+-) IPv6 не поддерживается
(-) Нет интерактивного приложения для настройки и управления
(-) Код местами весьма плох и костылен
(-) До сих пор нет поддержки Access-Control-Allow-Origin с не ‘*’ в закешированных ответах — но единственное что у меня от этого ломалось это интерфейс мэйлру почты.
(-) До сих пор нет поддержки учёта настроек кеширования, присылаемых сервером
(-) Скачивать через него большие файлы (не в raw режиме) неэффективно — сначала прокси скачает файл себе на диск, затем будет через localhost-сеть отдавать его браузеру, который опять будет сохранять его на диск, а ещё там где-то (а может и в нескольких местах) прописано ограничение в 10мбайт на запрос

Как собрать/установить и технические детали кода

Из обычных библиотек используются стандартная C-библиотека, zlib (для распаковки gzip http-ответов), openssl (линкуется только к ssl-подпрограммам). В случае с Debian это были пакеты zlib1g-dev и libssl-dev. Так же используются свои библиотеки (маленькие) с кодом который мне часто оказывается нужен в разных местах и поэтому вместо регулярного копипаста выделен в отдельные компилируемые единицы.

В целях данной публикации, для упрощения всё это собрано в один пакет (скачать можно тут) и обёрнуто в один сборочный скрипт (да, не Makefile, так уж вышло что пока я обхожусь без make) build-all. sh.

Ряд настроек расположен в исходниках: в скрипте fproxy/build2.sh, в файле fproxy/config.h (если у вас файл с бандлом доверенных центров сертификации расположен не в /etc/ssl/certs/ca-certificates.crt то надо этот путь заменить тут). Настройки подпрограмм (helpers/) расположены прямо в их коде вверху в виде #define (config.h они не используют), но их менять вряд ли кому потребуется.

То, что некоторая часть настроек прописана в компилируемом коде, а не в файлах настроек сделано для (моего) удобства. В файлах настроек настраивается то, что можно назвать наиболее часто меняющимися пользовательскими настройками (списки правил), а всё остальное — в общем то первоначальная настройка программы при её установке, и крайне редкие изменения всяких технических параметров (даже чаще меняется логика работы кода чем #define-настройки). По факту сейчас вполне рабочая версия получается если просто запустить build-all.sh и не трогать никакие исходники перед этим.

Но переделать код на приём настроек через командную строку или из ещё одного файла конфигурации несложно.

Для работы прокси нужна заранее подготовленная структура директорий. Для её создания есть скрипт prepare-dir.sh — он создаёт рядом подготовленную директорию fproxy-target/ со всем что требуется и кладёт туда примеры правил (в том числе много блокировок спамных доменов).

Путь	Описание:
cache/	Симлинки на второй уровень cache_real/.
cache_real/	Кеш, двухуровневая структура — домен 2 уровня, потом полный домен.
saved/	Симлинки на второй уровень saved_real/.
saved_real/	Сохранённый не-кеш, 2-ур. структура.
cert-pin/certs/	Настройки сертификатов для каждого домена (общий режим, белый/чёрный списки, вопросы).
cert-pin/queue/	Тут создаются файлы при появлении вопросов в качестве флажков для интерактивной программы управлением этими настройками, если она будет.
cert-pin/cache/	Кеш известных проксе сертификатов для дополнения неполных цепочек, принятых от сайтов (это НЕ список доверия, все эти сертификаты действительны только после прохождения проверок на общих основаниях).
dyn-certs/	Кеш для сгенерированных сертификатов которые шлются браузеру.
hist/	Сохранённая история посещений (инструментов для её просмотра пока нет, кроме ручного).
internal/	Сейчас тут хранится сокет для запросов от скачивателя AIA сертификтов к проксе.
log/	Логи.
pem/	Корневой сертификат и приватные ключи для генерации сертификатов сайтов.
proxy_temp/	Хранение запросов которые слишком большие для хранения их в памяти.
tmp/	Временные файлы.
dyn-cert-serial	Файл с текущим серийным номером генерируемого сертификата (начальное содежание — символ ‘0’ и перевод строки после него).
mincache.date	Если файл есть и в нём тут записано число больше 0, то весь кеш раньше этого времени будет игнорироваться.
offline.flag	Если файл есть и в нём тут записано число больше 0, то прокси будет работать в режиме «интернет-архива» — на каждый запрос сначала искать в saved_real/ данные, близкие по времени к указанному числу, и только если не нашлось — проксировать запрос.
rules_*.txt	Различные правила, на данный момент их изменения учитываются только после перезапуска прокси.

Насчёт прав доступа и вообще безопасности

Простейший вариант установки — запустить всё из под своего обычного юзера с обычными правами на всё (можно даже прямо из директории fproxy-target/, созданной скриптом prepare-dir.sh).

Но по ряду причин имеет смысл сделать по-другому. Для прокси создаётся отдельный юзер и группа, ему выдаются эксклюзивные права на чтение данных прокси, и права на запись в несколько мест, где они нужны. Права «только чтение» можно реализовать, поставив владельца root и группу прокси, и поставив доступ 0640 или 0750. Делать что бы то ни было из данных world-readable в любом случае плохая идея, всё же там лежит вся история браузера, а где-то и сохранённое содержание страниц, а так же ключи, с помощью которых браузеру можно делать MITM.

Для работы программы dashboard ей нужен только доступ на чтение к файлу BASE/log/dashboard и ничего другого.

По умолчанию прокси слушает 127.0.0.10:3128. Для работы с 127.0.0.10 у меня ничего специально настраивать (в ОС) не пришлось, но возможно в каких-то системах нужно.

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

Заключение

Ещё раз ссылка на скачивание: тут.

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

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

Надеюсь, что кому-то это всё окажется интересным и так или иначе поможет.

Настройка параметров прокси-сервера для локального шлюза данных

Статья
11/15/2022
Чтение занимает 3 мин

Рабочим средам может понадобиться, чтобы доступ в Интернет осуществлялся через прокси-сервер. Это требование может препятствовать подключению локального шлюза данных Майкрософт к службе.

В следующей записи на superuser.com обсуждается, как вы можете попытаться определить, есть ли прокси-сервер в вашей сети: Как узнать, какой прокси-сервер используется? (SuperUser.com).

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

Есть три файла конфигурации, связанных с использованием прокси-сервера с локальным шлюзом данных. К шлюзу и процессу его настройки применяются следующие два основных файла конфигурации.

Первый файл предназначен для экранов конфигурации, используемых непосредственно для настройки шлюза. Если у вас есть проблемы с настройкой шлюза, посмотрите на следующий файл: C:\Program Files\On-premises data gateway\enterprisegatewayconfigurator.exe.config.
Второй файл предназначен для фактической службы Windows, которая взаимодействует с облачной службой с помощью шлюза. Этот файл обрабатывает запросы: C:\Program Files\On-premises data gateway\Microsoft.PowerBI.EnterpriseGateway.exe.config.

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

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

C:\Program Files\On-premises data gateway\m\Microsoft.Mashup.Container.NetFX45.exe.config

В следующем разделе описывается, как редактировать эти файлы.

Настройка параметров прокси

В следующем примере показана конфигурация прокси-сервера по умолчанию, имеющаяся в обоих основных файлах конфигурации.

<system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>

В конфигурации по умолчанию применяется аутентификация Windows. Если прокси-сервер использует другую форму проверки подлинности, необходимо изменить параметры. Если вы не уверены, обратитесь к администратору сети.

Не рекомендуем использовать базовую проверку подлинности прокси-сервера. Использование базовой проверки подлинности прокси-сервера может привести к ошибкам, и в результате будет неправильна настройка шлюза. Чтобы устранить ошибку, выберите более надежный механизм проверки подлинности прокси.

Помимо использования учетных данных по умолчанию, можно добавить элемент <proxy>, чтобы более детально определить параметры прокси-сервера. Например, можно указать, что локальный шлюз данных всегда должен использовать прокси-сервер даже для локальных ресурсов, присвоив параметру bypassonlocal значение false. Этот параметр может помочь при устранении неполадок, если нужно отслеживать все HTTPS-запросы, исходящие из шлюза данных, в файлах журнала прокси-сервера. В соответствии с приведенным ниже образцом конфигурации все запросы должны передаваться через определенный прокси-сервер с IP-адресом 192.168.1.10.

<system. net>
    <defaultProxy useDefaultCredentials="true">
        <proxy  
            autoDetect="false"  
            proxyaddress="http://192.168.1.10:3128"  
            bypassonlocal="false"  
            usesystemdefault="true"
        />  
    </defaultProxy>
</system.net>

Вам также необходимо отредактировать файл Microsoft.Mashup.Container.NetFX45.exe.config, если вы хотите, чтобы шлюз подключался к облачным источникам данных через шлюз.

В файле разверните раздел <configurations>, чтобы включить указанное ниже содержимое, а также обновите атрибут proxyaddress, добавив сведения о прокси-сервере. Следующий пример перенаправляет все запросы облака через определенный прокси-сервер с IP-адресом 192.168.1.10.

<configuration>
    <system.net>
        <defaultProxy useDefaultCredentials="true" enabled="true">
        <proxy proxyaddress="http://192.168.1.10:3128" bypassonlocal="true" />
        </defaultProxy>
    </system. net>
</configuration>

Настройка этого третьего файла может потребоваться, если ваш прокси-сервер является обязательным для всего обмена данными через Интернет, особенно для корпоративного использования, когда сети безопасны и заблокированы. Если прокси-сервер нужен для обмена данными через шлюз, он, вероятно, также понадобится для любого интернет-трафика из контейнеров. В этом случае может показаться, что шлюз работает успешно, пока какой-либо контейнер не сделает внешний (через Интернет) запрос. Эта проблема особенно применима к потокам данных, которые пытаются отправить результирующий запрос локальных данных в Azure Data Lake Storage. Но это также применимо, когда запрос шлюза объединяет локальный набор данных с привязанным к Интернету набором данных.

Дополнительные сведения о настройке элементов прокси-сервера в файлах конфигурации .NET см. в статье об элементе defaultProxy (параметры сети).

Смена учетной записи службы шлюза на пользователя домена

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

Примечание

Чтобы избежать необходимости сбрасывать пароли, рекомендуем использовать управляемую учетную запись службы. Узнайте, как создать управляемую учетную запись службы в Active Directory.

Дальнейшие действия

Сведения о брандмауэре

Локальный прокси-сервер для фильтрации браузерного трафика

Черновой вариант: nginx + php-fpm

Тратить на всё это время не хотелось, поэтому было решено по-быстрому настроить связку nginx + php-fpm, из которых первый разбирал входящие подключения, включая https и перенаправлял их все, без разбора хостов и урлов, в один и тот же php-скрипт. Так же была маленькая программа на C, которая конвертировала http-proxy-протокол в обычный http(s)-трафик. То есть превращала запросы GET http://host/path HTTP/1.x в GET /path HTTP/1. x (имя хоста всё равно есть в Host-заголовке) и проксировала все https CONNECT’ы на локальный nginx. Как потом выяснилось, убирать http://host из http-запросов было не обязательно, nginx их принимает так же как и обычные.

PHP-скрипт, в свою очередь, собирал назад разложенный по разным переменным запрос, через fsockopen() подключался к целевому серверу (благо там поддержка SSL встроенная), слал собранный http-запрос, забирал ответ и отправлял его браузеру с помощью header() и echo. Скрипт делался не совсем с нуля, спасибо некоему Évelyne Lachance за https://github.com/eslachance/php-transparent-proxy (но всё же то, что по ссылке, имеет несколько другую цель и поэтому просто скопировать его было нельзя).

Тут возникли две проблемы

Итоговый вариант

Жалобы на OpenSSL и на SSL

SSL/TLS-обёртки

Таким образом, сервер принимает (accept) входящее подключение, выясняет что на той стороне хотят SSL/TLS, после чего отдаёт соединение дочернему процессу (который поднимает SSL/TLS-сессию, генерирует сертификат если нужно или берёт уже ранее сгенерированный), а от дочернего процесса берёт межпроцессный сокет, через который передаются уже нешифрованные данные. В итоге весь дальнейший код может вообще не делать различий между http-соединением и https-соединением, прозрачно расшифровывающимся дочерним процессом, и использовать для работы с этими соединениями обычные функции для работы с сокетами.

Пример

Пишем

$ host ya.ru                        - узнаём ip-адрес
ya.ru has address 87.250.250.242
$ ./ssl-client-wrapper
T/etc/ssl/certs/ca-certificates.crt    - указать место где хранятся доверенные RootCA
C87.250.250.242:443/ya.ru              - подключиться по указанному адресу с указанным SNI

DEBUG: cert[-1] subject = /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: cert[-1] issuer = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[0] subject = /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: cert[0] issuer = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[1] subject = /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
DEBUG: cert[1] issuer = /C=PL/O=Unizeto Technologies S. A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
DEBUG: cert[2] subject = /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
DEBUG: cert[2] issuer = /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA

Попытка собрать trusted цепочку

DEBUG: cert[-1] issued by cert[1]
DEBUG: cert[1] issued by cert[2]
DEBUG: cert[2]=cert[*0] was not issued by something from trusted-cert-store - chain incomplete, trying to recover
DEBUG: cache miss at ./cert-pin/cache/9nqv0qm41tlxyel95bbods0famxjagbx.0
DEBUG: downloading AIA issuer cert: http://repository.certum.pl/ca.cer
DEBUG: cert[*0] issued by cert[*1]
DEBUG: cert[*1] is self-signed, chain ended

Как видно, «Certum CA» нет в списке доверенных Root CA, поэтому на первый взгляд это обрыв цепочки, но во втором сертификате цепочки (cert[2]) нашлась ссылка http://repository.certum.pl/ca.cer откуда можно скачать этот неизвестный сертификат; сертификат скачан (cert[*1]), но оказался самоподписанным и таким образом ничему не помогающим на самом деле, в Root CA есть «Certum Trusted Network CA», так что всё в порядке и можно было ничего не скачивать.

Проверка соответствия доменного имени:

DEBUG: check wildcard '*.yandex.az' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.tm' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.com.ua' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.de' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.jobs' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.net' against needed name 'ya.ru'
DEBUG: check wildcard '*.xn--d1acpjx3f.xn--p1ai' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.com.ge' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.fr' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.fr' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.kz' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.aero' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.jobs' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.ee' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.com' against needed name 'ya. ru'
DEBUG: check wildcard 'yandex.tm' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.ru' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.ru' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.lv' against needed name 'ya.ru'
DEBUG: check wildcard '*.yandex.lt' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.az' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.net' against needed name 'ya.ru'
DEBUG: check wildcard 'yandex.lt' against needed name 'ya.ru'
DEBUG: check wildcard 'ya.ru' against needed name 'ya.ru'

Итог:

DEBUG: protocol = TLSv1.2
DEBUG: cipher = ECDHE-RSA-AES128-GCM-SHA256
DEBUG: verify_result = 0
DEBUG: server_cert subject: /C=RU/O=Yandex LLC/OU=ITO/L=Moscow/ST=Russian Federation/CN=*.yandex.az
DEBUG: server_cert issuer: /C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
OK: connection to 87.250.250.242:443/ya.ru established

Теперь есть прозрачное подключение, шлём http-запрос и получаем ответ

GET / HTTP/1. 0
Host: ya.ru
Connection: close
HTTP/1.1 200 Ok
Accept-CH: Viewport-Width, DPR, Device-Memory, RTT, Downlink, ECT
Accept-CH-Lifetime: 31536000
(...)

Основной функционал

С шифрованием разобрались, теперь можно приступить к обработке полезной нагрузки.

Что получилось

Отдельные модули для разворачивания шифрованного SSL/TLS-туннеля, один из которых при желании можно использовать как самостоятельную программу типа ssl-telnet. Ещё можно заменить их на какие-то альтернативные реализации (например с другой крипто-библиотекой), при этом остальная часть прокси ничего не заметит. Аналогично с инкрементальными обновлениями, ничего даже не нужно перезапускать. А ещё можно их использовать как демки по работе с OpenSSL (я прочёл много документации и всяких обсуждений в процессе их написания, возможно кто-то сможет теперь всё это быстрее усвоить). Код старался делать максимально понятным и простым.
- У клиента есть хранилище сертификатов для: белый список по сайтам (принимать и не проверять), чёрный список по сайтам (не проверять и не принимать), список вопросов (те, которые не входят ни в белый, ни в чёрный и не прошли валидацию — аналог браузерной страницы с предложением внести подозрительный сертификат в список исключений). Для сайтов можно включать режим белого списка (то есть принимать только сертификаты из него, остальные считать недоверенными). К сожалению, всё это делается путём манипуляций над файлами, интерактивного приложения пока нет.
- Серверная часть сама генерирует сертификаты ко всем сайтам на лету, ей нужен только корневой сертификат, добавленный как trusted root CA в браузер.
Возможность пробросить точку выхода в интернет через, например, ssh port forwarding (связанный с этим функционалом код расположен в helpers/remote.c и в proxy.c в месте где обрабатывается аргумент «—proxy». Это не тоже самое что запустить само прокси на удалённом сервере. Тут важно что кеш и расшифровка SSL/TLS находятся на локальном компе, а пробрасывается только «внешний» конец. Хотя я давно не проверял работу этого режима, могла и сломаться.
Единообразный формат файлов правил для: блокировки загрузки страниц, блокировки куков, управления кешированием, включения сниффера, включения raw-режима (для real-time стримингов).
Аналог /etc/hosts но усовершенствованный: возможность сопоставления айпи-адреса не только по хосту, но и по порту и по протоколу, а так же сменить порт и протокол подключения.
Кеш, управляемый прописанными ему настройками, а не заголовками, присланными сервером. Заголовки управления кешированием часто не отражают действительность (или отражают мнение владельца сайта, которое может расходиться с критериями удобства пользования этим сайтом), поэтому сейчас они игнорируются. Думаю что стоит сделать их учёт по принципу «если сайт разрешил кешировать то значит можно, а если нет — разбираемся сами можно или нельзя», но пока руки не дошли. Кеш хранится в интуитивно понятно организованном дереве директорий, хранится бессрочно, но можно либо вручную удалять отдельные сохранения, либо настройкой задать «игнорировать всё что сохранено раньше такого-то времени».
- Кроме кеша есть ещё сохранения — это те страницы, которые не берутся с диска при запросе к ним, но на всякий случай всё равно сохраняются. При включении оффлайн-режима они тоже смотрятся (в файл offline.flag надо прописать предпочтительное время, за которое будут искаться сохранённые страницы при обращении к ним). При настройке сохранений учтите, что, несмотря на то, что сохраняются только ответы (содержимое POST-запросов не сохраняется), в них всё же могут быть некоторые данные, которые стоит беречь от кражи, а сохранённые на диске страницы — дополнительный вектор атаки.
Возможность кастомных действий перед, после или вместо загрузки страницы проксированным запросом. Реализваны хардкодом, файл handle/inc.rewrite.c
Есть dashboard (двоичный файл со статусами всех потоков прокси) и программа для его вывода на экран в удобном виде.
./dashboard --basedir=/path/to/proxy/base --highlight --loop
Любой аспект работы прокси можно легко переделать при необходимости. Код, несмотря на то, что он весьма разросся по сравнению с первыми версиями, всё ещё занимает очень мало места, и не потребует много времени как на первоначальное изучение, так и на освежение в памяти забытых деталей. С другой стороны, кому-то это и минус — для пользования всеми возможностями программы предполагается её регулярная пересборка и правка кода, а не «скомпилировал и удалил исходники».

Как собрать/установить и технические детали кода

Из обычных библиотек используются стандартная C-библиотека, zlib (для распаковки gzip http-ответов), openssl (линкуется только к ssl-подпрограммам). Так же используются свои библиотеки (маленькие) с кодом который мне часто оказывается нужен в разных местах и поэтому вместо регулярного копипаста выделен в отдельные компилируемые единицы.

Но переделать код на приём настроек через командную строку или из ещё одного файла конфигурации несложно.

Путь	Описание:
cache/	Симлинки на второй уровень cache_real/.
cache_real/	Кеш, двухуровневая структура — домен 2 уровня, потом полный домен.
saved/	Симлинки на второй уровень saved_real/.
saved_real/	Сохранённый не-кеш, 2-ур. структура.
cert-pin/certs/	Настройки сертификатов для каждого домена (общий режим, белый/чёрный списки, вопросы).
cert-pin/queue/	Тут создаются файлы при появлении вопросов в качестве флажков для интерактивной программы управлением этими настройками, если она будет.
cert-pin/cache/	Кеш известных проксе сертификатов для дополнения неполных цепочек, принятых от сайтов (это НЕ список доверия, все эти сертификаты действительны только после прохождения проверок на общих основаниях).
dyn-certs/	Кеш для сгенерированных сертификатов которые шлются браузеру.
hist/	Сохранённая история посещений (инструментов для её просмотра пока нет, кроме ручного).
internal/	Сейчас тут хранится сокет для запросов от скачивателя AIA сертификтов к проксе.
log/	Логи.
pem/	Корневой сертификат и приватные ключи для генерации сертификатов сайтов.
proxy_temp/	Хранение запросов которые слишком большие для хранения их в памяти.
tmp/	Временные файлы.
dyn-cert-serial	Файл с текущим серийным номером генерируемого сертификата (начальное содежание — символ ‘0’ и перевод строки после него).
mincache.date	Если файл есть и в нём тут записано число больше 0, то весь кеш раньше этого времени будет игнорироваться.
offline.flag	Если файл есть и в нём тут записано число больше 0, то прокси будет работать в режиме «интернет-архива» — на каждый запрос сначала искать в saved_real/ данные, близкие по времени к указанному числу, и только если не нашлось — проксировать запрос.
rules_*.txt	Различные правила, на данный момент их изменения учитываются только после перезапуска прокси.

Насчёт прав доступа и вообще безопасности

Для работы программы dashboard ей нужен только доступ на чтение к файлу BASE/log/dashboard и ничего другого.

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

Заключение

Ещё раз ссылка на скачивание: тут.

Надеюсь, что кому-то это всё окажется интересным и так или иначе поможет.

Поддержка прокси-серверов в приложениях Adobe Creative Cloud

Эта статья относится к Creative Cloud 2018 и более ранним версиям.

Creative Cloud расширяет функциональность приложения, предоставляя доступ к различным службам, таким как Assets, Adobe Fonts и Behance. На многих предприятиях доступ в Интернет ограничивается и контролируется прокси-сервером.

В данной статье описаны различные уровни поддержки прокси-окружений в продуктах Creative Cloud.

Adobe Asset Link не поддерживает среды прокси-серверов. Подробности приведены в документе Необходимые требования.

Требования к прокси-серверам для Creative Cloud Libraries

Для правильной синхронизации в корпоративном окружении Creative Cloud Libraries на панели Libraries в приложениях должны подключаться к локальному узлу localhost. Поэтому для обхода прокси-сервера в корпоративном окружении при использовании Libraries следует задать локальный узел localhost и адрес 127.0.0.1.

Если вы используете автоматическую настройку прокси-сервера (PAC) или протокол автоматического обнаружения прокси-сервера (WPAD) на компьютере Mac, необходимо активировать параметр Исключить простые имена хостов.

Примечание. Включение этой функции необходимо при вводе URL- или IP-адреса прокси-сервера вручную.

Подробнее о настройках прокси-сервера для Creative Cloud Libraries см. в разделах Настройка прокси-сервера для работы с библиотеками и Настройка прокси-сервера сетевым администратором.

Поддерживаемые типы настройки прокси

На компьютерах с Mac OS и Windows поддерживаются следующие конфигурации прокси-сервера:

Настройка прокси-сервера с помощью URL-адреса PAC с проверкой подлинности или без нее
Автоматическая настройка прокси (WPAD)
Обычная проверка подлинности. В случае, если пользователь указывает учетные данные в приложении Creative Cloud, Creative Cloud Libraries использует эти данные. Если пользователь не указывает учетные данные в приложении Creative Cloud, Creative Cloud Libraries запрашивает эти данные у пользователя.
Аутентификация Kerberos поддерживается для Creative Cloud Libraries и приложения Creative Cloud для настольных ПК. Однако в настоящее время аутентификация Kerberos не поддерживается для продуктов Creative Cloud.

Неподдерживаемые типы настройки прокси

Следующие конфигурации прокси-сервера не поддерживаются:

Проверки подлинности NTLM
Поддержка локальных PAC-файлов

Поддержка PAC-файлов

Приложение Creative Cloud для настольных ПК и Creative Cloud Packager поддерживают удаленные PAC-файлы с базовой аутентификацией (PAC-файлы хранятся на удаленном сервере, доступ по URL-адресу).

Приложение Creative Cloud для настольных ПК и Creative Cloud Packager не поддерживают локально сохраненные pac-файлы.

Проверки подлинности NTLM не поддерживаются.

Среда прокси-сервера с проверкой подлинности и установленным приложением Creative Cloud для настольных ПК и другими продуктами Creative Cloud

Рекомендуется использовать только прокси-серверы HTTP и HTTPS. Прокси-сервер SOCKS не поддерживается в приложении Creative Cloud для настольных ПК.

Если корпоративное окружение настроено на использование прокси-сервера с обычной проверкой подлинности, будет происходить следующее.

Если используется вся функциональность Creative Cloud, то для лицензирования программного обеспечения и использования служб пользователи входят через приложение Creative Cloud для настольных ПК. Если приложение Creative Cloud для настольных ПК запускается впервые и обнаруживает прокси-сервер, запрашиваются учетные данные.

Введите учетные данные для прокси-сервера и выберите «Сохранить». При запуске приложений Creative Cloud они запрашивают подключение к Интернету. Приложения распознают, что учетные данные уже хранятся в приложении Creative Cloud для настольных ПК, и поэтому они используют эти учетные данные.

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

Однако в следующем приложении описанная технология внедрена не полностью, поэтому при его использовании в окружении с прокси-сервером и настроенной проверкой подлинности может происходить следующее.

Muse
Пользователю неоднократно предлагается ввести учетные данные. Когда пользователь выбирает функцию сохранения, диалоговое окно с учетными данными исчезает, и при следующих запусках не появляется.

Прокси-сервер с проверкой подлинности без приложения Creative Cloud для настольных ПК

Если есть прокси-сервер с проверкой подлинности, а приложение Creative Cloud для настольных ПК не установлено, каждое приложение обрабатывает подключение через прокси-сервер, что может приводить к различным последствиям. Обычно отображается единственный запрос учетных данных для прокси-сервера. Однако иногда диалоговые окна постоянно появляются при запуске и попытках использования расширенной функциональности.

Некоторые прокси-серверы для обхода проверки подлинности заносить домены в белый список. Полный список доменов можно найти в документации по конечным точкам Creative Cloud для корпоративного использования.

Поведение в окружениях, которым не требуются службы или которые работают без подключения к сети

При полностью автономной работе приложения не могут работать полностью корректно и не запрашивают учетных данных для подключения к Интернету. Если конечные пользователи пытаются получить доступ к требующим подключения функциям, им сообщают, что они работают в автономном режиме. Если конечные пользователи пытаются получить доступ к таким службам, как библиотеки, которые необходимы приложению Creative Cloud для настольных ПК, им сообщают, что эти службы нужно установить.

Многим функциям продуктов требуется интернет-подключение. Вот некоторые из них:

Установки и запросы синхронизации настроек
Установки и запросы входа в систему (из меню «Справка» и других)
Запросы Adobe Anywhere в приложении Adobe Premiere Pro или Prelude
Установки Business Catalyst в приложении Muse
Установки Lightroom Mobile в приложении Lightroom
Активация шрифта
Установки Creative Cloud Libraries и остальные настройки Adobe CreativeSync

Синхронизируйте настройки

Функция синхронизации настроек может использоваться в среде прокси-серверов, если установлены последние версии следующих продуктов:

Dreamweaver
Premier Pro
Adobe Media Encoder
Animate

Связанные материалы

Сетевые конечные точки Adobe Creative Cloud (PDF)

Вход в учетную запись

Войти

Управление учетной записью

Прокси сервер: что это и зачем нужен

Для чего нужны прокси-серверы в эпоху VPN? И как его выбрать, чтобы защитить личные данные? РБК Тренды разбираются вместе с экспертами

В этой статье:

Что такое прокси-сервер
Для чего нужен
Как работает
Виды прокси серверов
Чем прокси отличается от VPN
Почему прокси-серверы еще актуальны

Эксперты в этой статье:

Максим Закамсков, руководитель направления IT Support компании SimbirSoft
Микаэл Караманянц, генеральный директор компании «РашенСофт»

Что такое прокси-сервер

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

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

Для чего нужен прокси-сервер

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

Отслеживание информации. Например, крупные компании могут следить за запросами работников.
Повышение скорости. За счет кэширования файлов, они загружаются быстрее.
Конфиденциальность. Прокси меняет ваш IP-адрес и местоположение, из-за чего сложно отследить, кто делает запрос.
Доступ к заблокированным сайтам. Прокси-сервер может передавать данные, что вы находитесь в другой стране, поэтому вам станут доступны заблокированные на вашей территории ресурсы.
Блокировка нежелательных сайтов. Можно настроить прокси так, что пользователь не будет получать информацию с некоторых ресурсов.

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

Алгоритмы в сети сохраняют исходящую информацию и формируют «профиль» пользователя: например, его историю запросов и типичное поведение. Эти знания можно использовать по-разному, самое безобидное — для настройки таргетированной рекламы.

При использовании прокси трафик идет не напрямую от компьютера на сервера, а через фильтр или шлюз. Именно прокси берет на себя ответственность сделать запрос на ресурс, получить информацию, при необходимости изменить ее и выдать пользователю. Как именно будет работать прокси и какие изменения он внесет во входящие или исходящие данные, зависит от его типа и настроек. Выделяют два основных прокси [1].

Прямой прокси-сервер (Forward Proxy)

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

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

Обратный прокси-сервер (Reverse proxy)

Большинство сайтов используют несколько серверов для хранения информации: обратный прокси принимает запросы пользователей и сам решает, откуда запросить информацию. Поэтому часто такие прокси используют для балансировки нагрузки. Многие пользователи даже не подозревают, что ресурс использует обратный прокси-сервер. [2]

Также прокси серверы можно разделить уровню обеспечения анонимности клиента:

Прозрачный прокси-сервер

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

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

Анонимный прокси-сервер

Такие прокси не передают реальный IP-адрес, а заменяют его. То есть невозможно определить, где вы находитесь. Это помогает предотвратить утечку личных данных и отследить типичное поведение, что усложнит жизнь маркетологам.

К примеру, искажающий прокси-сервер передает, что пользователь находится в Лагосе; соответственно, ему будут предлагать рекламу и новости этого города. А на самом деле он жует пряник в Туле и новостями Африки особо не интересуется.

С помощью такого посредника можно обходить блокировку нежелательных ресурсов. Например, многие жители Китая используют прокси или VPN, чтобы преодолеть «Великий китайский фаервол», блокирующий сайты и даже запросы в поисковых системах. [3]

Из минусов: анонимные прокси не скрывают, что запрос передается через посредника, то есть сеть видит, что человек пользуется прокси-сервером.

Искажающий прокси-сервер

Искажающий прокси-сервер автоматически меняет HTTP-заголовки и IP-адрес пользователя, то есть помогает сохранить персональные данные, местоположение, историю просмотров и при этом не сообщает сети, что запрос идет через прокси.

Прокси высокой анонимности

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

Например, компания Apple использует прокси-серверы для защиты данных пользователей с помощью функции «Частный узел», скрывая IP-адрес и шифруя трафик устройства. Для этого компания перенаправляет информацию через два независимых прокси-сервера [4].

Функция «Частный узел» не работает в России, но пользователи Apple могут воспользоваться автопрокси, который операционная система подберет из доступных, или вручную задать реквизиты прокси-сервера.

Виды прокси-серверов

Чтобы выбрать подходящий прокси-сервер, нужно понимать для чего он вам нужен и какого функционала вы ждете. Существуют десятки видов прокси: SMTP, POP3, CGI, FTP и другие. Самые популярные:

HTTP-прокси

Это наиболее распространенный вид прокси. Они окружают пользователей практически везде: от офисов до дата-центров, будучи незаменимыми сетевыми помощниками.

Главные функции HTTP-прокси:

Сжатие размера файлов (кэширование) для увеличения скорости;
Блокировка ресурсов. Например, вы устанавливаете такой прокси в школе и запрещаете посещать все не образовательные ресурсы;
Фильтрация рекламы.

HTTPS-прокси

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

Socks-прокси

Это самые прогрессивные и современные прокси-сервера. Сетевой протокол разработал Дейв Коблас в 1992 году. Сейчас используют версии Socks 4 и Socks 5. [5] Socks-прокси не передает информацию о IP-адресе, а сеть не видит, что пользователь делает запрос через прокси.

Микаэл Караманянц, генеральный директор компании «РашенСофт»:

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

HTTPS — это юрист более высокой квалификации, который старается держать все материалы дела и ваши персональные данные в секрете.

Socks-прокси — это ваш начальник безопасности, который следит за сохранностью ваших данных, скрывающий на кого он работает, выполняющий ваши приказы, выдавая их за свои».

Чем прокси отличается от VPN

Как и прокси-сервер, VPN — посредник между пользователем и сетью. Сервис изменяет IP-адрес вашего компьютера — и в этом VPN схож по функциям с большинством прокси.

Максим Закамсков, руководитель направления IT Support компании SimbirSoft:

«В случае HTTPS-прокси: соединение клиент-прокси зашифровано с помощью сертификата и ключа, которые «живут» на прокси. Современные прокси-серверы, например, Squid, могут генерировать «валидные» сертификаты «на лету». Клиент будет уверен, что обратился к сайту через зашифрованное соединение, в адресной строке браузера будет показан замочек.

Тем не менее на прокси-сервере трафик от клиента к сайту расшифровывается, просматривается, редактируется (в зависимости от настроек сервера) и далее уже прокси-сервер устанавливает соединение с сайтом, шифруя его с помощью настоящего сертификата сайта. В случае VPN происходит то же самое — на VPN-сервере зашифрованный трафик расшифровывается, просматривается и далее отправляется в место назначения».

Большинство прокси-серверов сообщают сети, что они прокси-серверы; ресурсы видят, что запрос идет через посредника, а не от локальной сети. VPN действует как виртуальная сеть; запросы, проходящие через него для большинства программ ничем не отличается от запросов обычного пользователя.

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

Для обеспечения анонимности лучше использовать именно VPN. И это оправдано, если вам нужно только скрыть свой IP-адрес. А если вы хотите настроить ограничения для ресурсов, увеличить скорость трафика или распределить нагрузку на сайт — без прокси не обойтись. Проще говоря, для прокси — обеспечение конфиденциальности — лишь одна из задач. Для VPN — единственная.

Микаэл Караманянц, генеральный директор компании «РашенСофт»:

«Если вы обычный пользователь, то для вас лучше использовать VPN, а не прокси: будет более безопасно, так как надежный прокси найти обычному пользователю крайне сложно. Если вы владелец какой-то фирмы и преследуете определенные технические задачи, то вам нужен прокси.

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

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

Риски использования прокси-сервера

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

Отдельный вопрос — доверие к владельцам прокси-серверов, ведь они видят всю информацию в незашифрованном виде, поступающую от клиентов. В 2011 году с помощью собственного прокси иранские хакеры взломали серверы Comodo и DigiNotar. Эти организации занимаются выдачей сертификатов безопасности. Кибер-преступники украли документы из ЦРУ и MI-6, а также использовали поддельные сертификаты, чтобы получить от клиентов информацию в незашифрованном виде. Это поставило под угрозу клиентов онлайн-банков и других сервисов. [6]

Использование прокси-серверов — спорная тема из-за разногласий между сетевым нейтралитетом и цензурой. [7] С одной стороны, вы обходите запреты на посещение ресурсов, которые действуют в вашей стране, а с другой — тем самым нарушаете закон.

Почему прокси-серверы еще актуальны

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

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

Максим Закамсков, руководитель направления IT Support компании SimbirSoft:

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

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

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

Микаэл Караманянц, генеральный директор компании «РашенСофт»:

«Надежный компьютер — это выключенный компьютер. Если прокси-сервер настраивали не вы лично и вы им не управляете, не работали с данным сервисом ранее, лучше использовать VPN. Бесплатными прокси точно не стоит пользоваться, если у вас какие-то серьезные задачи. Рекомендации — дело неблагодарное: то что тебе не подконтрольно, не является надежным».

Максим Закамсков, руководитель направления IT Support компании SimbirSoft:

«Я рекомендую придерживаться принципа «нулевого доверия». Лучший прокси-сервер — установленный самостоятельно.

В сети есть множество инструкций для установки и настройки: они достаточно подробны и не вызовут затруднений. Пользоваться платными или бесплатными готовыми сервисами я не рекомендую.

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

Использование перенаправляющего прокси-сервера с ArcGIS Server—ArcGIS Server

Перенаправляющий прокси-сервер представляет собой компьютер, подключенный к сети LAN, позволяющий устанавливать соединение с внешней сетью, не ставя под угрозу безопасность внутренней сети. Использование перенаправляющего прокси-сервера обычно в пределах пограничной сети (т.н. демилитаризованной зоны [DMZ] или промежуточной подсети) для защиты идентификации внутренних компьютеров. Хотя большинству сервисов ArcGIS Server не требуются подключения к внешним сетям, сервису PrintingTools или пользовательским сервисам геообработки может потребоваться доступ к внешним веб-сайтам. Если организация уже использует перенаправляющий прокси для внешних подключений, нужно настроить ArcGIS Server на работу с ним.

Откройте веб-браузер и войдите в ArcGIS Server Administrator Directory. URL-адрес имеет формат https://machine.domain.com:6443/arcgis/admin.
Щелкните Система > Свойства > Обновить.
В диалоговом окне Обновить свойства сервера введите следующий JSON код, заменив информацию о перенаправляющем прокси-сервере:
Если прокси-серверу требуется аутентификация, в строку JSON необходимо включить имя пользователя и пароль:
Щелкните Обновить свойства.

ArcGIS Server использует параметры конфигурации перенаправляющего прокси-сервера из двух источников: операционной системы, в которой установлен ArcGIS Server, и системных свойств в ArcGIS Server Administrator Directory. Рекомендуется настраивать перенаправляющий прокси-сервер в обоих местоположениях.

Чтобы настроить или просмотреть в Windows настройки перенаправляющего прокси, используемого ArcGIS Server, выполните следующие шаги:

На компьютере с ArcGIS Server выполните вход с использованием учетной записи ArcGIS Server. Это важный шаг, так как настройки перенаправляющего прокси-сервера должны применяться с использованием данной учетной записи, чтобы ArcGIS Server мог эффективно обмениваться с ним данными.
В меню Пуск выберите Панель управления > Опции Интернет > Подключения > Настройки локальной сети.
Поставьте отметку Использовать прокси-сервер для подключений к локальной сети.
Укажите адрес и номер порта вашего перенаправляющего прокси-сервера. Нажмите OK после завершения.
В меню Пуск выберите Панель управления > Учетные записи пользователей.
Щелкните Добавить общие учетные данные и затем укажите учетные данные для вашего перенаправляющего прокси-сервера. Данные настройки будут зависеть от конфигурации перенаправляющего прокси-сервера. Дополнительную информацию вы можете получить у вашего системного администратора.
Проверьте подключение к перенаправляющему прокси-серверу, открыв браузер (например, Internet Explorer) и перейдя на веб-сайт. Если подключение настроено правильно, вы сможете получить доступ к веб-сайту, если нет – вам будет предложено указать учетную запись перенаправляющего прокси-сервера перед открытием веб-сайта.
Повторите данные шаги для остальных компьютеров на вашем сайте ArcGIS Server.

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

Разместите корневой сертификат в папку, к которой у ArcGIS Server есть права на чтение.
Откройте Менеджер сертификатов. Для этого нажмите кнопку Старт и введите в окне поиска certmgr.msc, после чего нажмите клавишу Enter.
В окне Менеджер сертификатов щелкните Доверенные корневые центры сертификации и выберите Сертификаты.
В верхнем меню щелкните Действие и выберите Все задачи > Импортировать.
В диалоговом окне Мастер импорта сертификатов щелкните Далее и следуйте инструкциям мастера для импорта сертификата.
Повторите эти действия для всех компьютеров сайта ArcGIS Server.

Отзыв по этому разделу?

Настроить локальный прокси-сервер для устройств, использующих веб-прокси

Вы можете использовать локальный прокси-сервер на устройствах AWS IoT для связи с API безопасного туннелирования AWS IoT. Локальный прокси-сервер передает данные, отправленные приложением устройства, используя безопасное туннелирование. через защищенное соединение WebSocket. Локальный прокси может работать в источнике или режим назначения . В режиме источника он работает на том же устройство или сеть, которая инициирует TCP-соединение. В пункт назначения режиме локальный прокси запускается на удаленном устройстве вместе с целевым приложение. Дополнительные сведения см. в разделе Локальный прокси.

Локальный прокси-сервер должен подключаться напрямую к Интернету, чтобы использовать безопасное туннелирование AWS IoT. Для долгосрочное TCP-соединение с безопасным туннелированием, локальный прокси-сервер обновляет Запрос HTTPS для установления соединения WebSockets с одним из защищенных туннелирование конечных точек подключения устройств.

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

Примечание

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

Следующие шаги показывают, как локальный прокси работает с веб-прокси.

Локальный прокси-сервер отправляет запрос HTTP CONNECT на веб-прокси, который содержит удаленный адрес службы безопасного туннелирования вместе с веб-прокси аутентификационная информация.
Затем веб-прокси создаст долгосрочное соединение с удаленным защищенным туннелированием. конечные точки.
TCP-соединение установлено, и локальный прокси теперь будет работать как в исходном, так и в режимы назначения для передачи данных.

Чтобы завершить эту процедуру, выполните следующие шаги.

Создание локального прокси-сервера
Настройка веб-прокси
Настройка и запуск локальный прокси

Создать локальный прокси

Открыть исходный код локального прокси в репозитории GitHub и следуйте инструкциям по сборка и установка локального прокси.

Настройте свой веб-прокси

Локальный прокси использует механизм туннелирования HTTP, описанный в HTTP/1. 1. Спецификация. Чтобы соответствовать спецификациям, ваш веб-прокси должен разрешить устройствам использовать метод CONNECT .

То, как вы настраиваете свой веб-прокси, зависит от используемого вами веб-прокси и веб-прокси. версия. Чтобы убедиться, что вы правильно настроили веб-прокси, проверьте документация.

Чтобы настроить веб-прокси, сначала укажите URL-адрес веб-прокси и убедитесь, что ваш веб-прокси прокси поддерживает туннелирование HTTP. URL-адрес веб-прокси будет использоваться позже, когда вы настроить и запустить локальный прокси.

Определите URL-адрес вашего веб-прокси
URL вашего веб-прокси будет в следующем формате.
```
  протокол  ://  web_proxy_host_domain  :  web_proxy_port  
```
Безопасное туннелирование AWS IoT поддерживает только базовую аутентификацию для веб-прокси. Чтобы использовать основные аутентификации необходимо указать имя пользователя и пароль как часть URL-адреса веб-прокси. URL-адрес веб-прокси будет иметь следующий формат.
```
  протокол  ://  имя пользователя  :  пароль  @  web_proxy_host_domain  :  web_proxy_port  
```
- протокол может быть http или https . Мы рекомендуем вам использовать https .
- web_proxy_host_domain — это IP-адрес вашего веб-прокси или DNS-имя, которое разрешается в IP-адрес вашего веб-прокси.
- web_proxy_port — это порт, на котором находится веб-прокси. слушаю.
- Веб-прокси использует это имя пользователя и пароль для аутентификации запрос.
Проверьте URL-адрес вашего веб-прокси
Чтобы убедиться, что ваш веб-прокси поддерживает туннелирование TCP, используйте curl и убедитесь, что вы получили 2xx или ответ 3xx .
Например, если ваш URL-адрес веб-прокси https://server.com:1235 , используйте прокси-небезопасный флаг с завиток команда поскольку веб-прокси может полагаться на самозаверяющий сертификат.
```
 экспорт HTTPS_PROXY=https:  //server.com:1235 
curl -I https://aws.amazon.com --proxy-insecure 
```
Если ваш URL-адрес веб-прокси имеет порт http (например, http://server.com:1234 ), вам не нужно использовать прокси-небезопасный флаг .
```
 экспорт HTTPS_PROXY=http:  //server.com:1234 
завиток-I https://aws.amazon.com 
```

Настройте и запустите локальный прокси

Чтобы настроить локальный прокси для использования веб-прокси, необходимо настроить HTTPS_PROXY переменная среды с именами доменов DNS или IP-адреса и номера портов, которые использует ваш веб-прокси.

После того, как вы настроили локальный прокси-сервер, вы можете использовать локальный прокси-сервер, как описано выше. в этом README документ.

Примечание

В объявлении переменной среды учитывается регистр. Мы рекомендуем определить каждый переменная один раз, используя либо все прописные, либо все строчные буквы. Следующее примеры показывают переменную окружения, объявленную заглавными буквами. Если одна и та же переменная указывается с использованием как прописных, так и строчных букв, переменная, указанная строчными буквами, имеет приоритет.

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

Команды, показанные в следующих примерах, зависят от используемой операционной системы. и прослушивает ли веб-прокси порт HTTP или HTTPS.

Веб-прокси прослушивает HTTP-порт

Если ваш веб-прокси прослушивает HTTP-порт, вы можете указать URL-адрес или IP-адрес веб-прокси адрес для Переменная HTTPS_PROXY .

Веб-прокси прослушивает HTTPS порт

Запустите следующие команды, если ваш веб-прокси прослушивает порт HTTPS.

Примечание

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

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

Пример команды и вывода

Ниже показан пример команды, которую вы запускаете в ОС Linux, и соответствующий вывод. В примере показан веб-прокси, который прослушивает HTTP порт и как можно настроить локальный прокси-сервер для использования веб-прокси в обоих источник и режим назначения . Прежде чем вы сможете бежать эти команды, вы, должно быть, уже открыли туннель и получили клиент токены доступа для источника и назначения. Вы должны также построить локальный proxy и настройте веб-прокси, как описано ранее.

Ниже приведен обзор действий после запуска локального прокси. Локальный прокси:

Идентифицирует URL-адрес веб-прокси, чтобы он мог использовать URL-адрес для подключения к прокси-серверу. сервер.
Устанавливает TCP-соединение с веб-прокси.
Отправляет запрос HTTP CONNECT на веб-прокси и ожидает Ответ HTTP/1.1 200 , который указывает, что соединение было установлено.
Обновляет протокол HTTPS до WebSockets для установления долговременного соединения.
Начинает передачу данных через подключение к защищенному туннелирующему устройству конечные точки.

Примечание

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

Запуск локального прокси в исходном режиме

Следующие команды показывают, как запустить локальный прокси в исходном режиме.

 экспорт AWSIOT_TUNNEL_ACCESS_TOKEN=  ${access_token} 
экспорт HTTPS_PROXY=http:  имя пользователя  :  пароль  @  10.15.10.25:1234 
./localproxy -s 5555 -v 5 -r us-west-2

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

 ...
Проанализированы базовые учетные данные для URL
  В переменных среды найдена информация о веб-прокси, она будет использоваться для подключения через прокси. 
...
  Запуск прокси в исходном режиме 
Попытка установить соединение через веб-сокет с конечной точкой wss://data.tunneling.iot.us-west-2.amazonaws.com:443
Разрешенный IP-адрес веб-прокси: 10.10.0.11
  Успешное соединение с веб-прокси
HTTP CONNECT успешно отправлен на веб-прокси .
Полный ответ от веб-прокси:
  HTTP/1.1 200 Соединение установлено 
Туннель TCP успешно установлен
  Успешное подключение к прокси-серверу 
  Успешно завершено рукопожатие SSL с прокси-сервером 
Идентификатор сеанса веб-сокета: 0a109affee745f5-00001341-000b8138-cc6c878d80e8adb0-f186064b
Выбран подпротокол веб-сокета: aws. iot.securetunneling-2.0.
  Успешно установлено соединение через веб-сокет с прокси-сервером: wss://data.tunneling.iot.us-west-2.amazonaws.com:443 
Настройка пинга веб-сокета каждые 5000 миллисекунд
Запланировано следующее чтение:
...
Запуск цикла чтения веб-сокета продолжить чтение...
Разрешенный IP-адрес привязки: 127.0.0.1
Прослушивание нового соединения на порту 5555

Запуск локального прокси в режиме назначения

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

 экспорт AWSIOT_TUNNEL_ACCESS_TOKEN=  ${access_token} 
экспорт HTTPS_PROXY=http:  имя пользователя  :  пароль  @  10.15.10.25:1234 
./localproxy -d 22 -v 5 -r us-west-2

Ниже показан пример вывода запуска локального прокси-сервера в пункте назначения . режим.

 ...
Проанализированы базовые учетные данные для URL
  В переменных среды найдена информация о веб-прокси, она будет использоваться для подключения через прокси.  
...
  Запуск прокси в режиме назначения 
Попытка установить соединение через веб-сокет с конечной точкой wss://data.tunneling.iot.us-west-2.amazonaws.com:443
Разрешенный IP-адрес веб-прокси: 10.10.0.1
  Успешное соединение с веб-прокси
HTTP CONNECT успешно отправлен на веб-прокси .
Полный ответ от веб-прокси:
  HTTP/1.1 200 Соединение установлено 
Туннель TCP успешно установлен
  Успешное подключение к прокси-серверу
Успешно завершено рукопожатие SSL с прокси-сервером 
Идентификатор сеанса веб-сокета: 06717bffffed3fd05-00001355-000b8315-da3109a85da804dd-24c3d10d
Выбран подпротокол веб-сокета: aws.iot.securetunneling-2.0.
  Успешно установлено соединение через веб-сокет с прокси-сервером: wss://data.tunneling.iot.us-west-2.amazonaws.com:443 
Настройка пинга веб-сокета каждые 5000 миллисекунд
Запланировано следующее чтение:
...
Запуск цикла чтения веб-сокета продолжить чтение...

Javascript отключен или недоступен в вашем браузере.

Чтобы использовать документацию Amazon Web Services, должен быть включен Javascript. Инструкции см. на страницах справки вашего браузера.

Локальные прокси-серверы и их использование — важные сведения, которые необходимо знать в 2023 году

Локальные прокси-серверы и их использование

По мере роста Интернета он становится локализованным, и пользователи сталкиваются со многими ограничениями при доступе к контенту на определенных веб-сайтах, поскольку существуют ограничения, основанные на геолокации IP-адреса.

Некоторые веб-сайты не будут блокировать пользователей, а будут отображать только веб-контент местоположения пользователя, и они могут не иметь доступа к общему контенту. Это служит ограничением для исследователей, SEO-менеджеров и бизнес-аналитиков, которые хотят получить доступ к глобальному контенту.

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

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

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

Не стесняйтесь переходить к любым разделам, чтобы узнать о локальных прокси!

Что такое локальный прокси?

Зачем использовать локальные прокси?

Для доступа к географическому содержимому

Обход ограничения по географическому положению

Для размещения фильтра в веб-браузере

Как настроить локальный прокси-сервер?

Резидентная прокси-сеть для локальных прокси-серверов

Лучшие резидентные прокси для ваших локальных прокси:

Часто задаваемые вопросы:

Заключительные мысли:

Что такое локальный прокси?

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

Например, определенный контент на веб-сайтах США доступен только пользователям из других стран. Только пользователи в Соединенных Штатах могут получить доступ к этому контенту. Другие пользователи упускают информацию, которая может быть полезна для их бизнеса или исследований.

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

Например, прокси-сервер в США предоставляет прокси с IP-адресами этой страны. Пользователям из других стран предоставляется прокси с локальным IP-адресом, который помогает им получить доступ к информации о местоположении.

Зачем использовать локальные прокси?

Локальные прокси имеют IP-адрес, привязанный к определенному местоположению. Эти прокси скрывают ваш IP-адрес для очистки и сбора данных со всего Интернета.

Для доступа к географическому содержимому

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

Обход ограничения геолокации

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

Например, если вы хотите получить доступ к Netflix в США, вам нужен локальный IP-адрес в США. Вам нужен локальный прокси для прохождения блокировки, если вы получаете к нему доступ за пределами США.

Для размещения фильтра в веб-браузере

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

Как настроить локальный прокси-сервер?

Существуют разные поставщики прокси-серверов, и процесс настройки и доступа к локальному контенту зависит от поставщика и типа прокси-сервера. Вы должны знать правильные локальные прокси для доступа к нужному контенту.

Если вы используете резидентные прокси, некоторые провайдеры разрешают вам доступ к IP-адресам из поддерживаемых ими местоположений. Вы можете получить прокси-адрес и пару портов для нужного вам местоположения и настроить их в клиентском приложении.

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

Перед использованием прокси желательно установить прокси в браузере и проверить геолокацию через IPinfo.io. Это сервис для проверки статуса прокси и определения его местоположения. Вы должны убедиться, что местоположение, объявленное поставщиком прокси-сервера, и фактическое местоположение совпадают.

Сеть резидентных прокси-серверов для локальных прокси-серверов

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

Пользователь запрашивает подключение к целевому веб-сайту через локальный прокси-сервер. Локальный прокси-сервер назначает прокси, через который направляются все запросы к целевому веб-сайту.

Локальные прокси-серверы зависят от резидентных прокси-серверов, которые предоставляют альтернативный IP-адрес. Этот альтернативный IP-адрес принадлежит реальному устройству в сети. Запрос пользователя передается через резидентный прокси, маскирующий реальный IP-адрес.

Целевой веб-сайт понимает ваш IP-адрес из локальной сети, а не из какой-либо другой страны, и не блокирует его.

Предприятия и отдельные пользователи используют резидентные прокси-серверы, чтобы избежать ограничений на доступ к содержимому желаемого веб-сайта. Резидентный прокси-сервер имеет базу данных IP-адресов локальной сети через интернет-провайдеров (ISP). Он имеет два разных типа: статические и вращающиеся резидентные прокси.

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

Лучшие резидентные прокси для ваших локальных прокси:

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

Выделенный прокси-сервер центра обработки данных лучше всего подходит для высокоскоростных онлайн-задач, таких как потоковая передача больших объемов данных (с точки зрения размера) с различных серверов для целей анализа. Это одна из основных причин, по которой организации выбирают выделенные прокси для передачи больших объемов данных за короткий промежуток времени.

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

И последнее, но не менее важное: ProxyScrape обеспечивает отличное обслуживание клиентов и поможет вам решить вашу проблему в течение 24-48 рабочих часов.

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

Другая особенность резидентного прокси-сервера ProxyScrape — функция ротации. Ротация прокси-сервера помогает вам избежать постоянной блокировки вашей учетной записи, поскольку ваш резидентный прокси-сервер динамически меняет ваш IP-адрес, что затрудняет проверку целевым сервером того, используете ли вы прокси-сервер.

Кроме того, другие функции резидентного прокси: неограниченная пропускная способность, одновременное соединение, выделенные прокси HTTP/s, прокси в любое время сеанса из-за более чем 7 миллионов прокси в пуле прокси, аутентификация по имени пользователя и паролю для больше безопасности и, что не менее важно, возможность смены страны сервера. Вы можете выбрать желаемый сервер, добавив код страны к аутентификации имени пользователя.

Последний — премиум-прокси . Премиум-прокси аналогичны выделенным прокси-серверам центра обработки данных. Функциональность остается прежней. Главное отличие — доступность. В премиальных прокси список прокси (список, содержащий прокси) доступен каждому пользователю в сети ProxyScrape. Вот почему премиальные прокси стоят меньше, чем выделенные прокси для центров обработки данных.

Итак, что является лучшим решением для тестирования веб-сайта с использованием прокси-сервера ? Ответ будет « выделенный прокси-сервер центра обработки данных». Причина проста. Как было сказано выше, резидентный прокси-сервер является ротационным прокси-сервером, что означает, что ваш IP-адрес будет динамически изменяться в течение определенного периода времени, что может быть полезно для обмана сервера, отправляя множество запросов в течение небольшого промежутка времени, не получая блокировку IP-адреса. .

Далее, лучше всего будет изменить прокси-сервер в зависимости от страны. Вы должны добавить страну ISO_CODE в конце проверки подлинности IP или имени пользователя и пароля.

Часто задаваемые вопросы:

1.

Что такое локальные прокси?

2.

Для чего используются локальные прокси?

Существует три основных способа использования локальных прокси-серверов:
Для доступа к географическому контенту
Обход веб-фильтров
Чтобы разместить фильтры в веб-браузерах

3.

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

Если вы используете Windows, вы можете найти свой локальный прокси-адрес, выбрав Пуск→Панель управления→Настройки Интернета→Подключение к локальной сети→Локальный прокси-адрес.

Заключительные мысли

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

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

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

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

Лучшие локальные прокси-сервисы 2022 года | Доступ к локализованному контенту

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

Обзор локальных прокси -сервисов

  Жилые прокси -сети для соскоба. 15 долларов США за ГБ> — Лучший провайдер для жилых помещений на рынке 
   Smartproxy   :  40+ миллионов IP-адресов в пуле — <Начиная с 75 долларов за 5 ГБ | 15 долларов за ГБ> — самый быстрый и один из самых надежных на рынке 
   Soax   :  5+ миллионов IP-адресов в пуле — <Начиная с 75 долларов за 5 ГБ | 15 долларов за ГБ> — Чистый пул прокси 
    Частные прокси для обхода ограничений по географическому местоположению  
  Прокси-продавец   : <  Начинается с 1,80 доллара за прокси в месяц> — Поддержка хорошего местоположения
  Blazing Proxies   :  <Начиная с $2,00 за прокси в месяц> – Сверхбыстрые прокси
 Highproxies   :  <Начинается с $1,40 за прокси в месяц> — Самый доступный провайдер в списке
 Интернет становится локализованным, и, хотя это хорошо, это привело к множеству онлайновых ограничений. В настоящее время содержимое, доступ к которому вы можете получить на некоторых популярных веб-сайтах, зависит от географического положения вашего IP-адреса. Возьмем, к примеру, если вы находитесь не в США, вы не можете получить доступ к сервису Netflix в США, поскольку к нему разрешен доступ только с IP-адресов США.
 Вам также необходимо знать, что некоторые веб-сайты не будут вас блокировать, а будут отображать только веб-контент для пользователей в вашем регионе. Это не очень хорошо для многих исследователей, SEO-специалистов и любителей развлечений, и они ищут способы обойти эти ограничения и получить доступ к контенту с географической привязкой.
 Когда дело доходит до доступа к геоориентированному и локализованному контенту, использование локального прокси-сервера из поддерживаемого местоположения является одним из решений, поскольку при этом будет использоваться поддерживаемый IP-адрес. В этой статье мы бы порекомендовали некоторых из лучших поставщиков прокси, у которых вы можете купить локальные прокси.
 Это позволит вам получить доступ к Интернету, как и любой человек в мире, и ваше местоположение не станет камнем преткновения для того, что вам нужно для доступа в Интернет. Прежде чем перейти к рекомендациям, давайте посмотрим, что такое локальные прокси и зачем они вам нужны.
 Что такое локальный прокси? 
 Локальный прокси-сервер — это обычный прокси-сервер. Что делает его локальным, так это IP-адрес, привязанный к определенному местоположению, что дает ему возможность доступа к контенту в таком месте. Например, австралийский прокси-сервер с IP-адресом AU можно назвать локальным прокси-сервером для Австралии, поскольку вы можете использовать его для доступа к австралийскому геотаргетингу и локализованному контенту.
 По сути, все прокси-серверы являются локальными серверами, поскольку их IP-адреса могут быть преобразованы в определенное географическое местоположение, которое вы будете использовать для доступа к контенту, предназначенному для пользователей в этом местоположении. Однако это не означает, что вы должны использовать любые прокси, и именно поэтому мы написали эту статью, чтобы вы покупали прокси только у надежного поставщика с качественными прокси.
 Зачем использовать локальные прокси?  Хотя мы используем вышеизложенное в качестве заголовка, я думаю, что уместным вопросом является то, почему используются прокси с IP-адресами из определенного географического местоположения, поскольку локальные прокси называются так из-за их прикрепления. Что ж, в основном есть 2 причины, по которым вам следует использовать прокси с IP-адресами из определенного географического местоположения, и они будут кратко обсуждены ниже.
 Для доступа к локализованному контенту требуются локальные прокси-серверы, если вы не находитесь в поддерживаемом месте. Если вы хотите собрать данные, доступные пользователям в определенных местах, вам понадобятся прокси из таких мест. Возьмем, к примеру, парсинг локальных данных SERP, требующий использования прокси из того места, где вам нужны данные SERP; в противном случае данные SERP, которые вы получите, относятся к вашему местоположению, а не к интересующему вас местоположению. ваше местоположение.
 Если вам нужно обойти ограничения по географическому местоположению и получить доступ к контенту, к которому у вас нет доступа, вам потребуются прокси из поддерживаемого местоположения. Например, BBC iPlayer доступен только для пользователей в Великобритании — если вы находитесь за пределами Великобритании, вам потребуется IP-адрес в Великобритании, чтобы пройти блокировку.
 Лучшие резидентные прокси-сети для локальных прокси  Резидентные прокси — одни из лучших локальных прокси-серверов, поскольку они используют IP-адреса реальных пользователей Интернета и поэтому являются наиболее локализованными. Если вы хотите собирать локализованные данные из Интернета, лучше всего использовать чередующиеся резидентные прокси-серверы, поскольку они не только не обнаруживаются, но и часто меняют назначенный вам IP-адрес, что делает отслеживание IP-адресов неэффективным для них. Давайте взглянем на некоторые из лучших домашних прокси-сетей, которые вы можете использовать для парсинга веб-страниц.
 Bright Data 
  Размер IP-пула:  Более 72 миллионов
  Местонахождение:  Все страны мира
  Параллелизм разрешен:  Не ограничено
  Допустимая пропускная способность:  Начинается с 20 ГБ
  Стоимость:  От 300 долларов в месяц за 20 ГБ
 Bright Data считается лидером рынка прокси-серверов. Его резидентный прокси-сервис является одним из лучших на рынке, и вы можете использовать его для парсинга всех видов веб-сайтов. Его вращающиеся прокси-серверы лучше всего подходят для локализованного сбора данных. Одна вещь, которая вам понравится в Bright Data, — это его обширная поддержка местоположения, которая включает все страны, штаты и большинство крупных городов по всему миру.
 Это позволяет вам выбирать IP-адреса из определенной страны, штата и города — функция, известная как геотаргетинг. Помимо отличной поддержки местоположения, что делает его идеальным локальным прокси-провайдером, он имеет один из крупнейших пулов прокси на рынке с более чем 72 миллионами IP-адресов и имеет хорошую систему управления сеансами. Однако его можно считать дорогим.
 Soax 
  Размер IP-пула:  Более 5 миллионов
  Местоположения:  100+ стран
  Параллелизм разрешен:  Не ограничено
  Допустимая пропускная способность:  Начинается с 5 ГБ
  Стоимость:  От 75 долларов в месяц за 5 ГБ
 Soax гордится тем, что имеет один из самых чистых пулов прокси на рынке, поскольку он регулярно обновляет свой пул и удаляет плохие IP-адреса. Что касается поддержки местоположения, Soax имеет пул IP-адресов из более чем 100 стран мира. В настоящее время его прокси-пул насчитывает более 5 миллионов IP-адресов.
 Soax — это новый прокси-сервис по сравнению с другими прокси-сервисами премиум-класса в списке, но он так быстро вырос и зарекомендовал себя как хороший поставщик для большого количества задач, включая веб-скрапинг локализованных данных. Несмотря на то, что цены основаны на пропускной способности, такой как Bright Data, минимальные денежные обязательства для кармана составляют 75 долларов по сравнению с 300 долларами у Bright Data.
 Smartproxy 
  Размер IP-пула:  Более 40 миллионов
  Места:  195 мест по всему миру
  Параллелизм разрешен:  Не ограничено
  Допустимая пропускная способность:  Начинается с 5 ГБ
  Стоимость:  От 75 долларов в месяц за 5 ГБ
 Резидентная прокси-сеть Smartproxy зарекомендовала себя как сильный конкурент на рынке. Его скорость не имеет себе равных у других провайдеров резидентных прокси. Что касается поддержки местоположения, в списке поддерживаемых местоположений по всему миру насчитывается более 195 местоположений. Одна вещь, которая вам понравится в Smartproxy, это то, что его прокси достаточно надежны — и вы можете использовать их для большинства случаев использования прокси.
 Пока они чередуют прокси, они могут поддерживать сеансы до 10 минут, если вы выберете их липкие порты. В настоящее время размер пула прокси-серверов в сети резидентных прокси-серверов Smartproxy оценивается в 40 миллионов, что делает его одним из крупнейших на рынке. Его цены очень похожи на Soax, но кажется, что Soax скопировал их, а не наоборот.
 Прокси-служба центра обработки данных для обхода географических ограничений  Если вам заблокировали доступ к такой услуге, как онлайн-игра или развлекательный сервис, такой как Hulu или Netflix, из-за вашего местоположения, то выделенные прокси-серверы с частными прокси-серверами Лучшее для вас, поскольку чередующиеся прокси-серверы не подходят для сервисов, в которых вам нужно оставаться в системе, поскольку слишком быстрое изменение IP-адреса является подозрительным и может привести к блокировке ваших учетных записей. Ниже приведены некоторые из лучших поставщиков прокси-серверов для центров обработки данных, которые предоставят вам локальные прокси для обхода географических ограничений.
 Прокси-продавец 
  Местонахождение:  До 22 стран
  Параллелизм разрешен:  Не указано
  Разрешенная пропускная способность:  Без ограничений
  Стоимость:  $1.80 за прокси в месяц
 Служба прокси-продавца показала большинству служб центров обработки данных, что прокси-службы центров обработки данных могут поддерживаться во многих местах. У него есть частный прокси в 22 странах, что является одним из самых высоких показателей среди качественных прокси для центров обработки данных. Его поддержка местоположения охватывает Северную Америку, Европу и Азию.
 С помощью этой услуги вы можете обойти блокировку геолокации для доступа к контенту, предназначенному для пользователей за пределами вашего местоположения. Уникальность этой услуги заключается в том, что помимо обычных IP-адресов IPv4 вы можете получить более новые и более дешевые IP-адреса IPv6. Proxy-Seller вполне доступен; однако скидка предоставляется, когда вы платите за большее количество IP-адресов или за более длительный срок.
 Blazing Proxies 
  Местоположение:  24 страны
  Параллелизм разрешен:  Не ограничено
  Разрешенная пропускная способность:  Без ограничений
  Стоимость:  $2.00 за прокси в месяц
 Прокси Blazing — одни из самых быстрых выделенных прокси на рынке. Яркие выделенные прокси-серверы для центров обработки данных — это элитные прокси-серверы из 36 центров обработки данных по всему миру. У них есть поддержка IP-адресов из 24 стран мира, что делает их поддержку местоположения даже лучше, чем у Proxy-Seller.
 Вы можете использовать их прокси-серверы в качестве локальных прокси-серверов для доступа к контенту с географическим ограничением из мест, которые они поддерживают. Что вам понравится в Blazing Proxies, так это то, что его прокси достаточно эффективны для большого количества случаев использования, помимо обхода географических ограничений, включая копирование кроссовок и веб-скрейпинг среди других.
 Высокопрокси 
  Местоположение:  11 стран
  Параллелизм разрешен:  До 100 потоков
  Разрешенная пропускная способность:  Без ограничений
  Стоимость:  $1.40 за прокси в месяц
 Highproxies — еще один локальный поставщик прокси с дата-центрами в 11 странах. На рынке прокси-серверов для центров обработки данных Highproxies является одним из ведущих поставщиков прокси-серверов, которые эффективны для большого количества задач. Помимо своих обычных частных прокси, у них есть специальные прокси для особых случаев использования, такие как прокси социальных сетей и прокси классифицированных объявлений.
 Высокие прокси были созданы, чтобы быть надежными, безопасными и максимально анонимными. Одна вещь, которая вам понравится в этом сервисе, это то, что он совместим со многими популярными веб-сервисами, которые могут обнаруживать и блокировать прокси-серверы.
 Как настроить прокси-сервер для локализованного веб-доступа  Хотя выше описаны провайдеры, у которых вы можете купить локальные прокси, если вы не знаете, как использовать правильные локальные прокси, вам может быть сложно их использовать. для доступа к нужному контенту. Процесс настройки прокси для доступа к локальному контенту или данным зависит от поставщика и типа прокси.
 Если вы используете резидентные прокси, то особых проблем у вас нет. Это связано с тем, что 3 провайдера, описанные выше, позволяют вам получать доступ к IP-адресам из всех поддерживаемых мест. Все, что вам нужно сделать, это получить пару прокси-адреса и порта для определенного местоположения, которое вы хотите, и настроить его в своем клиентском приложении (браузере или боте).
 Для прокси центра обработки данных вам нужно будет выбрать местоположение в точке покупки. Если вы выберете другое местоположение, отличное от желаемого, вам нужно будет приобрести другой прокси или поговорить с клиентом.
 В принципе, независимо от типа прокси, я советую вам настроить их в своем браузере и использовать браузер для доступа к IPinfo.io, чтобы увидеть геолокацию, прежде чем использовать его, так как бывают глюки или плохой провайдер может сказать у них есть IP-адреса в местах, где их нет.
  Заключение  
 Локализованные прокси - это инструмент, который вам нужен для доступа к единовременному монотонному Интернету, который был локализован с разными пользователями, имеющими доступ к разному контенту из-за их местоположения. Хотя есть много провайдеров, которые предлагают локальные прокси, некоторые из них некачественные и только разочаруют вас и испортят ваш проект.
 Если вы ищете проверенное и надежное решение, вам следует выбрать одного из 6 провайдеров, описанных выше, так как их прокси были протестированы и оказались одними из лучших на рынке.
 Поиск настроек прокси-сервера на вашем компьютере (для параметров локального тестирования) 
 Мы используем файлы cookie для улучшения взаимодействия с пользователем, анализа использования сайта и помощи в наших маркетинговых усилиях. Продолжая просматривать
 или закрывая этот баннер, вы подтверждаете, что прочитали и согласны с нашей Политикой в отношении файлов cookie,
 Политика конфиденциальности и Условия обслуживания.
 Вы можете найти настройки прокси-сервера, применимые к вашему компьютеру, и использовать их для настройки соединений для локального тестирования.
 Введение 
 Прокси-сервер находится между вашей машиной и вашим провайдером. В большинстве организаций прокси настроены
 сетевыми администраторами для фильтрации и/или мониторинга входящего и исходящего веб-трафика с компьютеров сотрудников.
 В этой статье мы покажем вам, как посмотреть настройки прокси (если ваш компьютер находится за прокси-сервером). Затем вы можете использовать эту информацию для настройки соединений Local Testing с BrowserStack..
 Найти параметры прокси-сервера в Windows 
 В большинстве случаев браузеры будут использовать параметры прокси, установленные на компьютере. Однако в каждом браузере есть
 страницу настроек, чтобы настроить параметры прокси-сервера.
 Есть два способа найти настройки прокси в Windows: через приложение «Настройки» (только для Windows 10) или через
 Панель управления.
 Использование приложения «Настройки» (Windows 10) для поиска настроек прокси-сервера  Щелкните  Start  , затем щелкните значок шестеренки (Настройки) в крайнем левом углу.
 В меню «Параметры Windows» щелкните «Сеть и Интернет».
 На левой панели щелкните Прокси.
 Здесь находятся все настройки, связанные с настройкой прокси в Windows. Он разделен на
 две конфигурации: автоматическая или ручная настройка прокси.
 Использование сведений о конфигурации для настройки подключения для локального тестирования:  Если  «Использовать сценарий установки»  включен, это означает, что вы настроили PAC-прокси в своей системе. Ты
 можно получить путь к файлу PAC из раздела «Адрес сценария».
  Примечание:  Чтобы настроить подключение для локального тестирования с использованием PAC-файла, необходимо убедиться, что PAC-файл хранится на вашем компьютере, а путь должен быть абсолютным путем к этому файлу.
 Если включена «Ручная настройка прокси», вы можете просто получить прокси-хост и порт из «Адрес». и раздел «Порт».
 Для корректной работы Local Testing вам необходимо обойти трафик для - bs-local.com - с вашего
 прокси. Это можно сделать, добавив запись в текстовое поле  Proxy Exception  > в поле  Раздел «Ручная настройка прокси» .
 Использование панели управления (все версии Windows) для поиска настроек прокси-сервера  В любой версии Windows вы можете найти настройки прокси через Панель управления на вашем компьютере.
 Нажмите  Start  и откройте панель управления. Затем нажмите на  Параметры Интернета. 
 В  «Свойствах обозревателя»  перейдите к  «Подключения» > «Параметры локальной сети». 
 Здесь находятся все настройки, связанные с настройкой прокси в Windows. Это в основном
 разделен на две конфигурации: либо  Автоматическая конфигурация , либо  Настройка прокси-сервера .
 Использование сведений о конфигурации для настройки локального тестового соединения:  Если установлен флажок «Использовать сценарий автоматической настройки», это означает, что вы настроили прокси-сервер PAC.
 в вашей системе. Вы можете получить путь к файлу PAC из раздела «Адрес сценария».  Примечание:  Чтобы настроить подключение для локального тестирования с использованием PAC-файла, необходимо убедиться, что PAC-файл хранится на вашем компьютере, а путь должен быть абсолютным путем к этому файлу.
 Если установлен флажок «Использовать прокси-сервер для вашей локальной сети», вы можете получить прокси-хост и порт из
 Раздел «Адрес» и «Порт».
 Для корректной работы Local Testing вам необходимо обойти трафик для - bs-local.com - с вашего
 прокси. Вы можете сделать это, нажав кнопку  «Дополнительно»  и добавив запись в  «Не использовать прокси-сервер для адресов, начинающихся с:» текстовое поле .
 Поиск настроек прокси-сервера в OS X 
 В OS X вы должны просмотреть настройки прокси-сервера в  Системных настройках  . Именно здесь большинство браузеров проверяют автоматически. Однако в каждом браузере есть страница настроек для настройки параметров прокси.
 Откройте Системные настройки и нажмите  Сеть  .
 С левой стороны щелкните активное сетевое подключение. Обратите внимание, что у вас могут быть разные настройки прокси для разных сетевых подключений. Нажмите кнопку  Advanced  в правом нижнем углу.
 Перейдите на вкладку «Прокси», и вы увидите список протоколов прокси, которые вы можете настроить.
 Использование сведений о конфигурации для настройки подключения для локального тестирования:  Если установлен флажок  «Автоматическая настройка прокси» , это означает, что в вашей системе настроен прокси-сервер PAC. Вы можете получить путь к файлу PAC из раздела «Адрес сценария».
  Примечание:  Чтобы настроить подключение для локального тестирования с использованием PAC-файла, необходимо убедиться, что PAC-файл хранится на вашем компьютере, а путь должен быть абсолютным путем к этому файлу.
 Если отмечены  «Веб-прокси (HTTP)»  или  «Защищенный веб-прокси (HTTPS)» , вы можете просто получить прокси-хост, порт, имя пользователя и пароль.
 Для корректной работы Local Testing вам необходимо обойти трафик для - bs-local.com - с вашего прокси. Вы можете сделать это, добавив запись в текстовое поле  «Обход настроек прокси-сервера для этих хостов и доменов» .
 Длительность соединения и разъединение 
 В Linux поиск настроек прокси-сервера будет зависеть от того, какой дистрибутив вы используете. В основном, процедура будет одинаковой для различных дистрибутивов.
 В Ubuntu откройте  Системные настройки  из панели запуска и прокрутите вниз до  Аппаратное обеспечение  . Нажмите на  Сеть .
 Нажмите  Сетевой прокси , вы можете выбрать  Автоматический  или  Ручной .
 Использование сведений о конфигурации для настройки подключения для локального тестирования:  Если выбран вариант «Автоматически», это означает, что в вашей системе настроен прокси-сервер PAC. Вы можете получить путь к PAC-файлу из раздела «URL-адрес конфигурации».
  Примечание:  Чтобы настроить соединение для локального тестирования с использованием PAC-файла, необходимо убедиться, что PAC-файл хранится на вашем компьютере, а путь должен быть абсолютным путем к этому файлу.
 Если выбран вариант  «Вручную» , вы можете просто получить Прокси-хост и порт из соответствующего раздела.
 Для корректной работы Local Testing вам необходимо обойти трафик для - bs-local.com - с вашего прокси. Вы можете сделать это с помощью интерфейса командной строки следующим образом:
 Чтобы изменить исключения прокси-сервера, используйте опцию «set» с командой «gsettings» следующим образом.
 $ gsettings set org.gnome.system.proxy ignore-hosts "['localhost', 'bs-local.com', '::1']" 
 Если доступ к вышеперечисленным разделам на вашем компьютере ограничен, вы можете обратиться за помощью к вашей группе ИТ/сети для сбора этой информации.
 Страница прокси (диалоговое окно «Дополнительные параметры сайта») :: WinSCP 
 Документация » Конфигурация » Диалоговое окно входа в систему » Дополнительно » Соединение »
 Страница  Proxy  в диалоговом окне Advanced Site Settings позволяет настроить WinSCP для использования различных типов прокси для установления сетевых подключений.
 Обратите внимание, что в отличие от некоторых программ (таких как веб-браузеры), WinSCP не пытается автоматически определить, следует ли использовать прокси-сервер и (если да), какой из них использовать для данного места назначения. Если вам нужно использовать прокси-сервер, он всегда должен быть явно настроен.1
 При использовании туннелирования SSH параметры прокси-сервера используются для сеанса туннеля, а не для основного сеанса.
  Реклама 
 Обратитесь к документации разделов страницы:
 Установка типа прокси
 Имя пользователя и пароль
 Команда Telnet/локального прокси-сервера
 Разрешение имени при использовании прокси-сервера
 Проксирование подключений к локальному хосту
 Дополнительное чтение
  Реклама 
 Установка типа прокси 
 Сначала выберите тип прокси, который WinSCP будет использовать для своих сетевых подключений. Значение по умолчанию:  Нет  . В этом режиме для подключения не используется прокси.
 Выбор   HTTP   позволяет проксировать ваши соединения через веб-сервер, поддерживающий команду  HTTP CONNECT , как описано в разделе 9.1111 RFC  2817.
 Выбор  SOCKS4  или  SOCKS5  позволяет вам проксировать ваши соединения через сервер SOCKS.
 Многие брандмауэры реализуют менее формальный тип прокси-сервера, в котором пользователь может установить соединение Telnet или  TCP  непосредственно с машиной брандмауэра и ввести команду, например  connect myhost.com 22 , чтобы подключиться к внешнему хосту. Выбор  Telnet  позволяет указать WinSCP использовать этот тип прокси с указанием точной команды. Этот тип прокси не поддерживается для протоколов FTP, WebDAV и S3.
 Выбор  Локальный  позволяет указать произвольную команду на локальном компьютере для работы в качестве прокси. При запуске сеанса вместо создания TCP-соединения WinSCP запускает указанную команду и использует свои стандартные потоки ввода и вывода. Этот тип прокси не поддерживается для протоколов FTP, WebDAV и S3.
 Это можно использовать, например, для связи с каким-либо сетевым прокси-сервером, который WinSCP изначально не поддерживает; или вы можете туннелировать соединение через что-то другое, чем  TCP/IP  целиком.
 Для протокола FTP поддерживается набор методов подключения через  FTP-прокси . Методы различаются последовательностью команд, необходимых для указания прокси-серверу подключиться к целевому хосту. Наиболее типичный метод —  USER %user@%host  .
 Используйте кнопку  Autodetect  для автоматического определения настроек прокси. Работает только для HTTP-прокси.
 Имя пользователя и пароль 
 Вы можете ввести имя пользователя и пароль в  Имя пользователя  и  Пароль  поля, которые будут использоваться, если ваш прокси требует аутентификации.
 Если WinSCP обнаружит, что ему требуется имя пользователя или пароль прокси-сервера, а вы не указали его здесь, WinSCP запросит его в интерактивном режиме в окне терминала.
 Аутентификация полностью не поддерживается для всех форм прокси:
 Аутентификация по имени пользователя и паролю поддерживается для прокси-серверов HTTP и SOCKS5. При использовании SOCKS5 аутентификация осуществляется через  CHAP , если прокси поддерживает это, в противном случае пароль отправляется на прокси открытым текстом.
 При проксировании HTTP аутентификация выполняется с помощью «HTTP Digest», если это возможно, или «HTTP Basic». В последнем случае пароль отправляется на прокси в виде простого текста.
 SOCKS4 может использовать поле  Имя пользователя , но не поддерживает пароли.
 Вы можете указать способ включения имени пользователя и пароля в  Telnet/Local  команда прокси. 
 Если вы сделаете это и не укажете в конфигурации фактическое имя пользователя и/или пароль, WinSCP предложит их ввести в интерактивном режиме.
 Большинство методов FTP-прокси требуют аутентификации.
 Команда Telnet/локального прокси-сервера 
 Если вы используете тип прокси-сервера  Telnet , обычная команда, требуемая сервером Telnet брандмауэра, — это  connect  , за которой следует имя хоста и номер порта. Если вашему прокси нужна другая команда, вы можете ввести альтернативу в  Команда Telnet  поле.
  Реклама 
 Если вы используете тип прокси-сервера  Local , локальная команда для запуска указывается в  Local Proxy Command  .
 В этой строке вы можете использовать  \n  для представления новой строки,  \r  для представления возврата каретки,  \t  для представления символа табуляции и  \x , за которым следуют две шестнадцатеричные цифры для представления любой другой персонаж. \ используется для кодирования самого символа \.
 Кроме того, специальные строки  %host  и  %port  будут заменены именем хоста и номером порта, к которому вы хотите подключиться. Строки  %user  и  %pass  будут заменены на имя пользователя и пароль прокси (которые, если не указаны в конфигурации, будут запрошены). Чтобы получить буквальный знак %, введите  %%  .
 Если прокси-сервер Telnet запрашивает имя пользователя и пароль перед отправкой команд, вы можете использовать такую команду, как:
 %user\n%pass\nconnect %host %port\n
 
 Это отправит ваше имя пользователя и пароль в качестве первых двух строк на прокси, а затем команду для подключения к нужному хосту и порту. Обратите внимание, что если вы не включите токены  %user  или  %pass  в команду  Telnet  , то все, что указано в полях конфигурации  Имя пользователя  и  Пароль , будет игнорироваться.
 Вы можете использовать PuTTY  plink  в качестве локальной прокси-команды для реализации туннеля с двумя переходами.
 Эти параметры недоступны для протокола FTP.
 Разрешение имени при использовании прокси-сервера 
 Если вы используете прокси-сервер для доступа к частной сети, может иметь значение, выполняется ли разрешение имен  DNS  самим WinSCP (на клиентском компьютере) или выполняется прокси-сервером.
 Параметр конфигурации  Do DNS name lookup at proxy end  позволяет управлять этим. Если вы установите его на  No  , WinSCP всегда будет создавать свой собственный DNS и всегда будет передавать IP-адрес прокси-серверу. Если поставить  Да  , WinSCP всегда будет передавать имена хостов напрямую прокси-серверу, не пытаясь предварительно их найти.
 Если вы установите для этого параметра значение  Авто  (по умолчанию), WinSCP будет делать то, что считает подходящим для каждого типа прокси. Большинство типов прокси-серверов (HTTP, SOCK5, Telnet и локальные) будут иметь имена хостов, переданные им напрямую; SOCKS4 прокси не будет.
 Исходный протокол SOCKS4 не поддерживает DNS на стороне прокси. Существует расширение протокола (SOCKS4A), которое его поддерживает, но не все серверы SOCKS4 предоставляют это расширение. Если вы включили прокси-DNS, и ваш сервер SOCKS4 не может с ним справиться, возможно, поэтому.
 Если вы хотите, чтобы WinSCP не делал никаких DNS-запросов, связанных с вашим именем хоста назначения (например, потому что ваш локальный преобразователь DNS очень медленно возвращает отрицательный ответ в этой ситуации), то, а также установите для этого элемента управления значение  Да  , вам также может потребоваться отключить аутентификацию GSSAPI и обмен ключами GSSAPI в  SSH  . Это связано с тем, что установка  GSSAPI  также включает запрос DNS для имени целевого хоста, и этот запрос выполняется отдельной библиотекой GSSAPI, поэтому WinSCP не может переопределить или перенастроить его.
 Эти параметры недоступны для протокола FTP.
 Проксирование подключений к локальному хосту 
 Соединения с локальным хостом (имя хоста  localhost  и любой петлевой IP-адрес) по умолчанию не проксируются. Очень маловероятно, что такое поведение когда-либо вызовет проблемы, но если это произойдет, вы можете изменить его, включив . Рассмотрите возможность проксирования соединений с локальным хостом .1.
  Реклама 
 Этот параметр недоступен для протокола FTP.
 Дополнительное чтение 
 Узнайте больше о диалоговом окне входа в систему и диалоговом окне дополнительных настроек сайта.
 Текст является копией руководства пользователя PuTTY или вдохновлен им. Назад
 Locals Context — документация Werkzeug (2.2.x) 
 Вы можете обнаружить, что у вас есть некоторые данные во время каждого запроса, который вы хотите
для использования во всех функциях. Вместо того, чтобы передавать их в качестве аргументов между
каждой функции, вы можете получить к ним доступ как к глобальным данным. Однако,
использование глобальных переменных в веб-приложениях Python не является потокобезопасным;
разные работники могут вмешиваться в данные друг друга.
 Вместо сохранения общих данных во время запроса с использованием глобальных переменных,
вместо этого вы должны использовать контекстно-локальные переменные. Локальный контекст
определяется/импортируется глобально, но содержащиеся в нем данные специфичны для
текущий поток, асинхронная задача или гринлет. Вы случайно не получите
или перезаписать данные другого работника.
 Текущий подход к хранению контекстных данных в Python — это
 Модуль  contextvars . Контекстные переменные хранят данные для каждого потока, асинхронно
задача, или гринлет. Это заменяет старые  threading.local  который обрабатывает только потоки.
 Werkzeug предоставляет обертки вокруг  ContextVar  для
облегчить работу.
  LocalProxy  позволяет напрямую обрабатывать переменную контекста как объект
вместо необходимости использовать и проверять  ContextVar.get()  . Если контекст
var, локальный прокси будет выглядеть и вести себя как объект, для которого установлена переменная.
настроен на. Если он не установлен, в большинстве случаев возникает ошибка  RuntimeError .
операции.
 из contextvars импортировать ContextVar
из werkzeug.local импортировать LocalProxy
_request_var = ContextVar("запрос")
запрос = локальный прокси (_request_var)
из werkzeug.wrappers Запрос на импорт
@Запрос.приложение
защитное приложение (р):
    _request_var.set(r)
    check_auth()
    ...
из werkzeug.exceptions import Неавторизованный
защита check_auth():
    если request.form["имя пользователя"] != "admin":
        поднять неавторизованный ()
 
 Доступ к  запросу  укажет на конкретный запрос, который каждый
работает рабочий сервер. Вы можете лечить  запрос  как настоящий  Запрос  объекта.
  bool(proxy)  всегда будет возвращать  False , если переменная не установлена. Если
вам нужен доступ к объекту напрямую вместо прокси, вы можете получить
это с помощью метода  _get_current_object() .
  class  werkzeug.local.LocalProxy( local ,  name=None ,  * ,  unbound_message=None )
 Прокси для объекта, связанного с контекстно-локальным объектом. Все
операции на прокси перенаправляются на связанный объект. Если нет
объект привязан,  Возникла ошибка RuntimeError .
 Параметры:
  локальный  — Контекстно-локальный объект, предоставляющий проксируемый
объект.
  имя  — Проксируйте этот атрибут из проксируемого объекта.
  unbound_message  — Сообщение об ошибке, которое будет отображаться, если
контекстно-локальный объект не привязан.
 Прокси-сервер  ContextVar , чтобы упростить
доступ. Передайте имя для прокси этого атрибута.
 _request_var = ContextVar("запрос")
запрос = локальный прокси (_request_var)
сеанс = локальный прокси (_request_var, «сеанс»)
 
 Проксируйте атрибут в пространстве имен  Local , вызвав метод
локальный с именем атрибута:
 данные = локальные()
пользователь = данные ("пользователь")
 
 Проксируйте верхний элемент в  LocalStack , вызвав метод local.
Передайте имя для прокси этого атрибута.
 app_stack = Локальный стек ()
текущее_приложение = стек_приложений()
г = стек_приложений("г")
 
 Передайте функцию, чтобы проксировать возвращаемое значение этой функции. Этот
ранее использовался для доступа к атрибутам локальных объектов до
это было поддержано напрямую.
 сеанс = локальный прокси (лямбда: запрос. сеанс)
 
  __repr__  и  __class__  проксируются, поэтому  repr(x)  и  isinstance(x, cls)  будет выглядеть как проксируемый объект. Использовать  issubclass(type(x), LocalProxy)  для проверки, является ли объект
прокси.
 repr(user) # <Администратор пользователя>
isinstance(пользователь, Пользователь) # Истина
issubclass(type(user), LocalProxy) # True
 
 Изменено в версии 2.2.2:  __wrapped__  устанавливается при обертывании объекта, а не только при
обертывание функции, чтобы предотвратить сбой doctest.
 Изменено в версии 2.2: Может напрямую проксировать  ContextVar  или  LocalStack .
 Изменено в версии 2.2: Параметр  name  можно использовать с любым проксируемым объектом, не
только  Местный  .
 Изменено в версии 2.2: Добавлен параметр  unbound_message .
 Журнал изменений Изменено в версии 2.0: атрибуты и методы прокси обновлены для отражения текущих
модель данных.
 Изменено в версии 0.6.1: Класс может быть создан с помощью вызываемого объекта.
 _get_current_object  : Вызываемый [[], T] 
 Возвращает текущий объект, к которому привязан этот прокси. Если прокси
несвязанный, это поднимает  Ошибка выполнения  .
 Это следует использовать, если вам нужно передать объект чему-то, что
не понимает прокси. Это также может быть полезно для производительности
если вы обращаетесь к объекту несколько раз в функции, скорее
чем проходить через прокси несколько раз.
  ContextVar  сохраняет одно значение за раз. Вы можете
обнаружите, что вам нужно хранить стек элементов или пространство имен с
множественные атрибуты. Для них можно использовать список или словарь, но с помощью
их как значения var контекста требует особой осторожности. Werkzeug предоставляет  LocalStack , который упаковывает список, и  Local , который упаковывает
дикт.
 Существует некоторое снижение производительности, связанное с этими
объекты. Поскольку списки и словари изменяемы,  LocalStack  и  Локальный  необходимо выполнить дополнительную работу, чтобы гарантировать, что данные не
вложенные контексты. Если возможно, разработайте свое приложение для использования  LocalProxy  вокруг контекста var напрямую.
  класс  werkzeug.local.LocalStack(  context_var = нет  )
 Создать стек контекстно-локальных данных. Это обертывает  ContextVar , содержащая значение списка  .
 Это может привести к снижению производительности по сравнению с использованием отдельных
context vars, так как он должен копировать данные, чтобы избежать изменения списка
между вложенными контекстами.
 Параметры:
  context_var  (  ContextVar   [   Список   [   T   ]   ]   |   Нет  ) –  ContextVar  для использования в качестве
хранилище для этого локального. Если не задано, оно будет создано.
Контекстные переменные, не созданные в глобальной области видимости, могут мешать
вывоз мусора.
 Список изменений Изменено в версии 2. 0: вместо пользовательской реализации хранилища используется  ContextVar .
 Новое в версии 0.6.1.
 __call__(  name=None  ,  *  ,  unbound_message=None )
 Создайте  LocalProxy , который получает доступ к верхней части этого
локальный стек.
 Параметры:
  name  (  str   |   None  ) — если указано, прокси получает доступ к этому атрибуту
верхний элемент, а не сам элемент.
  unbound_message  (  str   |   None  ) — сообщение об ошибке, которое прокси-сервер
показать, если стек пуст.
 Тип возврата:
  Локальный прокси 
 поп()
 Удалите верхний элемент из стека и верните его. Если
стек пуст, вернуть  None  .
 Тип возврата:
  Т  | Нет
 толчок(  объект  )
 Добавить новый элемент в верхнюю часть стека.
 Параметры:
  обж  (  Т  ) –
 Тип возврата:
  Список  [  Т  ]
  свойство  топ  : T | Нет 
 Самый верхний элемент в стеке. Если стек пуст,  Нет Возвращается .
  класс  werkzeug.local.Local( context_var=None )
 Создайте пространство имен контекстно-локальных данных. Это обертывает  ContextVar , содержащий значение  dict .
 Это может привести к снижению производительности по сравнению с использованием отдельных
context vars, так как он должен копировать данные, чтобы избежать изменения dict
между вложенными контекстами.
 Параметры:
  context_var  (  ContextVar   [   Dict   [   str   ,   Any   ]   ]   |   Нет  ) –  ContextVar  для использования в качестве
хранилище для этого локального. Если не задано, оно будет создано.
Контекстные переменные, не созданные в глобальной области видимости, могут мешать
вывоз мусора.
 Список изменений Изменено в версии 2.0: вместо пользовательской реализации хранилища используется  ContextVar .
 __call__( имя ,  * ,  unbound_message=нет )
 Создайте  LocalProxy  для доступа к атрибуту на этом
локальное пространство имен.
 Параметры:
  name  (  str  ) — Прокси этого атрибута.
  unbound_message  (  str   |   None  ) — сообщение об ошибке, которое прокси-сервер
показать, если атрибут не установлен.
 Тип возврата:
  Локальный прокси 
 Предыдущая реализация  Local  использовала внутренние структуры данных. который не мог быть очищен автоматически, когда каждый контекст заканчивался.
Вместо этого для выпуска данных можно использовать следующие утилиты.
 Предупреждение
 В современной реализации этого не требуется, т.к.
данные в переменных контекста автоматически управляются Python. Он хранится
для совместимости на данный момент, но может быть удален в будущем.
  класс  werkzeug.local.LocalManager ( locals=Нет )
 Управление выпуском данных для текущего контекста в одном или нескольких  Локальные объекты  и  LocalStack .
 Это не требуется для современных вариантов использования и может быть удалено.
в будущем.
 Параметры:
  локальные  (  Локальные   |   LocalStack   |   Итерируемый   [   Местный   |   LocalStack   ]   |   Нет  ) — локальный или список местных жителей для управления.
 Список изменений Изменено в версии 2.0:  ident_func  устарела и будет удалена в Werkzeug
 2.1.
 Изменено в версии 0.7: Добавлен параметр  ident_func .
 Изменено в версии 0.6.1:  Функция release_local()  может использоваться вместо
менеджер.
 очистка()
 Освободите данные в локальных файлах для этого контекста. Позвоните по этому адресу
конец каждого запроса или используйте  make_middleware()  .
 Тип возврата:
 Нет
 make_middleware( приложение )
 Оберните приложение WSGI, чтобы освободить локальные данные
автоматически после отправки ответа на запрос.
 Параметры:
  приложение  ( WSGIApplication ) —
 Тип возврата:
 WSGIApplication
 ПО промежуточного слоя ( функция )
 Аналогично  make_middleware() , но используется как декоратор на
Функция приложения WSGI.
No related posts.

Локальный прокси: Локальный прокси-сервер для фильтрации браузерного трафика / Хабр

Локальный прокси-сервер для фильтрации браузерного трафика / Хабр

Черновой вариант: nginx + php-fpm

Итоговый вариант

SSL/TLS-обёртки

Основной функционал

Что получилось

Как собрать/установить и технические детали кода

Насчёт прав доступа и вообще безопасности

Заключение

Настройка параметров прокси-сервера для локального шлюза данных

Настройка параметров прокси

Смена учетной записи службы шлюза на пользователя домена

Дальнейшие действия

Локальный прокси-сервер для фильтрации браузерного трафика

Черновой вариант: nginx + php-fpm

Итоговый вариант

SSL/TLS-обёртки

Основной функционал

Что получилось

Как собрать/установить и технические детали кода

Насчёт прав доступа и вообще безопасности

Заключение

Поддержка прокси-серверов в приложениях Adobe Creative Cloud

Требования к прокси-серверам для Creative Cloud Libraries

Поддерживаемые типы настройки прокси

Неподдерживаемые типы настройки прокси

Поддержка PAC-файлов

Среда прокси-сервера с проверкой подлинности и установленным приложением Creative Cloud для настольных ПК и другими продуктами Creative Cloud

Прокси-сервер с проверкой подлинности без приложения Creative Cloud для настольных ПК

Поведение в окружениях, которым не требуются службы или которые работают без подключения к сети

Синхронизируйте настройки

Связанные материалы

Прокси сервер: что это и зачем нужен

Что такое прокси-сервер

Для чего нужен прокси-сервер

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

Прямой прокси-сервер (Forward Proxy)

Обратный прокси-сервер (Reverse proxy)

Прозрачный прокси-сервер

Анонимный прокси-сервер

Искажающий прокси-сервер

Прокси высокой анонимности

Виды прокси-серверов

HTTP-прокси

HTTPS-прокси

Socks-прокси

Чем прокси отличается от VPN

Риски использования прокси-сервера

Почему прокси-серверы еще актуальны

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

Использование перенаправляющего прокси-сервера с ArcGIS Server—ArcGIS Server

Настроить локальный прокси-сервер для устройств, использующих веб-прокси

Создать локальный прокси

Настройте свой веб-прокси

Определите URL-адрес вашего веб-прокси

Проверьте URL-адрес вашего веб-прокси

Настройте и запустите локальный прокси

Веб-прокси прослушивает HTTP-порт

Веб-прокси прослушивает HTTPS порт

Пример команды и вывода

Запуск локального прокси в исходном режиме

Запуск локального прокси в режиме назначения

Локальные прокси-серверы и их использование — важные сведения, которые необходимо знать в 2023 году

Что такое локальный прокси?

Зачем использовать локальные прокси?

Для доступа к географическому содержимому

Обход ограничения геолокации

Как настроить локальный прокси-сервер?

Сеть резидентных прокси-серверов для локальных прокси-серверов

Лучшие резидентные прокси для ваших локальных прокси:

Часто задаваемые вопросы:

1.

2.

3.

Заключительные мысли

Лучшие локальные прокси-сервисы 2022 года | Доступ к локализованному контенту

Поиск настроек прокси-сервера на вашем компьютере (для параметров локального тестирования)

Введение

Найти параметры прокси-сервера в Windows