forum.opennet.ru - "Squid как обратный прокси" (8)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Squid как обратный прокси"

Форум Настройка Squid и других прокси серверов (Squid)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Squid как обратный прокси"	+/–
Сообщение от Валерий (??) on 04-Дек-15, 16:07
Добрый день. Стоит сервер SLES 11 SP4. Подключен один конец в инет, другой в локальную сеть. На сервере установлена Zimbra. Если подключаться из локальной сети или из инета напрямую все хорошо. Но нужна LDAP авторизация из инета, поэтому решил установить на эту же машину Squid 3.5.10 и настроить его как Reverse Proxy. Настроил сквид как реверсивный для https. Пробовал разные варианты настроек. Как экcперимент пробрасывал на другой компьютер в локальной сети на webmin все прекрасно. Никак не получается пробросить запросы на zimbra ругается на сертификат. Вот тестовый конфиг сквида без авторизации и с мусором. visible_hostname mail.external.ru https_port 444 accel key=/etc/squid/server.key cert=/etc/squid/server.crt defaultsite=mail.external.ru vhost cache_peer 192.168.100.10 parent 8443 0 proxy-only no-query originserver ssl sslflags=NO_DEFAULT_CA sslflags=DONT_VERIFY_PEER name=webmin1 acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl officesite dstdomain mail.external.ru acl officeip dst 192.168.100.10 acl SSL_ports port 443 8443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 8443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT cache_peer_access webmin1 allow officesite sslproxy_cert_error allow officesite sslproxy_cert_error allow localhost sslproxy_cert_error allow officeip sslproxy_cert_error deny all http_access allow officesite http_access allow officeip http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localnet http_access allow localhost http_access deny all icp_port 0 coredump_dir /var/cache/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/\|\?) 0 0% 0 refresh_pattern . 0 20% 4320 Ошибка в браузере При получении URL https://mail.external.ru/ произошла следующая ошибка Не удалось установить безопасное соединение с 192.168.100.10 The system returned: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE) Handshake with SSL server failed: [No Error] Для выполнения Вашего запроса этот кэш и удаленный узел не смогли согласовать взаимоприемлемые параметры безопасности. Возможно, удаленный узел не поддерживает безопасные соединения или кэш не удовлетворён удостоверением безопасности узла. Вот cache.log 2015/12/04 15:59:55 kid1\| storeDirWriteCleanLogs: Starting... 2015/12/04 15:59:55 kid1\| Finished. Wrote 0 entries. 2015/12/04 15:59:55 kid1\| Took 0.00 seconds ( 0.00 entries/sec). CPU Usage: 0.300 seconds = 0.232 user + 0.068 sys Maximum Resident Size: 61280 KB Page faults with physical i/o: 0 2015/12/04 15:59:55 kid1\| Logfile: closing log daemon:/var/log/squid/access.log 2015/12/04 15:59:55 kid1\| Logfile Daemon: closing log daemon:/var/log/squid/access.log 2015/12/04 15:59:55 kid1\| Open FD READ/WRITE 8 DNS Socket IPv4 2015/12/04 15:59:55 kid1\| Open FD UNSTARTED 10 IPC UNIX STREAM Parent 2015/12/04 15:59:55 kid1\| Squid Cache (Version 3.5.10): Exiting normally. 2015/12/04 15:59:55 kid1\| Set Current Directory to /var/cache/squid 2015/12/04 15:59:55 kid1\| Starting Squid Cache version 3.5.10 for x86_64-suse-linux-gnu... 2015/12/04 15:59:55 kid1\| Service Name: squid 2015/12/04 15:59:55 kid1\| Process ID 10957 2015/12/04 15:59:55 kid1\| Process Roles: worker 2015/12/04 15:59:55 kid1\| With 4096 file descriptors available 2015/12/04 15:59:55 kid1\| Initializing IP Cache... 2015/12/04 15:59:55 kid1\| DNS Socket created at 0.0.0.0, FD 8 2015/12/04 15:59:55 kid1\| Adding domain mkcons.ru from /etc/resolv.conf 2015/12/04 15:59:55 kid1\| Adding nameserver 192.168.100.5 from /etc/resolv.conf 2015/12/04 15:59:55 kid1\| Logfile: opening log daemon:/var/log/squid/access.log 2015/12/04 15:59:55 kid1\| Logfile Daemon: opening log /var/log/squid/access.log 2015/12/04 15:59:55 kid1\| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec 2015/12/04 15:59:55 kid1\| Store logging disabled 2015/12/04 15:59:55 kid1\| Swap maxSize 0 + 262144 KB, estimated 20164 objects 2015/12/04 15:59:55 kid1\| Target number of buckets: 1008 2015/12/04 15:59:55 kid1\| Using 8192 Store buckets 2015/12/04 15:59:55 kid1\| Max Mem size: 262144 KB 2015/12/04 15:59:55 kid1\| Max Swap size: 0 KB 2015/12/04 15:59:55 kid1\| Using Least Load store dir selection 2015/12/04 15:59:55 kid1\| Set Current Directory to /var/cache/squid 2015/12/04 15:59:56 kid1\| Finished loading MIME types and icons. 2015/12/04 15:59:56 kid1\| HTCP Disabled. 2015/12/04 15:59:56 kid1\| Pinger socket opened on FD 14 2015/12/04 15:59:56 kid1\| Configuring Parent 192.168.100.10/8443/0 2015/12/04 15:59:56 kid1\| Squid plugin modules loaded: 0 2015/12/04 15:59:56 kid1\| Adaptation support is off. 2015/12/04 15:59:56 kid1\| Accepting reverse-proxy HTTPS Socket connections at local=0.0.0.0:444 remote=[::] FD 12 flags=9 2015/12/04 15:59:56\| pinger: Initialising ICMP pinger ... 2015/12/04 15:59:56\| icmp_sock: (1) Operation not permitted 2015/12/04 15:59:56\| pinger: Unable to start ICMP pinger. 2015/12/04 15:59:56\| icmp_sock: (97) Address family not supported by protocol 2015/12/04 15:59:56\| pinger: Unable to start ICMPv6 pinger. 2015/12/04 15:59:56\| FATAL: pinger: Unable to open any ICMP sockets. 2015/12/04 15:59:56 kid1\| storeLateRelease: released 0 objects 2015/12/04 16:00:16 kid1\| recv: (111) Connection refused 2015/12/04 16:00:16 kid1\| Closing Pinger socket on FD 14 2015/12/04 16:01:32 kid1\| Error negotiating SSL on FD 13: error:00000000:lib(0):func(0):reason(0) (5/0/0) 2015/12/04 16:01:32 kid1\| TCP connection to 192.168.100.10/8443 failed 2015/12/04 16:01:32 kid1\| temporary disabling (Bad Gateway) digest from 192.168.100.10 Может кто сталкивался с таким? Куда копать и чего читать?
Ответить \| Правка \| Cообщить модератору

