[ilili]

Всем привет, есть вопрос по сабжу, для начала опишу схему:

Для определенной группы абонентов с белыми адресами понадобилась более правильная реализация схемы блокировки, с подсовыванием мажорной странички, на которой всё расписано, почему нельзя и кто он по жизни.

Решили реализовать это схемой, где в конце будет tproxy от squid3. В клиентский vrf подгружаются маршруты /32 на некошерные ресурсы, где nexthop`ом будет адрес виртуалки с кваггой и сквидом, iptables заворачивает все пакеты с dst-port 80 на порт сквида. В сам сквид подгружается список с url`ми плохих парней и с помощью его acl - блокируются данные url. Ну, это вкратце о схеме, а теперь ниже, суть проблемы:

дальше сквида ничего не улетает и в логи сквида сыпятся сообщения, типа

TCP_MISS_ABORTED/000 0 GET http://blablabla_url

или

TCP_MISS/503 3745 GET http://blablabla_url

Более ничего криминального в логах сквида не появляется, бывает, что пролетает TCP_MISS/200 или 302, но не более и редко.

IPTABLES

echo 1 > /proc/sys/net/ipv4/ip_forward
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100 
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -F INPUT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -F OUTPUT
/sbin/iptables -P FORWARD DROP
/sbin/iptables -F FORWARD
/sbin/iptables -F PREROUTING
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -F
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
/sbin/iptables -t mangle -N DIVERT
/sbin/iptables -t mangle -A DIVERT -j MARK --set-mark 1
/sbin/iptables -t mangle -A DIVERT -j ACCEPT
/sbin/iptables  -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129

 

И конфигурация сквида

 

cat /etc/squid3/squid.conf |grep -v -E "#|^$"
acl blocksites url_regex "/etc/squid3/block_url"
acl our_networks src x.x.x.x/21
http_access deny blocksites
acl SSL_ports port 443
acl CONNECT method CONNECT
acl GET method GET
acl POST method POST
cache deny all
dns_v4_first on
http_access allow our_networks CONNECT
http_access allow our_networks GET
http_access allow our_networks POST
http_access allow our_networks Safe_ports
http_access allow our_networks all
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all
http_port 0.0.0.0:3128
http_port 0.0.0.0:3129 tproxy
cache_dir ufs /var/spool/squid3 100 16 256
access_log daemon:/var/log/squid3/access.log squid
logfile_rotate 4
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .		0	20%	4320
deny_info http://url_to_denyinfo_page blocksites
nonhierarchical_direct off
dns_nameservers x.x.x.x y.y.y.y

 

Если, к примеру, клиент набирает url из некошерного списка

http://zepic.org/2013/04/loli-i-tentakli/

, то в логе сквида все хорошо,

TCP_DENIED/302 347 GET http://zepic.org/2013/04/loli-i-tentakli/ - HIER_NONE/- text/html

. Но, если набрать не блокированный адрес, http://zepic.org/, то через некоторое время ожидания сквид выдаст в лог

 TCP_MISS/503 2451 GET http://zepic.org/ - HIER_DIRECT/104.28.8.117 text/html

и клиенту отдается страница с ошибкой.

С помощью tcpdump, на исходящем интерфейсе, было выяснено, что имеет место быть неверная контрольная сумма

 

tcpdump -i eth1 -vvvv host zepic.org
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
10:58:01.213056 IP (tos 0x0, ttl 64, id 65022, offset 0, flags [DF], proto TCP (6), length 60)
   ip216-194.isp_xxx.ru.49799 > 104.28.8.117.http: Flags [s], cksum 0x786d (incorrect -> 0xe0df), seq 2638483124, win 29200, options [mss 1460,sackOK,TS val 448197450 ecr 0,nop,wscale 7], length 0

 

Мужчины, что делать посоветуете? Пускать трафик этих абонентов через SCE нельзя, сразу говорю, для них делается минимальное количество узлов и устройств на пути следования трафика.

 

uname -a
Linux quagga 3.13.0-49-generic #83-Ubuntu SMP Fri Apr 10 20:11:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

squid3 -v
Squid Cache: Version 3.3.8
Ubuntu
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
'--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' 
'--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' 
'--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for'
'--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper'
'--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' 
'--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' 
'--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' 
'--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu'
'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 
'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'


iptables v1.4.21

Изменено 19 мая, 2015 пользователем ilili

[alibek]

А страница-заглушка всегда одинаковая или ее содержимое зависит от клиента и целевого URL?

[ilili]

А страница-заглушка всегда одинаковая или ее содержимое зависит от клиента и целевого URL?

Всегда одинаковая и находится на другом сервере. Но пробовал поднимать lighttpd на этом же сервере с сквид и редиректить туда же - не помогло.

[nuclearcat]

А возврат траффика с этих сайтов идет тоже через squid? src ip (блокированные) src port 80

Ибо в схеме tproxy - запрос дальше пойдет с ip клиента - но он уже "не такой" и возвращаться должен через сквид

[ilili]

