LINUX.ORG.RU
решено ФорумAdmin

Squid — access denied в прозрачном режиме

 , ,


0

1

Привет. Бьюсь со Squid, скоро сойду с ума.

Имеется примерно такая сеть: http://goo.gl/8DxUqR (ничего необычного).

В качестве шлюза в интернет роутер на OpenWrt, в локальной сети установлен компьютер со Squid (на Fedora, если важно). Сеть: 192.168.5.0/24. Нужно прозрачно проксировать веб-трафик через Squid.

Для тестов пока использую вместо 80 другой порт — 8873.

Многострадальный конфиг /etc/squid.conf: http://pastebin.com/ERXJ8DEy

Часть /etc/config/firewall на OpenWrt:

config redirect                               
        option src              lan           
        option proto            tcp           
        option src_ip           !192.168.5.20                 
        option src_dport        8873                      
        option dest_ip          192.168.5.20
        option dest_port        3129
        option target           DNAT
                                              
config redirect                               
        option dest             lan           
        option proto            tcp           
        option src_dip          192.168.5.1                
        option dest_ip          192.168.5.20
        option dest_port        3129
        option target           SNAT  
Взято отсюда: http://wiki.openwrt.org/ru/doc/uci/firewall#transparent.proxy.rule.external Чтобы было понятнее вот аналог: http://www.tldp.org/HOWTO/TransparentProxy-6.html Так тоже не работает:
iptables -t nat -A PREROUTING -i br-lan ! -s 192.168.5.20 -p tcp --dport 8873 -j DNAT --to 192.168.5.20:3129
iptables -t nat -A POSTROUTING -o br-lan -s 192.168.5.0/24 -d 192.168.5.20 -j SNAT --to 192.168.5.1
iptables -A FORWARD -s 192.168.5.0/24 -d 192.168.5.20 -i br-lan -o br-lan -p tcp --dport 3129 -j ACCEPT

По логике все правильно, но не работает. Пытаюсь из локальной сети открыть URL http://example.com:8873/ и получаю «Доступ запрещён»:

$ curl -X HEAD -i example.com:8873
HTTP/1.1 403 Forbidden
Server: squid/3.3.13
Mime-Version: 1.0
Date: Wed, 26 Nov 2014 00:24:49 GMT
Content-Type: text/html
Content-Length: 3280
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from anon
X-Cache-Lookup: MISS from anon:3128
X-Cache: MISS from amurdep
X-Cache-Lookup: MISS from anon:3128
Via: 1.1 anon (squid/3.3.13), 1.1 anon (squid/3.3.13)
Connection: keep-alive
Не знаю почему тут порт 3128, у меня прозрачный на 3129.

В cache.log:

2014/11/26 09:55:35 kid1| WARNING: Forwarding loop detected for:

В access.log:

1416963429.856      0 192.168.5.20 TCP_MISS/403 357 HEAD http://example.com:8873/ - HIER_NONE/- text/html
1416963429.856      1 192.168.5.1 TCP_MISS/403 453 HEAD http://example.com:8873/ - HIER_DIRECT/192.168.5.20 text/html

С хоста со сквидом (192.168.5.20) я могу без проблем открыть нужный URL, т.е. роутер не отправляет трафик обратно. На другой сети с похожей конфигурацией абсолютно все так же не работает.

При этом Tinyproxy работает! Но Squid упорно не пускает и говорит о кольце, хотя его нет. Если в Squid отключить Via и X-Forwaded-For, то Squid не может определить кольцо и зависает. Т.е. у Squid кольцо есть, а у Tinyproxy кольца нет. В непрозрачном режиме через 3128 все работает.

Помогите пожалуйста.

P.S. Tinyproxy + Squid не предлагать :)

★★★★

Последнее исправление: Black_Roland (всего исправлений: 3)

В непрозрачном режиме через 3128 все работает.

ну если так, то может где-то в iptables-ах забыл нужный порт открыть ?

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

