LINUX.ORG.RU
ФорумAdmin

Не работает squid на втором DC

 , , ,


0

2

Коллеги, добрый день! Бьюсь долгое время с данной проблемой. Имеем Squid 3.5.8, Active Directory (два DC). Настроена интеграция через керберос с AD. Все работает, всё здорово. Но когда отключаешь DC1 - сквид начинает блокировать весь траффик. Если включить тутже DC1, то все работает как надо. (группы, блокировки, ACL все работает) Пересоздавал krb5.keytab. При выключении DC1, squid получает билет от DC2, все отображается в klist. PTR записи имеются, всё резолвится. Ниже конфиги, логи.

В момент блокировки в access.log в основном код 407. А в cache.log следующее: kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Can’t contact LDAP server kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Can’t contact LDAP server

squid.conf (ниже):

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -s HTTP/prx.domen.local@DOMEN.LOCAL auth_param negotiate children 60 auth_param negotiate keep_alive off

external_acl_type inet_medium ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-medium@DOMEN.LOCAL external_acl_type inet_full ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-full@DOMEN.LOCAL external_acl_type inet_low ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-low@DOMEN.LOCAL

acl localnet src 192.168.10.0/24

acl my_full external inet_full acl my_medium external inet_medium acl my_low external inet_low acl auth proxy_auth REQUIRED

krb5.conf (ниже):

[realms] DOMEN.LOCAL = { kdc = dc1.domen.local kdc = dc2.domen.local admin_server = dc1.domen.local default_domain = domen.local}

ERROR: Error while binding to ldap server with SASL/GSSAPI: Can’t contact LDAP server

Я не понял, ты отключаешь DC1 через который проводится аутентификация squid и удивляешься, почему он работать перестает?

Интересно..

А если тебе руки отрубить, то варенье с верхней полки ты тоже достать не сможешь. А если пришить обратно - сможешь.

Загадка?

zgen ★★★★★ ()
  1. С SRV-записями все в порядке? ext_kerberos_ldap_group_acl использует SRV-записи, а не те КД, что прописаны в krb5.conf.

  2. Из логов непонятно, пытается ли вообще ext_kerberos_ldap_group_acl контактировать со вторым КД. Включи дебаг (опция -d).

bigbit ★★★★★ ()

Последовательно делаешь следующее:

1) Настроить krb5.conf на резолв параметров домена через DNS(dns_lookup_realm, dns_lookup_kdc), ручное перечисление контроллеров НЕ НУЖНО;
2) Посмотреть в tcpdump что именно squid шлет перед неуспешной авторизацией;

Если пункт 1) не сработает, к пункту 2) не переходить, чинить DNS(dcdiag с контроллера домена, вот это вот всё).

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от John1216

Да, все нормально. В логах видно, что после «ERROR: Error while binding to ldap server with SASL/GSSAPI» она переключается на воторой КД и успешно авторизует пользователя. Значит, эту единственную ошибку, которая есть в логах, можно игнорировать.

А как выглядит access.log - есть ли имя пользователя в запросах после того, как ты выключаешь КД?

Тогда такое предложение - сбросить кэш тикетов на виндовом клиенте (klist.exe purge).

Если не поможет, то повышать уровень логирования (ошибок-то, за которые можно зацепиться, в логах нет). Если не поможет, то снифить HTTP и Kerberos трафик.

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit
  1. Да, согласен. Подключается к DC2 и проверяет наличие юзера в группе. А ошибка говорит о том, что просто не может подключиться к DC1 - все верно.
  2. Что происходит в момент отключения DC1: Я перезахожу в домен (на всякий, по факту нет разницы). Открываю браузер и не грузится никакая страница, просто пишет ERR_TIMEOUT (Chrome). Никакого запроса пароля и прочего. В этот момент в access.log сыпятся сообщения о блокировки страниц, которые я запрашивал. В основном DENIED/407 либо DENIED/403. Если включить в этот момент DC1, то все моментально начинает работать как надо. P.S. bigbit, спасибо тебе, коллега, что помогаешь.. я просто уже не знаю что ему надо. Думал может дело в параметрах TTL?(хелпера) Либо есть мб какой-нить чек-лист, я может базовое что-то не включил.