Оглавление

Squid как обратный прокси, omnomnim, 16:30 , 04-Дек-15, (1) +2
Squid как обратный прокси, keir, 20:22 , 05-Дек-15, (2)

Squid как обратный прокси, Sandman_VO, 07:09 , 07-Дек-15, (3)

Squid как обратный прокси, eRIC, 21:14 , 09-Дек-15, (6)

Squid как обратный прокси, Sandman_VO, 14:38 , 07-Дек-15, (4)

Squid как обратный прокси, eRIC, 21:05 , 09-Дек-15, (5)

Squid как обратный прокси, Sandman_VO, 07:40 , 11-Дек-15, (7)

Squid как обратный прокси, eRIC, 19:00 , 12-Дек-15, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "Squid как обратный прокси" +2 +/–

Сообщение от omnomnim on 04-Дек-15, 16:30

автоген->ж*па->гланды
google:// nginx proxy_pass https

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Squid как обратный прокси" +/–

Сообщение от keir (ok) on 05-Дек-15, 20:22

> Добрый день.
> Стоит сервер SLES 11 SP4. Подключен один конец в инет, другой в
> локальную сеть. На сервере установлена Zimbra. Если подключаться из локальной сети
> или из инета напрямую все хорошо. Но нужна LDAP авторизация из
> инета
Подождите, а почему ldap-авторизация невозможна сейчас? И по каким критериям было решено, что squid поможет ldap-авторизации?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Squid как обратный прокси" +/–

