Поделиться через

Поддержка прокси-сервера в Microsoft Edge

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

Содержимое

Идентификаторы прокси-сервера

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

Этот идентификатор можно записать в виде строки, используя либо формат PAC, либо формат URI.

Формат PAC — это имя прокси-сервера в скриптах автонастройки прокси-сервера . Пример

PROXY foo:2138 SOCKS5 foo:1080 DIRECT

Вместо этого "формат URI" кодирует сведения в виде URL-адреса. Пример

foo:2138 http://foo:2138 socks5://foo:1080 direct://

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

Дополнительные сведения о том, какие схемы поддерживает Edge и как записывать их в форматах PAC и URI, см. в разделе Схемы прокси-сервера.

Большинство поверхностей пользовательского интерфейса в Edge (включая командные строки и политику) ожидают идентификаторы прокси-сервера в формате URI. Однако за пределами Edge прокси-серверы определяются менее точно при использовании только адреса . Схема прокси-сервера предполагается на основе контекста.

В параметрах прокси-сервера Windows есть поля узла и порта для прокси-сервера HTTP, Secure, FTP и SOCKS. За исключением "SOCKS", все они являются идентификаторами для небезопасных прокси-серверов HTTP (схема прокси-сервера предполагается как HTTP).

Разрешение прокси-сервера

Прокси-сервер в Edge выполняется на уровне URL-адреса.

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

Это называется разрешением прокси-сервера. Входными данными для разрешения прокси-сервера является URL-адрес, а выходными данными является упорядоченный список идентификаторов прокси-сервера.

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

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

Скрипт PAC — разрешение прокси-сервера определяется с помощью программы JavaScript, которая вызывается при каждом получении URL-адреса для получения списка используемых идентификаторов прокси-сервера.

Автоматическое определение— протокол WPAD используется для проверки сети (с помощью DHCP/DNS) и, возможно, обнаружения URL-адреса скрипта PAC.

Схемы прокси-сервера

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

Осуществляется ли связь с прокси-сервером по безопасному каналу? Разрешение имен (например, DNS) выполнено на стороне клиента или на стороне прокси-сервера? Какие схемы проверки подлинности для прокси-сервера поддерживаются? Какой сетевой трафик можно отправлять через прокси-сервер? Edge поддерживает следующие схемы прокси-сервера:

Схема прокси-сервера DIRECT

Порт по умолчанию: N/A (ни узел, ни порт не применимы) Пример идентификатора (PAC): DIRECT пример идентификатора (URI). direct:// Это схема псевдо-прокси, которая указывает, что вместо использования прокси-сервера мы отправим запрос непосредственно на целевой сервер.

Это некорректно называть его прокси-сервером, но это удобная абстракция.

Схема прокси-сервера HTTP

Порт по умолчанию: 80 Пример идентификатора (PAC): PROXY proxy:8080, proxy (нестандартный; не используйте) Примеры идентификаторов (URI): http://proxy:8080, proxy:8080 (может опустить схему). Обычно при ссылке на "прокси-сервер" или "веб-прокси" речь идет о прокси-сервере HTTP.

При использовании прокси-сервера HTTP в Edge разрешение имен всегда откладывается на прокси-сервер. Прокси-серверы HTTP могут прокси-адреса http://, https://ws:// и wss:// .

Связь с прокси-серверами HTTP небезопасна, то есть запросы прокси http:// отправляются в формате clear. При передаче https:// запросов через прокси-сервер HTTP обмен TLS перенаправляется через прокси-сервер с помощью метода CONNECT, поэтому сквозное шифрование не нарушается. Однако при установке туннеля имя узла целевого URL-адреса отправляется на прокси-сервер в формате clear.

Прокси-серверы HTTP в Edge поддерживают те же схемы проверки подлинности HTTP, что и для целевых серверов: Basic, Digest, Negotiate, NTLM.

Схема прокси-сервера HTTPS

Порт по умолчанию: 443. Пример идентификатора (PAC): HTTPS proxy:8080 пример идентификатора (URI): https://proxy:8080

Это работает как прокси-сервер HTTP, за исключением того, что связь с прокси-сервером защищена протоколом TLS и может согласовать протокол HTTP/2 (но не QUIC).

Так как подключение к прокси-серверу является безопасным, запросы, https:// отправленные через прокси-сервер, не отправляются в формате clear, как с прокси-сервером HTTP. Аналогичным образом, так как запросы CONNECT отправляются по защищенному каналу, имена узлов для ПРОКСИ-адресов https:// также не отображаются.

Помимо обычных методов проверки подлинности HTTP прокси-серверы HTTPS также поддерживают сертификаты клиентов.

