nixp.ru v3.0

23 октября 2017,
понедельник,
05:37:38 MSK

DevOps с компанией «Флант»
greyork написал 16 ноября 2004 года в 15:08 (1520 просмотров) Ведет себя как мужчина; открыл 4 темы в форуме, оставил 14 комментариев на сайте.

Здравствуйте!

Меня достали глюки со 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 не подсказал как там авторизовываться нужно, может хоть со сквидом нормально заработает)… Заранее спасибо всем!

Vladimir

a na chiom mashiny-klijenty krutiatsia? i voobshe — mozhet v nih problemy?

greyork

Клиенты под winXP. Может и в них проблемы, но странно это, где именно? Да, если у кого есть время/желание написать что добавить в конфиг дабы аську через SSL пустить — буду крайне благодарен. Доки читал, гуглил, пробовал, но так ничего из этого не вышло. Потому через HTTP и работает сейчас. :( Сорри за, ламерские приколы (вроде «дайте конфиг рабочий»), ну хоть в двух словах — ткните носом почему может не заработать ICQ via SSL. Сейчас буду экперименты проводить… если разрулю — напишу.

greyork

Интересно вот что:

добавляю после строки 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…

Genie

найди вначале ответ и понимание того, «что есть proxy?».

чем оно занимается, как обслуживает клиентов.

далее. допустим, клиенту виден только та сторона прокси, которая находится во внутренней сети. напрямую наружу доступа нет.

куда и как ты должен посылать запрос, чтобы у тебя прошло соединение с удалённым компьютером?

как должно происходить диалог клиент--прокси--удалённый_сервер?

потом поищи, в чём ты ошибался. :))

greyork

Ликбез? :) Теория такая: клиент запрашивает страницу у прокси-сервера, и если она есть в кэше, прокси-сервер отдаёт её клиенту, если нет — прокси-сервер сам устанавливает соединение с нужным хостом, запрашивает требуемую страницу, получает её, отдаёт страницу клиенту и складывает в кэш. Теперь, что касается 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 надо поиграться…

greyork

Всем спасибо! :) Поборол глюки в своей голове. Пробуя в прошлый раз метод с 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’а.

greyork

Да, и на всякий случай можно кое-что добавить вот сюда:

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 # аналогично

Genie

умница. из тебя выйдет толк :))

кстати, распиши понимание сути проблемы.

скорее всего, не ты последний, кто на эти грабли наступит, так что у тебя есть шанс спасти других от такой шишки на лбу :)

ну а на тот случай, чтобы другие знали, где это искать, уже, я надеюсь, думают те, кому положено по статусу.

ps: а вообще, это можно даже в статью оформить. дерзай. ;)

(дополнить по настройке сквида вообще — это уже по желанию. но ты это ещё помнишь, да?)

greyork

Вот поэма… жду замечаний. А конфиг надо всё же оптимизировать: убрать лишнее (к примеру — кажется можно обойтись одним запретом 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-адреса и имена доменов), к какому порту, и от каких именно клиентов.

Всё, пошёл я спать.