На сервере (со сквидом) правил iptables вообще никаких нет, т.е. ничего не блокируется. Точнее есть немного от Docker'а, но это не суть. Если бы файрволом ограничивалось то, страничку с 403 не отдавало бы, просто никакого ответа не было бы. На роутере тоже все открыто из локальной сети.

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

У меня сейчас связка Tinyproxy в прозрачном режиме + Squid в непрозрачном нормально работает, так же через 3129 порт. А просто Squid в прозрачном не хочет работать. Такое ощущение что сам на себе замыкается почему-то.

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

Готово.

Там все просто: один роутер, для доступа в инет, компьютеры подключены к роутеру по локальной сети, сервер со Squid в той же сети.

Black_Roland ★★★★
() автор топика

Отвлекаясь от Forwarding loop, вам не кажется ненормальным вот это:

1416963429.856 1 192.168.5.1 TCP_MISS/403 453 HEAD http://example.com:8873

т.е. ваш эксперимент поставлен так, не только клиент лезет на 8873 порт, но и сам squid будет безрезультатно искать HTTP сервер example.com на нем же.

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

Почему безрезультатно? Я на VPS'ке сделал тестовую вэб-страничку на порту 8873. Или я чего-то не понимаю?

Пробовал в другой сети делать тоже самое на 80 порту — абсолютно те же ошибки. Пробовал внутри Docker поднимать Squid на CentOS — тоже никак :(

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

У меня эта ссылка уже даже как посещенная подсвечена :( Похоже там так и не решили проблему. С маркировкой пакетов лень возиться, а все остальное я уже пробовал. Помимо этого находил и другие похожие случаи, но либо проблему не решили, либо задачи разные.

Причем проблема явно где-то в Squid, потому что Tinyproxy работает отлично, даже в связке со Squid. Но хотелось бы сделать нормально, без Tinyproxy.

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

Ну так и попробуйте маркировку, раз ничто другое не помогает. В вашем же примере с iptables написано: «6.1 First method (simpler, but does not work for some esoteric cases)». В общем эзотерика как она есть. Кто-то пишет, что просто обновление версии squid на том же конфиге может привести к подобной неработоспособности. Так что Tinyproxy - не показатель.

rubic
()

На том же хосте поднял Squid 3.1.19 (был 3.3.13) в контейнере с Ubuntu 12.04 — все работает. Видимо надо читать changelog. А Tinyproxy сегодня завис.

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

Ну вот это вот видимо оно и есть.

«The HTTP Host: header cannot be trusted much in interception mode (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0801). Squid-3.2 and later will verify that 192.168.0.2:3128 IP address NAT delivered belongs to the Host: header domain before allowing the Host: header to be used. When it fails (as it will fail 100% on your system) Squid will be transparent and pass the request on t the same place the cleint was connection.

On your system Squid is transparently relaying the intercepted traffic to the web server it is being told exists at 192.168.0.1:3128.

Routers need to *route* the port 80 traffic to the Squid box *without* using NAT.»

http://www.squid-cache.org/mail-archive/squid-users/201304/0061.html

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

Спасибо. Да, все совпадает.

Routers need to *route* the port 80 traffic to the Squid box *without* using NAT.

Похоже придется с маркировкой пакетов.

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

Почитал про маркировку пакетов, у меня на 80 порту веб-сервер висит, ставить squid как reverse proxy для веб-сервера тоже не хочется :(

Реально ли как-то без DNAT, SNAT и 80-го порта обойтись? Или может можно выключить проверку Host в Squid?

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

Так заработало: http://serverfault.com/a/371858

visible_hostname squid
client_dst_passthru off

http_access allow all

http_port 3128
http_port 3129 accel vhost allow-direct

cache_dir ufs /var/spool/squid 100 16 256

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

Фух, спасибо большое всем.

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

Хотя по документации accel вообще не для того, но работает.

Black_Roland ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.