PermLUG
|
Пермская группа пользователей Linux |
|
ОблакоВход для пользователейНавигация |
Squid со включенным samsredir не пускает на https Здравствуйте. Возникла такая проблема: squid со включенным samsredir не пускает на https. Во время доставки URL: Произошла следующая ошибка: Невозможно определить IP адрес узла http Сервер адресов ответил: Name Error: The domain name does not exist. Это обозначает: Кэш не в состоянии определить сервер, указанный в URL. Версия squid 2.5stable12 с поддержкой icap. Пожалуйста, подскажите где кроется ошибка?? Всем заранее спасибо!
|
Новые записи в блогахАктивные обсуждения форума
|
| Пермская группа пользователей Linux, 2003—2008 |
попробуй сравнить то что на входе и на выходе из samsredir:
echo 'https://banking.webmoney.ru/ ip_of_user/- username get' | `which samsredir' -dиecho 'https://banking.webmoney.ru/ ip_of_user/- username connect' | `which samsredir' -dпоследняя строчка на выходе это то, что получает сквид и на что ругается.
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Не раз поднималась такая проблема. Дело в том, что у меня были проблемы с DNS. Это единственная причина при работе с https. Воспользуйся поиском по форуму.
sams-1.0.1
PHP 5.2.2
Apache/1.3.37
squid 2.6.10
mysql 4.0.27
samba 3.0.24
freebsd 6.2-RELEASE
redirector sams
auth ntlm+ip
Вот что получается в логах сквида со включенным редиректором:
1224672589.034 2 192.168.1.254 TCP_MISS/404 0 CONNECT http:443 - DIRECT/- -
А так без него:
1224672645.200 618 192.168.1.254 TCP_MISS/200 1534 CONNECT dynamic.exaccess.ru:443 - DIRECT/212.118.48.53 -
DogEater, вот последние строчки, полученные путём выполнения предложенных вами комманд:
https://banking.webmoney.ru/ 192.168.1.254/- admin get
https://banking.webmoney.ru/ 192.168.1.254/- admin connect
Eagle, я читал уже эти тема, но решения, предложенные там, у меня не сработали. Может быть я что-то не правильно делаю, конечно.
Я прописал в конфиге squid'а dns_nameservers 192.168.0.1, 88.86.66.254 - это не помогло. А то что написано про DNS в web-интерфейсе SAMS - честно, я не понял что автор поста имел ввиду =)
В аттаче мои конфиги сквида и самса.
Буду благодарен за любую помощь.
Сейчас заметил ещё одну вещь - создал новый шаблон и сделал авторизацю по IP, а не NCSA. Создал тестового юзера. И сразу всё заработало. Потом переключил авторизацию на NCSA - всё работает. Но после того, как я закрыл браузер и заново авторизовался - всё по новой, опять не пускает.
Включение/выключение "Преобразовывать DNS имена" не помогает. Я уже попробовал редиректоры от версий 20060417, 1.0.1, 1.0.3, обновился до 1.1.0 - ничего не помогает. Я может что-то не так делаю? Я делаю killall samsdaemon, samsredir, перезаписываю их другой версией. Делаю squid -k shutdown.
Запускаю samsdaemon, запускаю squid. Пытаюсь зайти на https со включенным checkdns, с выключенным checkdns. Ни-че-го.
Мне кажется ошибка где-то в другом месте. DNS тут не причём, потому что на каком-то этапе адрес хоста просто теряется и sams дальше обрабатывает уже хост вида http:443, где уже никакого адреса просто нет, соотвественно и DNS разрешить нельзя.
Интересно также то, что при IP авторизации проблем нет.
Такая крамольная мысль, а может из за icap? Он включен?
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Тоже грешил по началу на icap. Отключал - не помогло.
Да и тем более с ним, но без редиректора - всё ок.
А acl на порты SSL у тебя какие? Можешь показать?
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Конфиг в моём втором сообщении в аттаче.
Там всё стандартно, из конфига сквида по дефолту.
Подскажите, пожалуйста, надо временный вариант сделать.
HTTPS пустить в обход редиректора как-нибудь можно?
Если да, то как? Но чтобы учёт трафика по нему шёл.
Я в таких случаях пускаю юзверей напрямую через iptables. (Соответственно браузер другой с другими настройками).
Учёт трафика идёщего напрямую у меня остался со старых времён(самописный), так что моим вниманием такие юзвери у меня всё равно не обойдены. :)
Что я предлагаю тебе: поставить такую же систему в vmware, только сквид поставить другой, чистенький.
и попробовать сначала, как оно будет работать без самса. и редиректора. Если нормально то разреши доступ только на определённые сайты определённым людям с помошью acl и пока не разберёшься с основной машиной пускай их таким образом.
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Я пытался сделать вот так:
$IPTABLES -t nat -A POSTROUTING -s 192.168.1.0/24 --out-interface eth0 -j SNAT --to-source 192.168.0.2 -p tcp -m multiport --dports 110,995,143,25,465,220,993,32000,443
Но почему то ходит всё, кроме 443 :) Не везёт мне с ним :)
И всё-таки? Можно для 443 порта сквид настроить в обход редиректора?
OpenSuse 11.0
Squid-2.5STABLE12 with icap support
SAMS-1.1.0
Нет, в обход нельзя.
Там всё просто - каждая ссылка скармливается редиректору, а тот выдаёт её в каком-то виде сквиду.
Это можно или включить или выключить.
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Хм... жаль. Пробросил пока по NAT'у. Считаю NeTAMS'ом.
Сейчас попробую поднять SAMS на другой машине с Ubuntu. Вроде никогда подобных проблем не было...
OpenSuse 11.0
Squid-2.5STABLE12 with icap support
SAMS-1.1.0
напиши, исчезла ли проблема на машине с убунтой
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Решено было оставить OpenSuse. Но авторизация по IP. Как я выше писал, с этим типом авторизации проблем не возникает.
В общем, проблема висит...
OpenSuse 11.0
Squid-2.5STABLE12 with icap support
SAMS-1.1.0
Пусть повисит, пока поддержку delay pools для третьего сквида не добавят. Может тогда она сама собой исчезнет? ;)
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Проблему подтверждаю, причину пока не нашел.
Заводите багу на sams.nixdev.net, постараюсь исправить к 1.0.4
--
NixDev - Open Source solutions for life
Тикет завел сам: http://sams.nixdev.net/ticket/284
Но баг оказался плавающим, поэтому воспроизвести его во второй раз не могу. Хотелось-бы получить инструкция как воспроизвести.
--
NixDev - Open Source solutions for life
На мой взгляд проблема возникает из-за того что правила доступа к HTTPS находиться до правила SAMS.
http_access allow connect
http_access allow localhost
http_access allow itpro_network
http_access allow SSL_ports
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# TAG: http_access
http_access allow _sams_default
тоесть Squid пропускает пользователя, на любые SSL, а дальше редиректор не пускает, т.к. в строке которая ему передается отсутствует пользователь. Соответственно редиректор перенаправляет запрос на старницу "доступ запрещен", которая ну ни как не похожа на SSL, из-за этого и происходит глюк с http:443.
Как вариант думаю можно поставить
redirector_access allow itpro_network
перед правилом SAMSа, но тогда могут полезть еще какие глюки.
Тогда объясни, отчего в ссылке, которая возвращается в страницу ошибки убивается всё кроме "https" и номера порта?
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Это или ошибка или фича squid. Только что проверил на обычном перловом редиректоре, если редиректить https запрос на http. То squid именно это и показывает "http:443".
Проверьте сами если мне не верите.
#!/usr/bin/perl
$|=1;
while (<>) {
s@from_site@http://to_site@;
print;
}
Ну почему так сразу - "не верите"?
Это здорово, что ты отловил такую багу. Предупреждён, значит вооружён.
Но вот на своём сквиде - родном из системы, я такого не замечал.
Вполне вероятно, что эта хрень там устранена патчем.
Надо будет ещё на трёшке самосборной попробовать.
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Проверил на 3 версии, входящей в Ubuntu 8.04.1. Все тоже самое. Если запрос на https редиректить на http, то вылазит такая бяка "http:443". Видимо сквид ожидает редиректа также на https.
Сквид ожидает редиректа на всех портах/протоколах(как бы я иначе асю резал?). Вот почему именно на https бяка?
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Т.к. ожидаеться шифрованное соединение, а его нет.
мне стыдно об этом писать но у меня https работает.
только что послали нах с сертификатом. :)
сквид 3, самосборный rpm, редиректор sams. sams-1.0.3-credit.0
правда на всех моих хостах ssl тоже пересобранный. Может в этом дело??
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Работать то он работает, и с редиректором работает. Я речь то веду к тому что, если редиректить https на http, то и сертификатов никаких не будет, откуда им взяться то?
Сам тестировал все на Ubuntu 8.04.1 с родными пакетами что 2, и 3 Squid, SAMS 1.0.3 + credit path и SAMS 1.0.4 + credit path, NTLM авторизация. Столкнулся с такой бякой когда пытался разобраться почему SUN JAVA не авторизуеться по NTLM, и редиректор соотвественно переанаправляет все в сад.
Соответственно, для чистоты эксперимента, потом использовал именно простой перловый редиректор, который 100% мой SSL запрос перенаправит на простую страничку http. И результат в обоих случаях одинаковый. Конечно попробую еще на самосборном свкиде, но почему то мне кажется что результат будет такой же.
Гм... А кто говорил о перенаправлении https на http?
Garret вроде просто писал что у него вообще https с редиректом не работает...
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
Может плохо объяснил в первый раз. Но попробую еще раз.
Вот часть его конфига:
http_access allow connect
http_access allow localhost
http_access allow itpro_network
http_access allow SSL_ports
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# TAG: http_access
http_access allow _sams_default
Правило доступа к SSL у него стоит перед правилом SAMS. И по этому все подряд без аутентефикации проходят на HTTPS. А редиректору это не нравиться, он должен получить имя пользователя, что бы знать, перенаправить его на страницу запрета, или пустить дальше. Соответсвенно не получив имя пользователя он его заварачивает на локальную страницу, и уже на http. И по тому что я писал раньше появляется ошибка http:443. В случае с раздачей инета по IP адресам, такой проблеммы нет, т.к. IP адрес всегда присутствует.
Что бы все заработало, надо все правила http_access в squid.conf поставить после http_access allow _sams_default.
Надеюсь теперь понятно объяснил.
Исчерпывающе.
я бы это назвал "отлуп редиректором не-авторизованных самсом пользователей".
Я посмотрел свой конфиг. У меня как раз # TAG: http_access
стоит перед любыми другими http_access ... соответственно и самс пишет раньше.
Поэтому и работает.
Надо бы в Вику добавить.
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.3
samsredir
ip+ncsa (на это не надолго)
А у меня та же проблема, вот только нет
тэгов с
acl _sams_default src "/etc/squid/default.sams"
http_access allow _sams_default
после нажатия кнопки "перезапуск" сквид в вебморде самс, эти строчки вообще пропадают.
И все таки проблема с доступом к ресурсам https.
редиректор ес-но включен.
Как ее решать??? может кто решил?
Всё заработало! Честь и хвала kbelov! =) Спасибо огромное
OpenSuse 11.0
Squid-2.5STABLE12 with icap support
SAMS-1.1.0
Да, стоит его поблагодарить: закрыл такую тему. :)
Для самса уже пора писать troubleshoot list.
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.4-credit.0
samsredir
ip+ncsa (на это не надолго)
Ничего не закрыто! тема так и открыта.
уже голова кругом идет.
все перепробовал.
все равно https не работает
Fedora Core 8
httpd-2.2.6
mysql-5.0.4
php-5.2.4
squid-2.6.STABLE16
samba 3.2.4
sams-1.0.4
samsredir
ntlm аутентификация
squid.conf в студию (вложением)
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.4-credit.0
samsredir
ip+ncsa (на это не надолго)
да пожалуйста.
http://www.permlug.org/files/squid.tar
в вашем конфиге отсутствуют теги, нужные для работы самс # TAG: http_access, поэтому самс вам не пишет эти строки в squid.conf, ибо не знает куда именно писать.
попробуйте сделать именно в таком порядке:
тогда у вас сас сам будет писать свои правила сразу ПОСЛЕ # TAG: http_access но ДО любого сквидовского http_access
---------------------------------------------
Fedora Core release 2
httpd-2.0.52-3.1asp
mysql-3.23.58
php-4.3.9-3
squid-2.5.STABLE6-2asp
samba 3.2.0
sams-1.0.4-credit.0
samsredir
ip+ncsa (на это не надолго)
Да я понял свою ошибку, эти тэги появляются
когда устанавливается самс. Он прописывает их в скид.конф. А я его за основу взял старый и забыл про них.
Тему можно действительно закрыть. Нужно быть
внимательным. А вам большое СПАСИБО! выручили!