Сообщение от Sandman_VO (ok) on 07-Дек-15, 07:09

>> Добрый день.
>> Стоит сервер SLES 11 SP4. Подключен один конец в инет, другой в
>> локальную сеть. На сервере установлена Zimbra. Если подключаться из локальной сети
>> или из инета напрямую все хорошо. Но нужна LDAP авторизация из
>> инета
> Подождите, а почему ldap-авторизация невозможна сейчас? И по каким критериям было решено,
> что squid поможет ldap-авторизации?
В zimra авторизация через ldap есть и настроена. Планируется использование исключительно web интерфейса для почты. Проблема в том, что в zimbra можно либо включить, либо выключить web интерфес. А нужно ограничить доступ с внешки до zimbra. Поэтому и возникла идея обратного прокси. В составе zimbra есть обратный прокси на базе nginx. Беглый просмотр документации показал, что nginx (из коробки) не поддерживает ldap авторизацию, только через внешний модуль, поэтому и возникла идея использовать для этих целей squid.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Squid как обратный прокси" +/–

Сообщение от eRIC (ok) on 09-Дек-15, 21:14

щас у вас тупо со Squid 444 https порта трафик заворачивается на Zimbra порт 8443(это и есть вебмайл интерфейс Zimbra). вы дальше собираетесь на Squid вешать LDAP авторизацию?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Squid как обратный прокси" +/–

Сообщение от Sandman_VO (ok) on 07-Дек-15, 14:38

И так наковырял кучу информации. Мозг кипит, но немного прояснилось.
1. Разобрался с OpenSSL оказывается стояла версия 0.9.8, которая не поддерживает TLS 1.2 Обновил. Теперь команда openssl s_client - connect ip:8443 отрабатывает нормально и ошибку не дает.
2. В системе продолжает работать также старая версия OpenSSL и удалить ее не могу.
3. Squid 3.5.10 упорно использует библиотеку из старой версии, т.е. libcrypto.so.0.9.8
Ну и вопрос как заставить squid использовать для ssl более новую библиотеку.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Squid как обратный прокси" +/–

Сообщение от eRIC (ok) on 09-Дек-15, 21:05

> И так наковырял кучу информации. Мозг кипит, но немного прояснилось.
> 1. Разобрался с OpenSSL оказывается стояла версия 0.9.8, которая не поддерживает TLS
> 1.2 Обновил. Теперь команда openssl s_client - connect ip:8443 отрабатывает нормально
> и ошибку не дает.
> 2. В системе продолжает работать также старая версия OpenSSL и удалить ее
> не могу.
> 3. Squid 3.5.10 упорно использует библиотеку из старой версии, т.е. libcrypto.so.0.9.8
> Ну и вопрос как заставить squid использовать для ssl более новую библиотеку.
то что вы обновляли, вы обновляли openssl и только. касательно библиотеки openssl, то нужно обновлять libopenssl1(или openssl1) чтобы приложения могли пользоваться библиотеками openssl
в SLES да используется 0.9.8j если не ошибаюсь версия. если у вас есть SUSE Linux Enterprise Server subscription то можете воспользоваться официальным методом по установки 1.0.X версии этих библиотек: https://www.suse.com/communities/blog/introducing-the-suse-l.../
ну или по крайней мере собирать из исходников squid с нужными всеми опциями

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Squid как обратный прокси" +/–

Сообщение от Sandman_VO (ok) on 11-Дек-15, 07:40

Добрый день.
Всем спасибо. Разобрался. Основная проблема все таки была в OpenSSL. Обновил все библиотеки и squid (пакет rpm) сам подцепил нужную версию, а дальше просто правила в squid правильно настроил и все заработало как надо. Сейчас сначала запрашивается пароль при обращении к сайту, а дальше идет перенаправление на соответствующий этому сайту внутренний сервер, включая zimbra.
Остался только 1 вопрос(не столь важный, но для самообразования интересно):
В директиве cache-peer есть опция login=PASS. Добиться ее работы мне не удалось. Возможно причина опять же в шифровании. Схема получилась следующая.
https://mail.examle.ru -> запрос пароля squid -> если все хорошо, проброс на https://localnetip:8443 -> страница с авторизацией zimbra.
Т.е. сейчас необходимо 2 раза вводить свои учетные данные. Можно ли как то это подправить, чтобы данные первой авторизации пробрасывались дальше?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Squid как обратный прокси" +/–