А возврат траффика с этих сайтов идет тоже через squid? src ip (блокированные) src port 80

Ибо в схеме tproxy - запрос дальше пойдет с ip клиента - но он уже "не такой" и возвращаться должен через сквид

Возврат траффика идет непосредственно на src ip клиента, в этом то вся и проблема, как я думаю, т.к. ожидается ответ на src ip прокси.

Что делать, шеф ? ))

Изменено 19 мая, 2015 пользователем ilili

[Sergeylo]

Хм, у меня при попытке прикрутить tproxy год назад такая же фигня выходила. Без оного всё прекрасно работает. Видимо, нужно найти магическую граблю, которая всю малину обламывает.

Tproxy действительно принципиален?

[ilili]

Хм, у меня при попытке прикрутить tproxy год назад такая же фигня выходила. Без оного всё прекрасно работает. Видимо, нужно найти магическую граблю, которая всю малину обламывает.

Tproxy действительно принципиален?

Альтернативы есть? Вы реализовали без опции tproxy, перенаправляя запросы на обычный порт сквида ?

[Sergeylo]

Да, обычный прозрачный проксик, который себя никак не прячет - делает редирект на заглушку при блокировке и молча отдаёт остальное запрошенное. В случае таймаутов видно (почти) дефолтную сквидовскую страничку, но это редко, и проблемы никто в этом не видит.

[ilili]

Да, обычный прозрачный проксик, который себя никак не прячет - делает редирект на заглушку при блокировке и молча отдаёт остальное запрошенное. В случае таймаутов видно (почти) дефолтную сквидовскую страничку, но это редко, и проблемы никто в этом не видит.

Т.е. не сквид3, какой-то другой, как я Вас понял. Подскажете название ?

[edit] или вы вообще весь трафик заворачиваете на этот проксик ?

Изменено 19 мая, 2015 пользователем ilili

[Sergeylo]

Squid3 в режиме transparent, схема почти такая же, как у вас.

Ну, то есть у нас сбоку от бордера прокся, которая на бордер по bgp заливает маршруты на фильтруемые ресурсы, и прозрачно проксирует весь http.

[ilili]

Squid3 в режиме transparent, схема почти такая же, как у вас.

Ну, то есть у нас сбоку от бордера прокся, которая на бордер по bgp заливает маршруты на фильтруемые ресурсы, и прозрачно проксирует весь http.

ну ведь это ж и есть режим tproxy, он раньше intercept назывался

[Sergeylo]

Показательные строчки конфигов:

squid.conf

http_port 10.10.100.74:3128 transparent

iptables

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

И никаких излишеств.

 

Ну, то есть, я допускаю, что всё держится на deprecated-опциях, но оно работает, жрать не просит добавляем в полгода по ~200M памяти на виртуалку.

Изменено 19 мая, 2015 пользователем Sergeylo

[ilili]

Показательные строчки конфигов:

squid.conf

http_port 10.10.100.74:3128 transparent

iptables

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

И никаких излишеств.

 

Ну, то есть, я допускаю, что всё держится на deprecated-опциях, но оно работает, жрать не просит добавляем в полгода по ~200M памяти на виртуалку.

ОК, попробую без излишеств :)

[ilili]

-A INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

 

Попробовал, с этим правилом даже счетчик в iptables не растет при обращении к ресурсу. Вас не затруднит показать полный конфиг iptables ?

Изменено 19 мая, 2015 пользователем ilili

[Ivan_83]

Я не большой спец в линухе, но вместо INPUT просится FORWARD.

[nuclearcat]

Возврат траффика идет непосредственно на src ip клиента, в этом то вся и проблема, как я думаю, т.к. ожидается ответ на src ip прокси.

Что делать, шеф ? ))

Отключать transparent и работать по схеме с обычным прокси. Но тогда будет виден IP прокси, а не клиента.

 

Или все таки возвращать с запрещенных IP и пропускать через squid по той же схеме.

Когда вы перехватываете соединение, даже если оно выглядит похоже (ip src/dst, port src/dst) - оно уже "другое", TCP sequence и прочее - отличаются. Соответственно это соединение "принадлежит" сквиду, и только он знает, как развернуть его в настоящее соединение клиента.

Тут решайте, как вам подойдет и пишите - расскажу, как сделать.

[Sergeylo]

Значимые строки iptables

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -o eth1 -j MASQUERADE
-A INPUT -i eth0 -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 10.10.100.73/32 -i eth0 -j ACCEPT

[swsn]

У нас схема со сквидом прозрачным, редиректором и квагой стабильно работает.

Может Вам обработку запрещенных url отдать сквидгварду или другому редиректору?

[ilili]

Понимаю, что времени прошло очень много, но как-то раз решение было найдено :)

 

В сквиде нет необходимости использовать опцию tproxy, как это делал я, достаточно

http_port $ip:3129 intercept

$ip это адрес интерфейса, который слушает squid

Ну и в iptables

/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 3129
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE --random

Где eth1 является выходным интерфейсом. Не знаю, пригодится это кому или нет, пусть будет.