Прокси-серверы HTTPS, использующие HTTP/2, могут обеспечить более высокую производительность в Edge, чем обычный прокси-сервер HTTP из-за более высоких ограничений на подключение (прокси-серверы HTTP/1.1 в Edge ограничены 32 одновременными подключениями во всех доменах).

Edge, Firefox и Opera поддерживают прокси-серверы HTTPS; однако большинство старых стеков HTTP не используют.

Указание прокси-сервера HTTPS невозможно с помощью параметров системного прокси-сервера. Вместо этого необходимо использовать скрипт PAC или параметр прокси-сервера Edge (командная строка, расширение или политика).

Схема прокси-сервера SOCKSv4

Порт по умолчанию: 1080 Примеры идентификаторов (PAC): SOCKS4 proxy:8080, SOCKS proxy:8080 пример идентификатора (URI): socks4://proxy:8080 SOCKSv4 — это простой прокси-сервер транспортного уровня, который упаковывает сокет TCP. Его использование прозрачно для остальной части стека протоколов; После первоначального подтверждения при подключении сокета TCP (к прокси-серверу) остальная часть стека загрузки остается неизменной.

Методы проверки подлинности прокси-сервера для SOCKSv4 не поддерживаются.

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

Существуют расширения для SOCKSv4, которые позволяют разрешать имена сторон прокси и IPv6, а именно SOCKSv4a. Однако Edge не разрешает настройку или возврат к версии 4a.

Лучшая альтернатива — использовать более новую версию протокола, SOCKSv5 (которая по-прежнему 20+ лет).

Схема прокси-сервера SOCKSv5

Порт по умолчанию: 1080 Пример идентификатора (PAC): SOCKS5 proxy:8080 пример идентификаторов (URI): socks://proxy:8080, socks5://proxy:8080

SOCKSv5 — это прокси-сервер транспортного уровня, который упаковывает сокет TCP и позволяет отложить разрешение имен на прокси-сервер.

В Edge, когда для схемы прокси-сервера задано значение SOCKSv5, разрешение имен всегда выполняется на стороне прокси-сервера (даже если протокол также допускает использование клиентской стороны). В Firefox на стороне клиента и прокси-сервера разрешение имен можно настроить с network.proxy.socks_remote_dnsпомощью ; Edge не имеет эквивалентного параметра и всегда будет использовать разрешение прокси-сервера на стороне.

Методы проверки подлинности для SOCKSv5 в Edge не поддерживаются (хотя некоторые из них существуют для протокола).

Удобно создать прокси-сервер SOCKSv5 с ssh -Dпомощью , который можно использовать для туннелирования веб-трафика к удаленному узлу по протоколу SSH.

В Edge SOCKSv5 используется только для прокси-запросов URL-адресов на основе TCP. Его нельзя использовать для ретрансляции трафика UDP.

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

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

Сопоставление схем URL-адресов с идентификаторами прокси-сервера Список правил обхода прокси-сервера. Этот режим конфигурации называется "параметрами прокси-сервера вручную".

Параметры прокси-сервера вручную могут кратко описывать настройки, например:

Использовать прокси-сервер http://foo:8080 для всех запросов. Использование прокси-сервера http://foo:8080 для всех запросов, кроме запросов к поддомену contoso.com Используйте прокси-сервер http://foo:8080 для всех https:// запросов и прокси-сервер socks5://mysocks:90 для всех остальных. Хотя параметры прокси-сервера вручную являются повсеместным способом настройки прокси-серверов на разных платформах, стандартное представление или набор функций отсутствует.

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

При определении параметров прокси-сервера вручную в Edge мы указываем три (возможно, пустых) списка идентификаторов прокси-сервера:

прокси-серверы для HTTP — список идентификаторов прокси-сервера, используемых для http:// запросов, если прокси-серверы не являются прокси-серверами для HTTPS. Список идентификаторов прокси-сервера, используемых для https:// запросов, если непустые другие прокси-серверы. Список идентификаторов прокси-сервера для всех остальных (не совпадает с двумя другими списками). Существует много способов получить параметры прокси-сервера вручную в Пограничных серверах (обсуждается в других разделах).

В следующих примерах используется метод командной строки. Запуск Edge с --proxy-server=XXX помощью (и при --proxy-bypass-list=YYYнеобходимости )

Пример. Чтобы использовать прокси-сервер http://foo:8080 для всех запросов, можно запустить Edge с --proxy-server="http://foo:8080"помощью . Это означает:

Прокси-серверы для HTTP — пустые прокси-серверы для HTTPS — пустые другие прокси-серверы — http://foo:8080 при указанной выше конфигурации, если прокси-сервер недоступен, все запросы завершатся сбоем с ERR_PROXY_CONNECTION_FAILED. Чтобы устранить эту проблему, можно добавить резервную строку в DIRECT, запустив с помощью --proxy-server="http://foo:8080,direct://" (обратите внимание на список, разделенный запятыми). Эта командная строка означает:

Прокси-серверы для HTTP — пустые прокси-серверы для HTTPS — пустые другие прокси-серверы . http://foo:8080direct:// Если вместо этого мы хотели проксировать только http:// URL-адреса через прокси-сервер https://foo:443HTTPS, а все остальные используют прокси-сервер socks5://mysocks:1080 SOCKSv5, мы могли бы запустить Edge с --proxy-server="http=https://foo:443;socks=socks5://mysocks:1080"помощью . Теперь он расширяется до:

прокси-серверы для HTTP — https://foo:443 прокси-серверы для HTTPS — пустые другие прокси-серверы. socks5://mysocks:1080 В командной строке выше используется формат карты прокси-сервера WinInet с некоторыми дополнительными функциями:

Вместо именования прокси-серверов с помощью , hostname:portможно использовать формат URI Edge для идентификаторов прокси-сервера. Другими словами, можно префиксировать схему прокси-сервера, чтобы она по умолчанию не была http. Сопоставление socks= понимается более широко как "другие прокси-серверы". Последующий список прокси-серверов может включать прокси-серверы любой схемы, однако если схема опущена, она будет рассматриваться как SOCKSv4, а не HTTP.

Сопоставление URL-адресов WebSocket с прокси-сервером

В параметрах прокси-сервера вручную нет сопоставлений или ws://wss:// URL-адресов.

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

Если "другие прокси- серверы" не является бесполезным, используйте его. Если "прокси-серверы для HTTPS" является непустым используйте его. В противном случае используйте "прокси-серверы для HTTP". Это соответствует рекомендации, описанной в разделе 4.1.3 документа RFC 6455.

Можно маршрутизировать ws:// и wss:// отдельно с помощью скрипта PAC.

Учетные данные прокси-сервера в параметрах прокси-сервера вручную

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

Проверка подлинности прокси-сервера будет проходить через обычный поток для поиска учетных данных.

Правила обхода прокси-сервера

Помимо указания трех списков идентификаторов прокси-сервера, параметры прокси-сервера Edge вручную позволяют указать список "правил обхода прокси-сервера" с помощью шаблонов URL-адресов.

Этот набор правил определяет, следует ли по заданному URL-адресу пропускать использование прокси-сервера вместе, даже если для него определен прокси-сервер.

Эта концепция также известна под такими именами, как "список исключений", "список исключений" или "список без прокси-серверов".

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

Если параметры прокси-сервера вручную указываются из командной строки, --proxy-bypass-list="RULES" можно использовать параметр , где RULES — это список правил обхода с запятой или разделенный запятыми.

Шаблоны URL-адресов конфигурации прокси-сервера см. в разделе шаблоны URL-адресов, поддерживаемые Edge для правил обхода прокси-сервера.

При использовании параметров системного прокси-сервера следует использовать формат правила платформы, а не формат edge.

Шаблоны URL-адресов конфигурации прокси-сервера

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

Шаблоны URL-адресов конфигурации прокси-сервера: имя узла

[ URL_SCHEME "://" ] HOSTNAME_PATTERN [ ":" <port> ]

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

Примеры:

foobar.com — соответствует URL-адресу любой схемы и порта, для которого нормализованный узел — foobar.com*foobar.com Соответствует URL-адресу любой схемы и портам, для которого нормализованный узел заканчивается foobar.com (например blahfoobar.com , и foo.foobar.com) *.org:443 — соответствует URL-адресам любой схемы, используя порт 443, и домен верхнего уровня которого — .orghttps://x.*.y.com:99 соответствует https:// URL-адресам на порте 99, для которого соответствует нормализованное имя узла. x.*.y.com

Шаблоны URL-адресов конфигурации прокси-сервера: поддомен

[ URL_SCHEME "://" ] "." HOSTNAME_SUFFIX_PATTERN [ ":" PORT ]

Шаблоны имени узла, начинающиеся с точки, имеют специальный регистр, чтобы означать соответствие поддомена. .foo.com фактически является еще одним способом написания *.foo.com.

Примеры:

.contoso.com — соответствует outlook.contoso.com и foo.bar.contoso.com, но не contoso.comhttp://.contoso.com — соответствует только http:// URL-адресам, которые являются поддоменом contoso.com

Шаблоны URL-адресов конфигурации прокси-сервера: IP-литералы

[ SCHEME "://" ] IP_LITERAL [ ":" PORT ]

Соответствует URL-адресам, которые являются литералами IP-адресов, а также дополнительным ограничениям схемы и порта. Это особый случай сопоставления имен узлов, в котором учитывается канонизация IP-литерала. Например, правила [0:0:0::1] и эквивалентны (оба представляют один IPv6-адрес [::1] ).

