ProxyCompass Knowledge Base

Аутентификация прокси: доступ по IP или по логину и паролю?

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

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

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

Как работают два способа аутентификации

Аутентификация по IP: разрешение для источника подключения

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

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

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

Логин и пароль: данные доступа передаёт программа

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

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

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

Сравнение аутентификации по IP и по логину и паролю

В таблице сравниваются два самостоятельных способа. Доступ по паролю здесь не требует дополнительной IP-привязки; комбинированный режим рассмотрен ниже.

Ни один способ не определяет количество выходных IP в услуге. Один разрешённый клиентский IP или одна пара реквизитов могут давать доступ ко многим прокси. Ни то ни другое не делает число соединений безлимитным и не выделяет выходные адреса в исключительное пользование одному клиенту.

Как выбрать способ для своей программы и сети

Сначала проверьте, умеет ли программа использовать предлагаемый способ

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

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

Поэтому перед покупкой стоит проверить конкретное сочетание: работает ли эта программа с этим протоколом прокси и этим способом аутентификации? Успешное подключение в другом браузере или инструменте командной строки на этот вопрос не отвечает.

Затем определите, что обычно меняется в вашей работе

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

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

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

Если подходят оба способа, сравните обслуживание

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

Учитывайте дополнительные ресурсы, которых потребует выбранный способ. Постоянный публичный IP, дополнительные записи whitelist или обслуживаемый вами шлюз могут стоить денег. Доступ по паролю способен избавить от этих расходов, но только если он работает из нужных сетей. Сравнивайте реальные условия услуг: само наличие пароля не делает прокси дешевле.

Комбинированная аутентификация: IP и пароль

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

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

В статических пакетах ProxyCompass комбинированный режим принимает правильные реквизиты с публичных клиентских IPv4 из той же подсети /24, что и IP в whitelist. У таких адресов совпадают первые три числа. Поэтому несколько клиентских адресов этой подсети могут использовать реквизиты через одну запись whitelist. Правило относится к источникам подключения к сервису, а не к купленным выходным IP. Примеры подключений разобраны в статье о логине и пароле, ссылка на которую приведена выше.

Какой способ лучше контролирует доступ

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

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

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

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

Делает ли аутентификация по IP прокси быстрее

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

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

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

Можно ли распознать прокси по запросу аутентификации

Да. Пароль может запрещать постороннему пользоваться прокси и при этом не мешать распознать сам сервис. Например, проверяющая система обращается к адресу и порту HTTP-прокси без действующих реквизитов. Ответ 407 Proxy Authentication Required с заголовком Proxy-Authenticate прямо сообщает о требовании аутентификации на прокси. Чтобы получить этот признак, проверяющей системе не нужно знать пароль.

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

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

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