Сообщение от eRIC (ok) on 12-Дек-15, 19:00

> Т.е. сейчас необходимо 2 раза вводить свои учетные данные. Можно ли как
> то это подправить, чтобы данные первой авторизации пробрасывались дальше?
я ранее и спрашивал про авторизацию на SQUID, вы на нее хотели повесить авторизацию?. да в итоге по вашей выбранной схеме у вас две разные независимые точки авторизации, то что хотели то и получили= типа некая двух-факторная авторизация :) :)
в Zimbra можно настроить Preauth или внедрять решения типа SSO/SAML Service Provider/IdP для SQUID и Zimbra
можно было так же поднять nginx для проксирования и передавать нужные ZM_AUTH_TOKEN заголовки для Zimbra. смотрите в сторону Zimbra Proxy
>В директиве cache-peer есть опция login=PASS. Добиться ее работы мне не удалось.
не знаю какая версия у вас Zimbra и были ли изменения авторизации в последних версиях Zimbra, если обычная Bacid Form авторизация то нужно использовать в cache_peer login=PASSTHRU
>Проблема в том, что в zimbra можно либо включить, либо выключить web интерфес. А нужно >ограничить доступ с внешки до zimbra. Поэтому и возникла идея обратного прокси.
опять таки вопрос: зачем нужен был тогда этот каламбур со SQUID если все равно предоставляется доступ до Zimbra? SQUID как файрвольчик :)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Squid как обратный прокси"	+2 +/–
Сообщение от omnomnim on 04-Дек-15, 16:30
автоген->ж*па->гланды google:// nginx proxy_pass https
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

2. "Squid как обратный прокси"	+/–
Сообщение от keir (ok) on 05-Дек-15, 20:22
> Добрый день. > Стоит сервер SLES 11 SP4. Подключен один конец в инет, другой в > локальную сеть. На сервере установлена Zimbra. Если подключаться из локальной сети > или из инета напрямую все хорошо. Но нужна LDAP авторизация из > инета Подождите, а почему ldap-авторизация невозможна сейчас? И по каким критериям было решено, что squid поможет ldap-авторизации?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "Squid как обратный прокси"	+/–
	Сообщение от Sandman_VO (ok) on 07-Дек-15, 07:09
	>> Добрый день. >> Стоит сервер SLES 11 SP4. Подключен один конец в инет, другой в >> локальную сеть. На сервере установлена Zimbra. Если подключаться из локальной сети >> или из инета напрямую все хорошо. Но нужна LDAP авторизация из >> инета > Подождите, а почему ldap-авторизация невозможна сейчас? И по каким критериям было решено, > что squid поможет ldap-авторизации? В zimra авторизация через ldap есть и настроена. Планируется использование исключительно web интерфейса для почты. Проблема в том, что в zimbra можно либо включить, либо выключить web интерфес. А нужно ограничить доступ с внешки до zimbra. Поэтому и возникла идея обратного прокси. В составе zimbra есть обратный прокси на базе nginx. Беглый просмотр документации показал, что nginx (из коробки) не поддерживает ldap авторизацию, только через внешний модуль, поэтому и возникла идея использовать для этих целей squid.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "Squid как обратный прокси"	+/–
	Сообщение от eRIC (ok) on 09-Дек-15, 21:14
	щас у вас тупо со Squid 444 https порта трафик заворачивается на Zimbra порт 8443(это и есть вебмайл интерфейс Zimbra). вы дальше собираетесь на Squid вешать LDAP авторизацию?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору

