Авторизующий прокси под Windows (+ нормальная работа Opera с NTLM как бонус)

На написание данного топика меня сподвигли следующие особенности моего жизненного пути:

• Пару лет назад я устроился на работу в достаточно крупную компанию, где познакомился с прокси в целом и прокси с авторизацией в частности и узнал о косяках Opera в такой среде
• Админы заставляют нас менять пароль в домене\на прокси достаточно часто
• Похожей статьи на Хабре не нашлось:) — надеюсь, что кому-то эта инфа будет полезна

Предыстория

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

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

Дядя Гугл рассказал мне много интересных и новых тогда для меня вещей на эту тему… и про то, как давно на это жалуются юзеры Opera, и как это элементарно чиниться установкой какого-то «лиса»:)
Кроме того я уяснил, что существует NTLM-аутентификация, и что Opera с ней не особо-то и дружит.

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

Поиски решения

Большинство рекомендаций сводилось к тому, что надо подергать флажок EnableNTLM в Opera (opera:config -> Network -> EnableNTLM).

К сожалению, в моем случае опция не принесла мне искомого единения с браузером:

• EnableNTLM=1 -> получаем по одному запросу пароля на каждую вкладку
• EnableNTLM=0 -> всего один запрос, но зато отваливаются все внутренние ресурсы, требующие доменной авторизации:

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

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

Результат и плюшки

Все уже наверняка догадались, что есть-таки достойная и более удобная замена NTLMAPS, о которой я и хочу рассказать. И имя ей — CNTLM.
Именно этот прокси я использую на работе последние несколько лет (работающие под Linux коллеги также остановили свой выбор на CNTLM). С тех прошло уже много времени… Сначала выяснилось, что у нас используется squid, ISA и что-то еще… Затем появился секретный прозрачный прокси вообще без авторизации. Но я по-прежнему использую CNTLM.

Итак, для начала я приведу плюсы CNTLM по сравнению с NTLMAPS:

• практически (боюсь писать «абсолютно») незаметное падение скорости (см. конец статьи)
• отстутствие заметной нагрузки на CPU и малое потребление памяти (см. конец статьи)
• работа в режиме службы
• возможность хранить в конфиге хэш вместо самого пароля
• возможность указать сразу несколько родительских проксей
• возможность включить режим шлюза и т.п.
• возможность задания NoProxy ресурсов (т.е. тех, для которых не надо использовать прокси вообще — e.g. локальные ресурсы)
• ...

Чем может быть полезно такое решение:

1. Opera теперь ВООБЩЕ не спрашивает логин\пароль — mission accomplished:)
2. Весь софт ходит в инет через CNTLM. Когда наступает судный день день смены пароля -достаточно поменять его лишь в конфиге CNTLM.
   Ранее мне приходилось это делать в куче мест… Возьмем для примера комп сферического айтишника в вакууме: 3 браузера, dropbox, hamachi, teamviewer, miranda, skype, DM, антивирус, kitty и т.п. + многие приложения, которым просто нужен инет для проверки обновлений.
   Кроме того, после смены пароля весь софт продолжает долбиться в инет со старым паролем, что приводит к временному бану на прокси… Я надеюсь уже понятно — мне и коллегам было не очень комфортно).
3. Как оказалось, не все современные программы умеют ходить в инет через прокси с авторизацией. CNTLM очень выручает в этой ситуации
4. Все виртуалки и нужные машины в локалке можно также пустить в инет через CNTLM (включив в конфиге режим шлюза)
5. Допустим, основной корпоративный прокси имеет привычку регулярно падать. Вбиваем в конфиг все доступные прокси и CNTLM будет сам прозрачно для нас перебирать их по списку в случае отвала основного прокси.

Это лишь перечень тех применений, которые пришли мне в голову. Уверен, что многие смогут придумать что-то еще.

Getting started

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

1. Вбиваем наши данные в %PROGRAMFILES%\Cntlm\cntlm.ini.
   
   В общем случае нас интересуют следующие параметры:
   
   Username -> наш логин на прокси или доменный логин
   Domain -> имя домена
   Proxy -> IP-адрес\имя родительского прокси + порт
   Listen -> локальный порт, на котором CNTLM будет нас ждать с распростертыми объятьями
   
   Указываем нужные данные и перезапускаем службу CNTLM.
2. Узнать детали «диалекта» корпоративного прокси и вбить пароль\хэш в нужный параметр конфига.
   
   Эту инфу можно вытянуть у админов, но можно попробовать решить этот вопрос и средствами CNTLM. Для этого запускаем CNTLM с ключами -I и -M и адресом любого внешнего сайта:
   
   cntlm.exe -I -M ya.ru
   
   , вбиваем пароль руками и видим примерно такой аутпут:
   
   Auth NTLMv2
PassNTLMv2 4AC6525378DF8C69CF6B6234532943AC
   
   Отсюда видно, что используется NTLMv2. Кроме того CNTLM сразу показывает нам хэш от введенного пароля.
   Вот мы и получили последний недостающий параметр PassNTLMv2.
   Вставляем его в конфиг CNTLM и перезапускаем службу.
   
3. Вбиваем в браузере\аське\… прокси localhost: Х, где Х — наш локальный порт, указанный в конфиге.

Ложка дегтя

Поскольку CNTLM использует Cygwin, который по дефолту сыпет события в eventlog, мы имеем бешеное количество мусора в Application-логе (по ивенту на каждый HTTP запрос — Event ID 0 Source Cygwin):

The description for Event ID 0 from source Cygwin cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
127.0.0.1 GET s.4pda.ru/forum/style_emoticons/default/thank_you.gif


C этим, конечно, можно жить, но зато найти что-то реально полезное в логе достаточно сложно.
Если кто-то подскажет элегантное решение — буду благодарен.
Единственное, что пока пришло мне в голову — убрать в исходниках все вызовы syslog().

P.S.

Привожу обещанное выше сравнение перформанса с NTLMAPS (эти данные ранее были указаны на сайте CNTLM, но недавно были убраны).

Рис. 1. Проверяем время выполнения запроса wget-ом. Обращаем внимание, что время 1го и последующего запроса при использовании NTLMAPS практически одинаково (~2 сек). В случае с CNTLM — 1ый запрос выполняется в 5 раз быстрее, последующий — уже в 15 раз — налицо кэширование соединений.


Рис.2. Смотрим потребление CPU и RAM при 50 параллельных соединениях.