Здравствуйте!
Меня достали глюки со Squid’ом, которые я не могу побороть… :( У меня настроена ncsa_auth для доступа в и-нет. Всё работает, и всё бы ничего.. кроме некоторых неприятных моментов, которые весьма потртят жизнь. Первое: на половине компов icq работает, а на половие — нет. Говорит Can’t connect to proxy. Чушь полная: в и-нет с того-же компа ходить с авторизацией можно без проблем. Правила iptables точно не причём (проверял, да и ACCEPT там по умолчанию). В качестве клиентов ICQ пробовал Light-ICQ, SIM, Miranda. Ещё проблемы: 1. На обной из машин получалось коннектится аськой только с ОПРЕДЕЛЁННЫМ логином (их всего три), с другими — болт. Хотя огнептицу с тем же логином Squid пускает баз проблем. 2. На второй машине не получается законнектить асьску вообще ни под одним из логинов, ни с одним из клиентов. 3. На этой второй проблемной машинке, огнептица не получает ответ от сквида/и-нета при просьбе загрузить одну из страниз веб-приложения (index отображает, новостные и некоторые другие страницы этого сайта показывает, а самую нужную — time out).
Собственно, просьба: кто хоть что-нибудь знает по данным вопросам, расскажите где могут быть грабли, и пожалуйста, посмотрите мой конфиг:
squid.conf
http_port 192.168.0.3:3128
icp_port 0
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 30 MB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /var/spool/squid 100 16 256
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
log_ip_on_direct on
pid_filename /var/run/squid.pid
ftp_user some@email.adress
hosts_file /etc/hosts
auth_param basic program /usr/lib/squid/ncsa_auth /usr/share/squid/etc/passwd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl OFFICE proxy_auth REQUIRED src 192.168.0.0/255.255.255.0
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563 # ssl ports
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 1025-65535 # unregistered ports
acl CONNECT method CONNECT
acl purge method PURGE
acl squid_block_porn url_regex -i «/etc/squid/squidblock/porn.block.txt pron.block.txt»
acl squid_unblock_porn url_regex -i «/etc/squid/squidblock/porn.unblock.txt»
http_access deny squid_block_porn !squid_unblock_porn
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow OFFICE
http_access allow localhost
http_access deny all
http_reply_access allow OFFICE
http_reply_access deny !OFFICE
icp_access deny all
cache_mgr root
cache_effective_user squid
cache_effective_group squid
visible_hostname my.QDN.name
announce_period 0
logfile_rotate 10
forwarded_for on
cachemgr_passwd none all
snmp_port 0
snmp_access deny all
prefer_direct off
coredump_dir /var/spool/squid
Извините, за длинный пост — накипело. (dante socks не удалось наладить — никто на opennet не подсказал как там авторизовываться нужно, может хоть со сквидом нормально заработает)… Заранее спасибо всем!
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
a na chiom mashiny-klijenty krutiatsia? i voobshe — mozhet v nih problemy?
Клиенты под winXP. Может и в них проблемы, но странно это, где именно? Да, если у кого есть время/желание написать что добавить в конфиг дабы аську через SSL пустить — буду крайне благодарен. Доки читал, гуглил, пробовал, но так ничего из этого не вышло. Потому через HTTP и работает сейчас. :( Сорри за, ламерские приколы (вроде «дайте конфиг рабочий»), ну хоть в двух словах — ткните носом почему может не заработать ICQ via SSL. Сейчас буду экперименты проводить… если разрулю — напишу.
Интересно вот что:
добавляю после строки http_port 192.168.0.3:3128 строчку https_port 192.168.0.3:443 далее говорю
# service squid restart
и … облом — не стартует, в логе наблюдаю:
2004/11/17 13:30:48| Initialising SSL.
FATAL: Failed to acquire SSL certificate: error:0200100E:system library:fopen:Bad address
И, честно говоря, я так и не понял что говорится тут:
http://www.squid-cache.org/Doc/FAQ/FAQ.html#toc1.12
про SSL через Squid… :( Буду искать в мануалах.
Судя по всему, если добавить строку https_port сквиду нужен сертификат (ну а я не занимался ещё индейцем => тем более сертификаты для него не генирил)… А если эту троку закомментировать, то судя по выше указанному FAQ’у, сквид просто будет пробрасывать через себя SSL соединение по запросу CONNECT. И вот чего я не понимаю, так это того, почему он у меня этого не делает? Ведь у меня там русским языком по английски написано:
acl SSL_ports port 443 563 # ssl ports
http_access allow CONNECT SSL_ports # это я добавил
http_access deny CONNECT !SSL_ports
т.е. я проверял так: на win-машине набираю telnet linuxhostname 443 и соединения не происходт — отлуп. WHY??? :((( Куда там аське через SSL…
найди вначале ответ и понимание того, «что есть proxy?».
чем оно занимается, как обслуживает клиентов.
далее. допустим, клиенту виден только та сторона прокси, которая находится во внутренней сети. напрямую наружу доступа нет.
куда и как ты должен посылать запрос, чтобы у тебя прошло соединение с удалённым компьютером?
как должно происходить диалог клиент--прокси--удалённый_сервер?
потом поищи, в чём ты ошибался. :))
Ликбез? :) Теория такая: клиент запрашивает страницу у прокси-сервера, и если она есть в кэше, прокси-сервер отдаёт её клиенту, если нет — прокси-сервер сам устанавливает соединение с нужным хостом, запрашивает требуемую страницу, получает её, отдаёт страницу клиенту и складывает в кэш. Теперь, что касается SSL… это шифрованое соединение, и в Squid 2.5 появилась поддержка SSL-шифрования (см. http://www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE7-RELEASENOTES.html на предмет «Added SSL gatewaying support, allowing Squid to act as a SSL server in accelerator setups.»)… Это пока всё, что я нашёл по этому поводу в англоязычной документации (т.е. я не нашёл примера показывающего как этим можно воспользоваться, и у меня уже глаза болят в английский вчитываться), а сделать так как советуют тут: http://www.opennet.ru/base/net/squid_icq.txt.html мне не удалось, увы… пока что я не понял почему именно :( С always_direct надо поиграться…
Всем спасибо! :) Поборол глюки в своей голове. Пробуя в прошлый раз метод с always_direct я упустил из виду, что можно коннектится используя SSL к 443 порту login.icq.com через стандартный порт своего Squid’а (3128 в моём случае), и неправильно настраивал клиентов (вписывал порт 443 для коннекта к прокси-серверу, пробуя то 5190, то 443 для коннекта к login.icq.com. Позорище).
На всякий случай (может кому пригодится) рабочий вариант конфига:
# поскипано всё не относящееся к acl’ям и htt_access (брать в первом посте),
# остальное оставлено по причине важности порядка следования
acl OFFICE proxy_auth REQUIRED src 192.168.0.1-192.168.0.6/255.255.255.0
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563 1025 5190 # ssl ports
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 1025-65535 # unregistered ports
acl CONNECT method CONNECT
acl purge method PURGE
acl squid_block_porn url_regex -i «/etc/squid/squidblock/porn.block.txt pron.block.txt»
acl squid_unblock_porn url_regex -i «/etc/squid/squidblock/porn.unblock.txt»
acl ICQ_PORT port 443
acl ICQ_PROTO proto HTTPS
acl ICQ_ADDR dst 64.90.0.0/16 205.188.0.0/16
acl ICQ_DOMAIN dstdomain .icq.com .aol.com
http_access allow OFFICE ICQ_PORT ICQ_PROTO ICQ_ADDR CONNECT
http_access deny !OFFICE !ICQ_PORT !ICQ_PROTO !ICQ_ADDR CONNECT
always_direct allow ICQ_ADDR ICQ_PORT CONNECT
always_direct allow ICQ_DOMAIN ICQ_PORT CONNECT
http_access deny squid_block_porn !squid_unblock_porn
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access allow CONNECT SSL_ports
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow OFFICE
http_access allow localhost
http_access deny all
Итог: любой клиент (при его правильной настройке) коннектится и нормально работает используя шифрование (SSL) через http_port Squid’а.
Да, и на всякий случай можно кое-что добавить вот сюда:
always_direct allow ICQ_ADDR ICQ_PORT CONNECT
always_direct deny !ICQ_ADDR !ICQ_PORT CONNECT # запретить direct connect всем, кроме allowed alc’s
always_direct allow ICQ_DOMAIN ICQ_PORT CONNECT
always_direct deny !ICQ_DOMAIN !ICQ_PORT CONNECT # аналогично
умница. из тебя выйдет толк :))
кстати, распиши понимание сути проблемы.
скорее всего, не ты последний, кто на эти грабли наступит, так что у тебя есть шанс спасти других от такой шишки на лбу :)
ну а на тот случай, чтобы другие знали, где это искать, уже, я надеюсь, думают те, кому положено по статусу.
ps: а вообще, это можно даже в статью оформить. дерзай. ;)
(дополнить по настройке сквида вообще — это уже по желанию. но ты это ещё помнишь, да?)
Вот поэма… жду замечаний. А конфиг надо всё же оптимизировать: убрать лишнее (к примеру — кажется можно обойтись одним запретом http_access deny CONNECT сразу после разрешающего правила) и проследить ещё разок порядок следования правил на предмет отклонений от желаемого. Будет время — сделаю и отпишусь.
1. Squid всегда слушает тот порт(ы) который указан в его конфиге, соответственно соединение он может принять только на этом порту(портах). Исключение составляет лишь случай с перенаправлением соединения на другой порт при помощи внешних программ, но к данной теме это не имеет отношения — в данном случае Squid не работает в режиме transparent proxy (т.е. требует настройки клиентов). Итак, клиентские программы необходимо настроть на обращение к порту, на котором ждёт соединение Squid (в данном случае: 3128).
2. ICQ-клиенты могут работать через Squid при помощи двух протоколов: не шифруемого HTTP, и шифруемого HTTPS. В обоих случаях надо помнить, что за каждым протоколом обычно закрепляют свой порт, поэтому в настройках клиентов необходимо будет указать порт к которому будет производится подключение к ICQ-серверу. Для работы через HTTP это обычный для ICQ порт 5190, а для работы через HTTPS — порт 443.
3. Squid начиная с версии 2.5 поддерживает SSL шифрование, особенностью которого заключается отсутствие необходимости в наличии SSL-сертификата у клиента (ведь Вы пользуясь web browser’ом никогда не сталкиваетесь с необходимостью иметь такой сертификат для работы через SSL у себя, а наоборот принимаете решение о доверии сертификату сервера), а вот наличие сертификата у сервера обязательно. И если Вы решите включить эту возможность Squid’а — работать с SSL-шифрованием, вот тут Вам нужно будет вспомнить о том, что для клиентов вашего прокси-сервера Ваш прокси-сервер будет являться сервером! Простите, за тавталогию. :) И Вам придётся озаботиться созданием собственного SSL-сертификата для вашего Squid’а. Если такого желания нет — Squid может позволить прямое соединение между клиентом и удалённым сервером, только нужно его об этом прямо «попросить». И тогда Squid уже не сможет кэшировать данные передаваемые через такие соединения, зато SSL-клиент сможет почти «прозрачно» общаться с SSL-сервером. Для того, чтобы Squid распознал какие соединения необходимо направить прямо к адресату ему нужно это «растолковать». Делается это при помощи указания одного из методов соединения — CONNECT. Т.е. надо описать в конфигурационном файле для кого именно (указать хосты-клиентов, порт назначения, и протокол) мы разрешаем прямое соединение. (Надо включить в разрешающую соединение директиву http_access allow, для наших клиентов, имя acl’я содержащего метод connect, и не забыть запретить этот метод для всех иных случаев). Ещё, неплохо будет указать Squid’у на то, что соединения ICQ-клиентов следует всегда передавать прямо хосту-назначения (директива always_direct). Как всегда, ради безопасности, лучше явно описать к каким хостам позволено выполнять прямое подключение (в примере использованы и ip-адреса и имена доменов), к какому порту, и от каких именно клиентов.
Всё, пошёл я спать.