Эта статья появилась в связи с тем, что в работе рассмотренной мной системе распределения трафика оказалось несколько проблем, которые связаны с прокси-сервером. И не только с ним. Но опишу по порядку.
Итак начну с того, что когда я пришёл на новую работу, то решил настроить свой роутер (система распределения трафика — я привык её называть просто роутером) не на i686 системе, а на x86_64. При этом я думал, что от проблем с прокси-сервером, которые я буду описывать ниже, мне помогут избавиться более свежие пакеты таких программ, как samba и squid. И тут можно было пойти двумя путями: либо всё настраивать на более свежей версии федоры, либо настраивать, как и раньше, не 13-ке, но отдельные, более свежие, пакеты пересобрать вручную. Я решил пойти вторым путём, поскольку на тринашке у меня подобная настройка уже от зубов отскакивала, а пересобрать более свежий пакет из src.rpm-ки проще, чем разгребать возможные подводные камни при настройке всего этого изобилия на более свежей федорихе...
Забегая вперёд, сразу скажу, что ни этот второй способ не решил моих проблем, ни первый способ тоже не решил бы моих проблем. Но поскольку работа по второму способу проделана успешно, то грех будет не законспектировать её здесь. Тем более, что помимо более свежих пакетов, я свой роутер дополнил ещё кое-какими фишками. Одна из них — это кэширующий DNS-сервер, который помог не только снизить нагрузку на интернет канал, но и развязал руки ещё кое в чём.
Итак, DNS-сервер BIND (или ещё он имеет название Named), установка:
yum -y install bind bind-utils
после которой надо не забыть про одну тонкость (по крайней мере в федоре она есть): надо сразу дать доступ на каталог /var/named для пользователя и группы named:
chown -R named:named /var/named
Далее, видим, что в каталоге /etc появился конфигурационный файл /etc/named.conf, который я привёл вот к такому виду (отредактированные и добавленные строчки выделил зелёным):
options {
listen-on port 53 { 127.0.0.1; 172.16.1.100; };
// тут я указал, на каких адресах будет доступен мой dns-сервер
// listen-on-v6 port 53 { ::1; };
// IPv6 закомментировал, ибо у меня только IPv4
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; 172.16.0.0/23; };
// принимать обычные запросы можно только с самого себя и из локалки
forwarders { 8.8.8.8; 8.8.4.4; };
// Перенаправлять запросы, которые не может обработать сам, на публичные гугловские серверы
recursion yes;
allow-recursion { localhost; 172.16.0.0/23; };
// принимать рекурсивные запросы только от самого себя и из локалки
// dnssec-enable yes;
// dnssec-validation yes;
// dnssec-lookaside auto;
// закомментировал за ненадобностью этого мне.
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "server.ru" {
type master;
file "server.ru";
// Полезная фишка, суть которой в следующем: есть у нас один сервак, который в локалке доступен
// под именем serv.mydomain.domain (или просто serv), а извне он доступен по адресу server.ru.
// Люди на него заходят через вэб-интерфейс и поэтому всё время путаются, по какому адресу
// заходить. Данная настройка избавляет от этой проблемы, делая доступным этот сервер по имени
// server.ru как из-вне, так и из локалки. Иными словами, для своего DNS-сервера я сделал свою
// DNS-зону для хоста server.ru. Её содержание я приведу чуть ниже.
zone "_msdcs.mydomain.domain" {
type slave;
file "_msdcs.mydomain.domain";
masters { 172.16.0.107;
172.16.0.108; };
};
zone "mydomain.domain" {
type slave;
file "mydomain.domain";
masters { 172.16.0.107;
172.16.0.108; };
};
// Ещё одна очень полезная фишка — здесь я настроил, чтоб мой роутер был также и вторичным
// уполномоченный DNS-сервером для домена Active directory. Это ему позволит не перенаправлять
// dns-запросы о локальных компах на контроллер домена, а обрабатывать их самостоятельно.
include "/etc/named.rfc1912.zones";
А вот содержание dns-зоны для хоста server.ru (надо сказать, что этот файл должен лежать в каталоге /var/named):
$TTL 3600
$ORIGIN ru.
server 3600 IN SOA router.mydomain.domain. me.mymail.ru. (
2012121200 ; serial
14400 ; refresh
3600 ; retry
2592000 ; expire
600 ; minimum ttl
)
$ORIGIN server.ru.
@ NS router.mydomain.domain.
A 172.16.0.103
Надо заметить, что в этом же каталоге будут лежать и файлы с зонами _msdcs.mydomain.domain и mydomain.domain, которые named скопирует с контроллеров домена.
Когда привели конфиги в порядок, запускаем наш bind (и ставим его в автозагрузку):
service named start
chkconfig named on
А в файле /etc/resolv.conf указываем, чтоб роутер использовал dns-сервером сам себя:
nameserver 127.0.0.1
И это ещё не всё. На контроллерах домена нужно не забыть сделать следующее:
1. в свойствах DNS-сервера указать сервером пересылки наш роутер.
И:
2. в свойствах зон _msdcs.mydomain.domain и mydomain.domain разрешить передачу зоны на наш роутер.
Вот теперь двигаемся далее. А далее, я поставил более свежий пакет samba, который взял из Fedora 15 и пересобрал для Fedora 13. Делается это просто. Сначала надо скачать src.rpm-ку из репозиториев пятнахи:
wget http://archive.fedoraproject.org/pub/fedora/linux/updates/15/SRPMS/samba-3.5.15-74.fc15.1.src.rpm
А затем его надо пересобрать командой:
rpmbuild --rebuild samba-3.5.15-74.fc15.1.src.rpm
Скорей всего, будет выдано сообщение, что для пересборки не хватает некоторых пакетов и выдаст их список. Их надо будет установить и запустить команду пересборки ешё раз.
Собственно, вот выкладываю уже готовые пакеты, чтобы не пересобирать их самим:
libsmbclient-3.5.15-74.fc13.1.x86_64.rpm
libsmbclient-devel-3.5.15-74.fc13.1.x86_64.rpm
samba-3.5.15-74.fc13.1.x86_64.rpm
samba-client-3.5.15-74.fc13.1.x86_64.rpm
samba-common-3.5.15-74.fc13.1.x86_64.rpm
samba-doc-3.5.15-74.fc13.1.x86_64.rpm
samba-domainjoin-gui-3.5.15-74.fc13.1.x86_64.rpm
samba-swat-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-clients-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-devel-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-krb5-locator-3.5.15-74.fc13.1.x86_64.rpm
После установки самбы и ввода роутера в домен я дошёл до настройки прокси-сервера. Squid я тоже решил поставить посвежее, думая, что это решит мои проблемы. Поэтому я также скачал src.rpm-ку от пятнадцатой федоры:
http://archive.fedoraproject.org/pub/fedora/linux/updates/15/SRPMS/squid-3.1.19-1.fc15.src.rpm
и попробовал пересобрать её под тринаху. Однако, выяснилось, что для нужна более свежая версия libecap, поэтому, сначала пришлось собрать libecap от пятнадцатой федоры. Вот src.rpm-ка:
http://archive.fedoraproject.org/pub/fedora/linux/updates/15/SRPMS/libecap-0.0.3-2.fc15.src.rpm
А вот готовые пересобранные пакеты squid и libecap под тринашку:
libecap-0.0.3-2.fc13.x86_64.rpm
libecap-devel-0.0.3-2.fc13.x86_64.rpm
squid-3.1.19-1.fc13.x86_64.rpm
Далее, я начал ставить Clamav. Поставил, сконфигурировал. Но тут меня ждал облом. Он заключался в том, что в репозиториях 13-ой федоры кламав лежит уже слишком старый, и, при попытке скачать антивирусные базы, я получил ошибку, которая прямо о том и говорила, что мол версия программы у тебя старая, поэтому базы не скачаются. Собственно, из-за этого, мне пришлось пересобрать также и clamav из src.rpm-ки от пятнадцатой федоры:
http://archive.fedoraproject.org/pub/fedora/linux/updates/15/SRPMS/clamav-0.97.3-1500.fc15.src.rpm
Вот готовые пакеты:
clamav-0.97.3-1500.fc13.x86_64.rpm
clamav-data-0.97.3-1500.fc13.noarch.rpm
clamav-data-empty-0.97.3-1500.fc13.noarch.rpm
clamav-devel-0.97.3-1500.fc13.x86_64.rpm
clamav-filesystem-0.97.3-1500.fc13.noarch.rpm
clamav-lib-0.97.3-1500.fc13.x86_64.rpm
clamav-milter-0.97.3-1500.fc13.x86_64.rpm
clamav-milter-systemd-0.97.3-1500.fc13.noarch.rpm
clamav-milter-upstart-0.97.3-1500.fc13.noarch.rpm
clamav-scanner-0.97.3-1500.fc13.noarch.rpm
clamav-scanner-systemd-0.97.3-1500.fc13.noarch.rpm
clamav-scanner-upstart-0.97.3-1500.fc13.noarch.rpm
clamav-server-0.97.3-1500.fc13.x86_64.rpm
clamav-server-sysvinit-0.97.3-1500.fc13.noarch.rpm
clamav-update-0.97.3-1500.fc13.x86_64.rpm
После этого, настройка роутера продолжалась как обычно, отличаясь лишь некоторыми маленькими моментами, связанными с тем, что система была x86_64, а не i686.
И вот когда роутер был готов и дошло дело до обрезания кислорода юзверям, то вот тут я натолкнулся на одну проблему... Дело в том, что была поставлена задача обрезать доступ ко всем популярным развлекательным сайтам. Это было сделано с лёгкостью. Однако мы заметили, что юзвери всё равно попадают на все сайты, на которые захотят. Выяснилось, что они попадают на них через анонимайзеры.
Сначала мы приняли решение заносить в чёрный список и анонимайзеры. Но быстро поняли, что это было глупым решением, ибо сайтов-анонимайзеров очень много, и когда мы прикрывали один, то юзвери легко находили другой, достаточно только было ввести в поисковике слово «анонимайзер». Мы подумали, что легко прикроем эту дыру, добавив в чёрный список url фразу "анонимайзер". Ведь как известно, вот такая связка в сквиде:
acl blackurl url_regex анонимайзер
http_access allow !blackurl
спокойно зарежет страничку поисковика, который выдал результат поиска «анонимайзер», ведь в адресе такой странички содержится слово «анонимайзер» в виде спец.символов, которые заменяют кирилицу. Например вот:
Но тут мы потерпели фиаско против юзверей. С этой проблемой я пошёл просить помощи на форум:
http://unixforum.org/index.php?showtopic=120430&hl
Приём с добавлением "анонимайзер" в список запрещённых url оказался практически бесполезным, ибо squid был чувствителен к регистру, и поэтому странички с любыми запросами типа «Анонимайзер» или «анОнимайзер» не блокировались. На форуме тоже с решением никто не смог помочь.
Первое, что мне пришло в голову — это сделать так, чтобы либо squid изначально не был чувствителен к регистру, либо чтобы SAMS научился подставлять параметр -i к url_regex. Решение вроде хорошее, но, как выяснилось, его можно осуществить только с помощью правки исходников. Тут нужна была помощь программера. И я нашёл эту помощь.
Есть у меня один очень хороший товарищ, зовут его Иван Мартюшев. Очень грамотный программист и очень хороший человек, который никогда не отказывает в помощи. Огромнейшее ему спасибо и огромнейший респект!
Итак, поломав голову над этим вопросом, мы с Иваном выбрали вариант научить SAMS подставлять ключик -i к параметру url_regex. Итак, вот как это делается:
В исходниках самса надо найти файл samsdaemon.c. В этом файле находим строчки 874, 876, 922, и 924. Они будут выглядеть вот так соответственно:
fprintf(fout,"acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
.............................
fprintf(fout,"acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
Вот в них то и добавляем наш параметр -i. После чего выглядеть они будут вот так:
fprintf(fout,"acl _sams_%s url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
.............................
fprintf(fout,"acl _sams_%s url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s -i url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
Потом надо пересобрать SAMS. Теперь, он будет создавать правила вот такого вида:
acl _sams_chat url_regex -i "/etc/squid/chat.sams"
acl _sams_porno url_regex -i "/etc/squid/porno.sams"
Я было обрадовался... Однако, как выяснилось, этим решается лишь половина проблемы. Если url_regex будет содержать кириллицу (например как у меня "анонимайзер"), то чувствительность к регистру всё равно продолжала работать. Чтобы решить эту проблему, пришлось лезть уже в исходники Squid. Чтобы разобраться в этой вопросе, у Ивана ушло больше суток. Но он всё равно нашёл, как это сделать! 
Итак, в исходниках сквида в файле main.cc после строчки 888 (это касается версии squid-3.1.8 — в других версиях номер строчки будет другой) нужно вставить конструкцию "setlocale(LC_ALL, "");"
Т.е. кусок кода, после этого, будет выглядеть так:
static void
mainInitialize(void)
{
setlocale(LC_ALL, "");
/* chroot if configured to run inside chroot */
if (Config.chroot_dir && (chroot(Config.chroot_dir) != 0 || chdir("/") != 0)) {
fatal("failed to chroot");
}
Затем, в этом же файле, надо найти строку 36 и в неё прописать: #include <locale.h>
Таким образом, кусок кода, после этого, получится вот такой:
#include "squid.h"
#include <locale.h>
#include "AccessLogEntry.h"
Ну и потом пересобираем squid. В результате будет работать ignore case для русских букв!
Вот после этого жить стало несколько радостнее... Радостнее, да не совсем! Ибо поисковики нынче умные пошли, они умеют учитывать человеческий фактор и человеческие грамматические ошибки. Иными словами, странички с результатом поиска по запросам типа «Аннонимайзер», «Анонимпрайзер», «Анонимайквапзеер» и другими похожими запросами, которые содержали одну-две грамматических ошибок, не блокировались сквидом. А результатами поиска на таких страничках, понятное дело, были списки множества анонимайзеров.
Здесь на помощь снова пришёл Иван. Он сказал, что для того, чтобы забить гол надо думать, как мяч, после чего посветил меня в магическую силу регулярных выражений 
Чтобы squid блокировал запросы с ошибками, надо в список запрещённых url добавить вот такую штуку:
[ао].*н.*[ао].*н.*[ие].*м.*[аэ].*[йи].*з.*[ие].*р
Это регулярное выражение подразумевает, что даже если человек путает буквы «а» и «о», «е» и «и», «и» и «й», «а» и «э», даже если человек вместо одной буквы «н» напишет две «н», или даже три, или даже необязательно «н», то всё равно squid поймёт его грязные намерения и заблокирует страничку с результатами поиска для подобного запроса 
При этом, регистр букв также не важен.
Вот теперь это означало победу. К чёрному списку уже самых популярных анонимайзеров мы добавили вышенаписанное регулярное выражение и напрочь отрубили доступ к поиску других анонимайзеров.
Здесь я выкладываю уже готовые rpm-ки изменённого squid и sams, а таже их src.rpm-ки, чтобы можно было пересобрать эти пакеты под другую версию операционной системы:
squid-3.1.19-1.fc13.src.rpm
squid-3.1.19-1.fc13.x86_64.rpm
squid-3.1.15-1.fc13.i386.rpm
squid-3.1.15-1.fc13.src.rpm
squid-3.1.10-1.fc13.i386.rpm
squid-3.1.10-1.fc13.src.rpm
squid-3.1.8-1.fc12.i686.rpm
squid-3.1.8-1.fc12.src.rpm
sams-1.0.5-91.1.src.rpm
sams-1.0.5-91.1.x86_64.rpm
За это ещё раз спасибо Ивану Мартюшеву.
Радость от проделанной работы была не очень долгой. Вылезла наружу другая беда, которая связана с прозрачной NTLM-авторизацией, которая в конфиге сквида обозначена вот так:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of="MYDOMAIN\\Пользователи домена"
auth_param ntlm children 50
auth_param ntlm keep_alive on
Всё дело в том, что сквид начал очень часто «отваливаться». Почти каждый день приходилось его перезапускать. Юзвери жаловались, да и самого меня это очень бесило. Этой проблемой я также решил поделиться на форуме с людьми:
http://unixforum.org/index.php?showtopic=123682&hl
Но тогда решения так и не нашлось. Поэтому, в итоге, я решил отказаться от прозрачной авторизации. Оставил basic-авторизацию, которая спрашивала логин и пароль. Можно сказать, что это был мой epic fail...
Возможно, я бы и не вернулся к этому вопросу, но тут случилось так, что я поменял работу. Кстати, вот я и подошёл к развязке того, с чего и начинал эту статью. Итак, на новой работе я везде решил поменять шлюзы, которые всем и вся давали прямой неограниченный доступ в и-нет, на свои, так называемые, продвинутые роутеры 
Которые решил поднять уже на x86_64-ой системе с более свежими пакетами, надеясь, что, на этот раз, прозрачная авторизация у меня будет работать стабильно.
Итак, поднял я свой роутер. Настроил. Начал переводить всех людей на работу через него. Поскольку, на новой работе, люди оказались более капризные, чем на старой, то тут меня прозрачная авторизация буквально спасала. Ведь до этого у них работал тупой прямой, ничем неограниченный, доступ в и-нет, который, само собой, не спрашивал никаких паролей. Вот тут я настроил роутер на прозрачную ntlm-авторизацию, и в групповых политиках AD прописал для браузера свой прокси-сервер. Поэтому переход оказался почти безболезненным: юзвери, как и прежде, открывали браузер и лазили по сайтам даже не подозревая о том, что трафик теперь проходит через прокси, и что на них уже вовсю велась статистика 
Вопросы у них появлялись лишь тогда, когда они вдруг внезапно не могли попасть в социальные сети и прочие развлекательные сайты, на что я вежливо отвечал, что отныне эта лавочка прикрыта.
Вроде всё в шоколаде... Но тут вернулась старая проблема... Прокси опять начал «отваливаться». А народ на новой работе, как я уже и сказал, более капризный — соответственно и нервничали они сильнее. Отказываться от прозрачной авторизации очень не хотелось, поскольку юзверьё весь мозг бы мне вынесло по поводу ввода пароля, который бы начал браузер запрашивать. Ситуация усугублялась ещё тем, что многие пользуются лисой, а виндовая лиса, почему-то, любит аж три раза подряд этот пароль спрашивать. Поэтому я снова решил предпринять попытку, чтобы разобраться с этой проблемой.
Вначале, я снова обратил внимание на ошибки в логах сквида, которые были вот такого вида:
[2012/011/01 15:28:57.299781, 1] libsmb/ntlmssp.c:342(ntlmssp_update)
got NTLMSSP command 1, expected 3
И попробовал рыть в этом направлении. Нарыл статью, в которой предлагалось решение:
http://00m.ru/samba3-squid-libsmbntlmssp-c342ntlmssp_update
В общем, внёс я правку в исходники самбы и пересобрал её. Вот готовые пакеты уже с подправленной самбой:
libsmbclient-3.5.15-74.fc13.1.x86_64.rpm
libsmbclient-devel-3.5.15-74.fc13.1.x86_64.rpm
samba-3.5.15-74.fc13.1.x86_64.rpm
samba-client-3.5.15-74.fc13.1.x86_64.rpm
samba-common-3.5.15-74.fc13.1.x86_64.rpm
samba-doc-3.5.15-74.fc13.1.x86_64.rpm
samba-domainjoin-gui-3.5.15-74.fc13.1.x86_64.rpm
samba-swat-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-clients-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-devel-3.5.15-74.fc13.1.x86_64.rpm
samba-winbind-krb5-locator-3.5.15-74.fc13.1.x86_64.rpm
samba-3.5.15-74.fc13.1.src.rpm
Также, обратите внимание, что я выложил и src.rpm-ку (зелёным), чтоб её можно было пересобрать под другую ОС.
Короче, это решение мне не помогло 
Squid продолжал отваливаться. А я продолжал рыть далее.
Обратил внимание на ещё одну ошибку в логах, которая выглядела так:
[2012/11/11 03:39:11.730916, 0] utils/ntlm_auth.c:186(get_winbind_domain)
could not obtain winbind domain name!
Уже не помню, где нашёл решение, но его суть заключалась в том, что нужно было отучить самбу смотреть на другие домены и рабочие группы в сети, а также в конфиге squid надо немного изменить параметры ntlm_auth. Что и было сделано. В /etc/samba/smb.conf я добавил вот такую строчку:
allow trusted domains = no
а в конфиге /etc/squid/squid.conf я заменил вот эти строчки:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of="MYDOMAIN\\Пользователи домена"
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic --require-membership-of="MYDOMAIN\\Пользователи домена"
на вот такие соответственно:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=MYDOMAIN --require-membership-of="\\Пользователи домена"
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic --domain=MYDOMAIN --require-membership-of="\\Пользователи домена"
После чего, ошибка в логе исчезла. Но моей проблеме это не помогло. Squid продолжал систематично отваливаться.
Далее, я обратил внимание, что у меня на роутере системное время отличалось аж на целый час. При этом, я проверил: демон ntpd работает нормально и время синхронизирует успешно. Тут я вспомнил, что Fedora 13 — уже старая система, которая была выпущена ещё до того, что наш «доблестный» президент догадался отменить летнее/зимнее время. А за это отвечает пакет tzdata, который (в тринадцатой федоре) не знает, что у нас отменено летнее/зимнее время. Поэтому мне также пришлось его пересобрать из src.rpm-ки от пятнадцатой федоры:
http://archive.fedoraproject.org/pub/fedora/linux/updates/15/SRPMS/tzdata-2012c-1.fc15.src.rpm
Вот пересобранные пакеты под тринаху:
tzdata-2012c-1.fc13.noarch.rpm
tzdata-java-2012c-1.fc13.noarch.rpm
После его обновления, проблема с разницей во времени на час исчезла. Но и решить мою основную проблему это также не помогло. Пришлось рыть дальше.
И вот нарыл я информацию, что оказывается есть другая прозрачная авторизация, которая работает через kerberos. Её я и решил попробовать. И в этом мне помогла вот эта статья:
http://www.k-max.name/linux/avtorizaciya-autentifikaciya-squid
Сперва наперво, на контроллере домена надо создать keytab-файл и пользователя, с которым он будет ассоциироваться. Пользователь – это самый обычный пользователь без каких-либо особых привилегий. Называться он будет router, и пароль у него будет password.
Напомню, что у меня контроллер домена на Windows server 2008 R2. После того, как создали пользователя, открываем виндовую командную строчку и делаем вот такую команду:
ktpass /crypto ALL /princ HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN /mapuser router /pass password /ptype KRB5_NT_PRINCIPAL /out C:\111\squid.keytab
где параметр /crypto ALL позволяет использовать любой тип шифрования
параметр /princ HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN – это имя службы, с которой будет ассоциирован виндовый пользователь router.
Само собой, что вместо router.mydomain.domain@MYDOMAIN.DOMAIN вы должны подставить имя своего сервера со сквидом и название своего домена AD.
Параметр /ptype задает тип принципала. В значении этого параметра рекомендуется указывать KRB5_NT_PRINCIPAL, т.к. это подходит практически для всех служб.
параметр /out C:\111\squid.keytab – название keytab-файла и путь, куда его положить.
Итак, после выполнения этой команды получим файл C:\111\squid.keytab, который надо скопировать на наш роутер. Я его скопировал в каталог /etc/squid.
Далее, нам надо посмотреть, корректен ли наш keytab-файл. Вводим команду:
klist -e -k -t /etc/squid/squid.keytab
и если видим вот такой вывод:
Keytab name: WRFILE:/etc/squid/squid.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (DES cbc mode with CRC-32) 3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (DES cbc mode with RSA-MD5) 3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (ArcFour with HMAC/md5) 3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (AES-256 CTS mode with 96-bit SHA-1 HMAC) 3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (AES-128 CTS mode with 96-bit SHA-1 HMAC)
то значит файл корректен, и его мы будем использовать для получения билета керберос. Но сначала удалим уже полученный билет:
kdestroy
А потом введём команду:
kinit -k -t /etc/squid/squid.keytab HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN
которая должна отработать без вывода каких либо сообщений — это означает, что билет получен корректно. Проверить это можно командой:
klist
Вывод должен быть примерно таким:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN
Valid starting Expires Service principal
12/13/12 18:49:22 12/14/12 04:49:22 krbtgt/MYDOMAIN.DOMAIN@MYDOMAIN.DOMAIN
renew until 12/20/12 18:49:22
Кстати, не забудем изменить владельца на keytab-файл:
chown root:squid /etc/squid/squid.keytab
Затем, находим файл /etc/sysconfig/squid и в его конец добавляем две строчки:
KRB5_KTNAME=/etc/squid/squid.keytab
export KRB5_KTNAME
Кстати, я в этом же файле изменил параметр:
SQUID_SHUTDOWN_TIMEOUT=3
чтобы squid перезапускался быстрее, а не выжидал чёрт знает чего...
Ну а в конфиге самого сквида, я заменил ntlm-ную конструкцию:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=MYDOMAIN --require-membership-of="\\Пользователи домена"
auth_param ntlm children 100
auth_param ntlm keep_alive on
На новую для авторизации через kerberos:
auth_param negotiate program /usr/lib64/squid/squid_kerb_auth -s HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN
auth_param negotiate children 100
auth_param negotiate keep_alive on
После чего попробовал, как она работает. С первого раза не получилось. Начал выяснять, и оказывается я упустил важный момент: В браузере прокси-сервер должен быть прописан не по IP-адресу (как у меня было), а по fqdn-имени. Т.е. вот в таком виде: router.mydomain.domain. Как только это сделал, то сразу заработало, чем я был очень доволен!
Однако, это лишь половина решения проблемы. Ведь остался SAMS. Дело в том, что если его настроить вот так:
то он начинает заполнять файл с пользователями вот в таком виде:
MYDOMAIN.DOMAIN@user1
user1
MYDOMAIN.DOMAIN@user2
user2
MYDOMAIN.DOMAIN@user3
user3
А надо, чтоб было наоборот: пользователь@ДОМЕН. Да и в логах он ищет именно DOMAIN+user, а не user@DOMAIN.
Тут, как я уже понимал: снова надо править исходники. И я снова хотел обратиться к Ивану. Но сначала решил погуглить, ибо наверняка такая ситуация уже у людей встречалась. И действительно! Я наткнулся вот на эту ветку форума:
http://forum.lissyara.su/viewtopic.php?f=3&t=12858#p132898
В которой один очень хороший человек под никнэймом slim рассказывает, что и где нужно подправить в исходниках самса, чтобы он прописывал пользователей по схеме пользователь@ДОМЕН и видел эту схему в логах сквида. Перекопирую его пост сюда:
Правим в исходниках файл samsdaemon.c. Строки 1886-1908. Меняем местами переменные row2[6] — домен и row2[1] — пользователь. Изменённый код получится вот таким:
for(k=1;k<strlen(SEPARATOR);k++)
{
if(BIGD==1)
{
str2upper((char *)row2[6]);
fprintf(fout,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
if(RREJIK==1&&atoi(row2[10])>0)
fprintf(fout2,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
}
else if(BIGD==-1)
{
Str2Lower(row2[6]);
fprintf(fout,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
if(RREJIK==1&&atoi(row2[10])>0)
fprintf(fout2,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
}
else
{
fprintf(fout,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
if(RREJIK==1&&atoi(row2[10])>0)
fprintf(fout2,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
}
}
Кстати на форуме у него есть одна опечатка — там он в одном месте забыл поменять row2[6] и row2[1]. После этой правки SAMS записывает пользователей в файл в нужном нам виде.
Теперь логи: в файле demon.c находим строки 209-214 и меняем их с такого вида:
if(strstr(STR[7],"+")!=0)
{
domain=strtok(STR[7],"+");
user=strtok(NULL,"+");
samsuser=ReturnSAMSUser(user, domain, STR[2], 1);
if(samsuser>0)
на такой:
if(strstr(STR[7],"@")!=0) { user=strtok(STR[7],"@"); domain=strtok(NULL,"@"); samsuser=ReturnSAMSUser(user, domain, STR[2], 1); if(samsuser>0)
А также, находим строки с 484 по 490:
if(strstr(STR[7],"+")!=0)
{
domain=strtok(STR[7],"+");
user=strtok(NULL,"+");
samsuser=ReturnSAMSUser(user, domain, STR[2], 1);
userflag=1;
}
И меняем их по аналогии:
if(strstr(STR[7],"@")!=0) { user=strtok(STR[7],"@"); domain=strtok(NULL,"@"); samsuser=ReturnSAMSUser(user, domain, STR[2], 1); userflag=1; }
После чего, пересобираем SAMS, устанавливаем и радуемся жизни! Готовую rpm-ку, а также src.rpm-ку с изменёнными исходниками выкладываю у себя:
sams-1.0.5-91.2.src.rpm
sams-1.0.5-91.2.x86_64.rpm
Отдельно хочется заметить, что я нашёл один недостаток в kerberos-авторизации. Ну как недостаток... Лишь в моём случае это недостаток. А в подавляющем большинстве других ситуаций это наверно будет именно преимуществом Дело в том, что у меня на новой работе все пользуются скайпом. А скайп этот не может пробиться через прозрачную kerberos-авторизацию. Поэтому приходится в его настройках вручную прописывать прокси, логин и пароль. А когда была прозрачная ntlm-авторизация, то скайп сам через неё пробивался, что в моём случае было очень удобно.
Сейчас у себя на прокси я оставил два типа авторизации: прозрачная через керберос и вторая по списку — обычная непрозрачная ntlm, которая запрашивает логин и пароль в виде:
user
password
Поэтому, в программах, которые не могут пробиться через керберос, я просто прописываю прокси по ай-пишнику и вбиваю логин и пароль пользователя. На этом, я пока закончу эту статью. Есть у меня ещё одна проблемка, которую я пока не разрешил. Как только я с ней разберусь, то дополню эту статью.
