LINUX.ORG.RU

CentOS 7 + SQUID + Cisco (WCCP)

 , , , ,


0

2

Всех приветствую. Тут делаю скажем так шаги, для фильтрации https траффика, при помощи squid, обязательное условие, прозрачность. Почитав в интернете не мало статей, при установке все равно столкнулся с проблемой. Имеем свеже установленный CentOS 7, установил squid, установил Iptables, произвел настройки wccp как на циске так и на squid, они друг друга видят, дальше создал gre тунель для общения между ними: modprobe ip_gre ip tunnel add wccp0 mode gre remote 192.168.255.255 local 192.168.10.7 dev enp2s0 ip link set wccp0 up

Ну а далее, необходимо в iptables завернуть запросы с 80 порта на squid 3128, собственно добавляю правило: $IPT -A PREROUTING -i wccp0 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 3128 и получаю ошибку: iptables: No chain/target/match by that name.

Начал выяснять, как оказалось, необходимо правило добавить в одну из таблиц (nat, filter и т.д.), но тут у меня встала дилемма... В качестве шлюза у меня выступает цискороутер, и я в полном замешательстве, куда именно добавить правило? И как правильно? вопрос к чему https? Пытаюсь сначала хотя бы захудалый http заставить бегать. При всем при этом, циска пакеты редиректит, по ifconfig вижу что пакеты приходят, а вот обратно не вылетают... Помогите плз с проблемкой :)

Ответ на: комментарий от kolka88

И еще проблема в чем, в скрипте iptables следующее: #!/bin/bash export IPT=«iptables»

$IPT -F

$IPT -t nat -A PREROUTING -i wccp0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.7:3128 #$IPT -A PREROUTING -i wccp0 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 3128

$IPT -P INPUT ACCEPT $IPT -P OUTPUT ACCEPT

Собственно, проблема так и остается, на интерфейсе gre который счетчики бегут только в одну сторону...: wccp0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1476 inet 192.168.10.7 netmask 255.255.255.255 destination 192.168.10.7 inet6 fe80::5efe:c0a8:a07 prefixlen 64 scopeid 0x20<link> unspec C0-A8-0A-07-00-00-F0-D0-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC) RX packets 1362 bytes 149981 (146.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3 bytes 180 (180.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

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

И еще вопрос, правило я принял, но по iptables -L -v -n я вижу вот что: Chain INPUT (policy ACCEPT 7861 packets, 650K bytes) pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 3219 packets, 346K bytes) pkts bytes target prot opt in out source destination

А самого правила нет...

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

Не понимать основ iptables, по-вашему, норма.
Зато про какую-то извращенскую железку все вокруг знать обязаны.
Это новый способ троллинга или просто двойные стандарты?

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

Еще раз повторюсь, принципы iptables мне понятны более чем, так же как и IPFW, также как и Cisco ACL, что вы подразумеваете под извращенной железкой? Cisco? Серьезно, не смешно. Троллинга нет, я более чем достаточно описал проблему, если что то непонятно, спросите, а не высмеивайте. Троллинга нет, это видимо вы обижены на весь мир.

kolka88 ()

обязательное условие, прозрачность
куда именно добавить правило?

На то устройство, для которого трафик является транзитным.
Либо ставьте шлюзом линуксовую машину, либо своими силами на цисках.

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

Господи! Уважаемый ArcFi я вас очень прошу, сходите пожалуйста на википедию, ну очень прошу, посмотрите про wccp, то что вы предлагаете совсем не то что нужно... Не отнимайте пожалуйста время попусту... Но спасибо за ответы. В качестве шлюза проксю не вариант.

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

а сквидовая вики не помогает ? Судя по ней для https требует дополнительных строчек, да и ssl bump на сквиде должен работать.

Собственно остается вопрос работоспособности конкрентной версии сквида.

PS цисковские acl-и удобными не назовешь после iptables

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

Сейчас же вопрос не в cisco acl, вопрос хотя бы 80 порт заредиректить, но по всем симптомам уперлось именно в GRE тунель между роутером и CentOS, но проблема именно в CentOS, так как роутер пакеты редиректит нормально...

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

Есть связки сейчас FreeBSD + wccp + IPFW и все работает отлично, но именно с 80 портом, с 443 траблы именно с сертификатами, говорят что именно CentOS для этого идеальна. Вот и пытаюсь сделать.

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

посмотрит tcpdump-ом что приходит через gre. Посмотри куда будет отправлен ответный пакет через «ip ro get ...»

echo 0 >/proc/sys/net/ipv4/conf/wccp0/rp_filter
echo 0 >/proc/sys/net/ipv4/conf/enp2s0/rp_filter

не забыл ?

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

Кроме как SYN ничего нет :(

15:40:47.790799 IP 192.168.10.61.58825 > mail.sprut.primorye.ru.http: Flags , seq 1743869189, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:40:48.690105 IP 192.168.10.61.58823 > mailext.pro-m.org.http: Flags , seq 482443526, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:40:50.790168 IP 192.168.10.61.58825 > mail.sprut.primorye.ru.http: Flags , seq 1743869189, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:40:53.690250 IP 192.168.10.61.58820 > mailext.pro-m.org.http: Flags , seq 2721106306, win 8192, options [mss 1460,nop,nop,sackOK], length 0 15:40:54.688763 IP 192.168.10.61.58828 > mailext.pro-m.org.http: Flags , seq 3792617853, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:40:54.690227 IP 192.168.10.61.58823 > mailext.pro-m.org.http: Flags , seq 482443526, win 8192, options [mss 1460,nop,nop,sackOK], length 0 15:40:55.683491 IP 192.168.10.61.58831 > mailext.pro-m.org.http: Flags , seq 2983318713, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:40:56.790512 IP 192.168.10.61.58825 > mail.sprut.primorye.ru.http: Flags , seq 1743869189, win 8192, options [mss 1460,nop,nop,sackOK], length 0 15:40:57.688670 IP 192.168.10.61.58828 > mailext.pro-m.org.http: Flags , seq 3792617853, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:40:58.678684 IP 192.168.10.61.58831 > mailext.pro-m.org.http: Flags , seq 2983318713, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:41:03.692622 IP 192.168.10.61.58828 > mailext.pro-m.org.http: Flags , seq 3792617853, win 8192, options [mss 1460,nop,nop,sackOK], length 0 15:41:04.678390 IP 192.168.10.61.58831 > mailext.pro-m.org.http: Flags , seq 2983318713, win 8192, options [mss 1460,nop,nop,sackOK], length 0 15:41:04.690069 IP 192.168.10.61.58834 > mailext.pro-m.org.http: Flags , seq 1809780845, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

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

Так куда будет отправлен ответный syn пакет ? Я не зря написал про «ip ro get ...».

У тебя сквид в прозрачном режиме работает ( без wccp ) ? Пока он не заработает о wccp можно забыть.

http://www.slideshare.net/buithequan/wccp-introduction-final2 на 27-м слайде есть очень полезная информация о прохождении пакетов с wccp

PS нафига все зачеркивать? Или lor-код не осилил ? :)

vel ★★★★★ ()