4. "Squid как обратный прокси"	+/–
Сообщение от Sandman_VO (ok) on 07-Дек-15, 14:38
И так наковырял кучу информации. Мозг кипит, но немного прояснилось. 1. Разобрался с OpenSSL оказывается стояла версия 0.9.8, которая не поддерживает TLS 1.2 Обновил. Теперь команда openssl s_client - connect ip:8443 отрабатывает нормально и ошибку не дает. 2. В системе продолжает работать также старая версия OpenSSL и удалить ее не могу. 3. Squid 3.5.10 упорно использует библиотеку из старой версии, т.е. libcrypto.so.0.9.8 Ну и вопрос как заставить squid использовать для ssl более новую библиотеку.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Squid как обратный прокси"	+/–
	Сообщение от eRIC (ok) on 09-Дек-15, 21:05
	> И так наковырял кучу информации. Мозг кипит, но немного прояснилось. > 1. Разобрался с OpenSSL оказывается стояла версия 0.9.8, которая не поддерживает TLS > 1.2 Обновил. Теперь команда openssl s_client - connect ip:8443 отрабатывает нормально > и ошибку не дает. > 2. В системе продолжает работать также старая версия OpenSSL и удалить ее > не могу. > 3. Squid 3.5.10 упорно использует библиотеку из старой версии, т.е. libcrypto.so.0.9.8 > Ну и вопрос как заставить squid использовать для ssl более новую библиотеку. то что вы обновляли, вы обновляли openssl и только. касательно библиотеки openssl, то нужно обновлять libopenssl1(или openssl1) чтобы приложения могли пользоваться библиотеками openssl в SLES да используется 0.9.8j если не ошибаюсь версия. если у вас есть SUSE Linux Enterprise Server subscription то можете воспользоваться официальным методом по установки 1.0.X версии этих библиотек: https://www.suse.com/communities/blog/introducing-the-suse-l.../ ну или по крайней мере собирать из исходников squid с нужными всеми опциями
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

7. "Squid как обратный прокси"	+/–
Сообщение от Sandman_VO (ok) on 11-Дек-15, 07:40
Добрый день. Всем спасибо. Разобрался. Основная проблема все таки была в OpenSSL. Обновил все библиотеки и squid (пакет rpm) сам подцепил нужную версию, а дальше просто правила в squid правильно настроил и все заработало как надо. Сейчас сначала запрашивается пароль при обращении к сайту, а дальше идет перенаправление на соответствующий этому сайту внутренний сервер, включая zimbra. Остался только 1 вопрос(не столь важный, но для самообразования интересно): В директиве cache-peer есть опция login=PASS. Добиться ее работы мне не удалось. Возможно причина опять же в шифровании. Схема получилась следующая. https://mail.examle.ru -> запрос пароля squid -> если все хорошо, проброс на https://localnetip:8443 -> страница с авторизацией zimbra. Т.е. сейчас необходимо 2 раза вводить свои учетные данные. Можно ли как то это подправить, чтобы данные первой авторизации пробрасывались дальше?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	8. "Squid как обратный прокси"	+/–
	Сообщение от eRIC (ok) on 12-Дек-15, 19:00
	> Т.е. сейчас необходимо 2 раза вводить свои учетные данные. Можно ли как > то это подправить, чтобы данные первой авторизации пробрасывались дальше? я ранее и спрашивал про авторизацию на SQUID, вы на нее хотели повесить авторизацию?. да в итоге по вашей выбранной схеме у вас две разные независимые точки авторизации, то что хотели то и получили= типа некая двух-факторная авторизация :) :) в Zimbra можно настроить Preauth или внедрять решения типа SSO/SAML Service Provider/IdP для SQUID и Zimbra можно было так же поднять nginx для проксирования и передавать нужные ZM_AUTH_TOKEN заголовки для Zimbra. смотрите в сторону Zimbra Proxy >В директиве cache-peer есть опция login=PASS. Добиться ее работы мне не удалось. не знаю какая версия у вас Zimbra и были ли изменения авторизации в последних версиях Zimbra, если обычная Bacid Form авторизация то нужно использовать в cache_peer login=PASSTHRU >Проблема в том, что в zimbra можно либо включить, либо выключить web интерфес. А нужно >ограничить доступ с внешки до zimbra. Поэтому и возникла идея обратного прокси. опять таки вопрос: зачем нужен был тогда этот каламбур со SQUID если все равно предоставляется доступ до Zimbra? SQUID как файрвольчик :)
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору