Авторизация прокси по IP или по логину: когда что включать

Как это выглядит со стороны прокси

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

# Авторизация логином: креды в строке подключения
curl -sI -x http://ЛОГИН:ПАРОЛЬ@ШЛЮЗ:ПОРТ https://example.com | head -1

# Авторизация по IP: та же строка без логина и пароля.
# Работает, только если адрес этой машины добавлен в whitelist.
curl -sI -x http://ШЛЮЗ:ПОРТ https://example.com | head -1

# Какой у машины внешний адрес — его и добавлять в whitelist
curl -s https://op-proxy.com/api/check

Когда whitelist — единственный выход

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

• Софт с полями только под адрес и порт.
• Puppeteer и другие обёртки над Chromium, где креды приходится передавать отдельным вызовом.
• Запуск по расписанию, где не хочется держать пароль в конфиге или в переменных окружения.

Когда надёжнее логин

Ровно в обратной ситуации: когда адрес машины непостоянен. Домашний и мобильный интернет почти всегда выдаёт динамический IP — при переподключении он меняется, whitelist перестаёт совпадать, и прокси отвечает так, будто пароль неверный.

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

Обе схемы одновременно — рабочая конфигурация

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

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

Риски whitelist, о которых стоит знать

• Адрес сменился — доступ пропал, и симптом выглядит как неверный пароль.
• За одним внешним адресом может сидеть весь офис: разрешив его, вы разрешаете подключение любому, кто в этой сети.
• Слотов whitelist ограниченное число, и на десяток машин их может не хватить.

Диагностика: какая схема на самом деле сработала

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

# Какой адрес прокси видит с вашей стороны — его и вносить в whitelist.
# Внешний адрес машины и адрес в её сетевых настройках почти всегда разные.
curl -s https://op-proxy.com/api/check

# Проверка обеих схем по очереди на одном и том же прокси:
curl -sI -x http://ЛОГИН:ПАРОЛЬ@ШЛЮЗ:ПОРТ https://example.com | head -1  # по логину
curl -sI -x http://ШЛЮЗ:ПОРТ              https://example.com | head -1  # по whitelist

# Первая прошла, вторая нет -> адрес не в списке.
# Вторая прошла, первая нет -> неверная пара логин-пароль.

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

Что видит целевой сайт

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

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

• Работаете по https — заголовки, выдающие прокси, добавить физически некуда.
• Работаете по http — проверьте, что реально доходит до сервера, эхо-эндпоинтом.
• Обещания «элитных» прокси для HTTPS-задач описывают свойство, которое там ни на что не влияет.