John1216 ()
Ответ на: комментарий от John1216

Когда логируется 407 ошибка, есть ли в логе имя пользователя, или вместо него стоит прочерк?

Если перезапустить squid после выключения КД, это что-то меняет?

bigbit ★★★★★ ()
Ответ на: комментарий от John1216

Говорит о том, что не проходит даже аутентификация пользователя, не говоря уже об авторизации.

Видел аналогичную ситуацию - керберизованный апач не мог авторизовать пользователей после того, как выключили старые домен-контроллеры (всего их было на порядок больше, чем 2).

После рестарта апача магически все заработало.

Потом пост-фактум разглядывали графики мониторинга, и в статистике netstat было видно несколько сотен тысяч connection refused именно в этот промежуток времени, т.е. похоже, что тупой mod_kerberos долбился в старые КД.

Поэтому мне интересно - помогает ли тебе рестарт сквида?

bigbit ★★★★★ ()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

ручное перечисление контроллеров НЕ НУЖНО

Не соглашусь. Далеко не всякий софт, умеющий в SRV-записи из DNS, умеет также и сайты AD.

Допустим, имеется 4 КД в Москве, 4 в Лондоне, пара в Нью-Йорке и еще парочка в Сингапуре.

SSSD вот знает, что такое сайт, и будет соединяться с ближайшим КД в том же сайте. А всякие mod_kerberos и эта Kerberos-приблуда к сквиду - нет. В результате они будут соединяться с первым попавшимся КД. А аутентификация на КД, находящемся в другом полушарии - это дикие тормоза.

Так что ручное перечисление нужно, надо просто знать, зачем это делается.

bigbit ★★★★★ ()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от John1216

DC1 - он случайно не DNS по совместительству?
Вообще при отвале DNS-сервера тормоза ожидаемы.
Попробуй в krb5.conf указать IP-адреса kdc и рестартунуть сквид, или вообще убрать DC1 из /etc/resolv.conf.

Ты это - смелее давай - увеличивай уроваень логирования сквида, влезай в его все процессы lsof'ом и strace'ом, смотри, что они делают, чего ждут. Надо понять, что происходит в системе.

lsof покажет не только файлы, но и сетевые соединения. Именно они и интересуют - будет видно, куда ломится процесс.

tcpdump'ом активнее пользуйся, ARP-запросы мало о чем говорят. В качестве фильтра tcpdump'у можешь указать «host <DC1_IP> or host <DC2_IP>».

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

Ты прав, DC1 - DNS1, DC2 - DNS2. Сейчас так и сделал, добился того, чтобы при выключенном DC1 - прокся работала. Что поменял выставил основным DNS => DNS2 (DC2). И поставил параметр auth_param negotiate keep_alive ON (было off).

John1216 ()
Ответ на: комментарий от bigbit

Так, виновник частично найден. Это - DNS. Повторюсь, оба DC - оба DNS. Сейчас поставил в конфигурации сети и конфигурации сквида DNS только DC2 - и прокся работает. Но в логах видно что половина запросов обрабатывается(виден доменный юзер), а у половины прочерк…

John1216 ()
Ответ на: комментарий от John1216

Там порождается 60 дочерних процессов для аутентификации (children 60). У каждого свой собственный резолвер. Видимо, часть процессов уже переключилась на DC2, а часть - нет.

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

Странно.. вернул все конфиги как были, теперь при включенном DC1 происходит следующее: Все сайты открываются (согласно ACL), все работает. Но в access.log чередуются «tunnel/200» (с доменным логином) и denied/407 (с прочерком).

John1216 ()
Ответ на: комментарий от John1216

Но в access.log чередуются «tunnel/200» (с доменным логином) и denied/407 (с прочерком).

ЕМНИП, это и есть нормальная работа. Только сначала браузер без аутентификации получает 407, а потом выполняет запрос уже с аутентификацией

router ★★★★★ ()
Ответ на: комментарий от router

Победа!) router, bigbit огромное спасибо коллеги за помощь!) Оптимизировал скорость переключения между DNS, и всё как надо заработало. После выключения DC1, проходит секунды 3 и доступ в интернет возвращается. Спасибо!

John1216 ()