Примеры:

127.0.0.1 http://127.0.0.1 [::1] — сопоставляет любой URL-адрес с адресом [0:0::1] замыкания на себя IPv6 — то же, что и выше http://[::1]:99 , — соответствует любому http:// URL-адресу замыкания на цикл IPv6 через порт 99.

Шаблоны URL-адресов конфигурации прокси-сервера: диапазон адресов IPv4

IPV4_LITERAL "/" PREFIX_LENGTH_IN_BITS

Соответствует любому URL-адресу, имя узла которого является литералом IPv4, и находится между заданным диапазоном адресов.

Обратите внимание, что это относится только к URL-адресам, которые являются IP-литералами.

Примеры:

192.168.1.1/16

Шаблоны URL-адресов конфигурации прокси-сервера: диапазон адресов IPv6

IPV6_LITERAL "/" PREFIX_LENGTH_IN_BITS

Соответствует любому URL-адресу, который является литералом IPv6, который находится между заданным диапазоном. Литералы IPv6 не должны быть заключены в квадратные скобки.

Обратите внимание, что это относится только к URL-адресам, которые являются IP-литералами.

Примеры:

fefe:13::abc/33 [fefe::]/40 --НЕПРАВИЛЬНО! Литералы IPv6 не должны быть заключены в квадратные скобки

Шаблоны URL-адресов конфигурации прокси-сервера: простые имена узлов

<local>

Соответствует именам узлов без точки в них и не являются IP-литералами. Это наивный строковый поиск, то есть точки, отображаемые в любом месте (включая конечные точки!).

Это правило соответствует флажку "Исключить простые имена узлов" в macOS и "Не использовать прокси-сервер для локальных адресов (интрасети) " в Windows.

Имя правила происходит от WinInet, и его можно легко спутать с понятием localhost. Однако эти два понятия являются ортогональными. На практике не следует добавлять правила для обхода localhost, так как это уже делается неявно.

Шаблоны URL-адресов конфигурации прокси-сервера: вычитание неявных правил

<-loopback>

Вычитает неявные правила обхода прокси-сервера (локальные адреса localhost и link). Это необходимо только для тестовых настроек. Остерегайтесь последствий для безопасности при прокси-сервере localhost.

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

Порядок может иметь значение при использовании правила subtractive, так как правила будут оцениваться слева направо. <-loopback>;127.0.0.1 имеет эффект, который немного отличается от 127.0.0.1;<-loopback>.

Значение правил обхода диапазона IP-адресов

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

Пример.

Предположим, мы настроили прокси-сервер для всех запросов, но добавили правило обхода для 192.168.0.0.1/16. Если мы перейдем к http://foo (который разрешается в нашей настройке 192.168.1.5 ), браузер подключается напрямую (обход прокси-сервера), так как мы указали правило обхода, включающее этот IP-адрес?

Он проходит через прокси-сервер.

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

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

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

Правила неявного обхода

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

Мы называем эти неявные правила обхода. Правила неявного обхода соответствуют URL-адресам, частью узла которых является имя localhost или литерал локального IP-адреса канала. По сути, он соответствует:

localhost *.localhost [::1] 127.0.0.1/8 169.254/16 [FE80::]/10 Полные правила немного сложнее. Например, в Windows мы также распознаем loopback.

Эта концепция правил неявного обхода прокси-сервера согласуется с поддержкой прокси-сервера на уровне платформы в Windows и macOS (хотя и с некоторыми различиями из-за их реализации причуд . См. заметки о совместимости в net::ProxyHostMatchingRules::MatchesImplicitRules).

Зачем в первую очередь применять неявные правила обхода прокси-сервера? Конечно, есть соображения по эргономике и ожиданиям пользователей, но большая проблема заключается в безопасности. Так как веб-платформа рассматривает localhost как безопасный источник, возможность прокси-сервера предоставляет дополнительные полномочия. Это особенно проблематично, когда параметры прокси-сервера управляются извне, например при использовании скриптов PAC.

Переопределение правил неявного обхода

Если вы хотите, чтобы трафик на localhost отправлялся через прокси-сервер, несмотря на проблемы безопасности, это можно сделать, добавив специальное правило <-loopback>обхода прокси-сервера . Это правило вычитает неявные правила.

Например, запустите Edge с флагом командной строки:

--proxy-bypass-list="<-loopback>"

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

Лицензия на содержимое

Примечание.

Некоторые части этой страницы представляют собой измененные материалы, созданные и предоставленные на сайте Chromium.org. Их использование регулируется условиями, описанными в лицензии Creative Commons Attribution 4.0 International License. Исходная страница Chromium находится здесь.

Creative Commons License
Эта работа предоставляется в рамках международной лицензии Creative Commons Attribution 4.0 International License.

  • Last updated on