Имеется сервер на Debian 8.4 (x64) + Squid 3.4.8 (работающий как authentication proxy), стоит задача шейпить трафик пользователям прокси. В squid.conf прописаны нужные delay_pools, но проблема в том, что режется только HTTP трафик, HTTPS идет к пользователю без ограничений. На зарубежных ресурсах есть обрывочная информация о том, что при обработке https-запросов squid использует метод CONNECT, который нельзя обработать при помощи delay_pools. Возможно ли вообще с помощью delay_pools ограничивать HTTPS, либо использовать для этих целей что-то другое вместо squid?
Прошу помочь с правилами iptables для сетевого шлюза. Имеется машинка на Debian 7.8, выполняющая роль шлюза в инет. Из софта - bind9, isc-dhcp-server. Настроил iptables (NAT во внутреннюю сеть 10.0.0.0/8), по умолчанию установил политику DROP (все что не разрешено, то запрещено). Все работает хорошо, но только первые минут 10-15 или до сброса сетевого адаптера на клиентской машине - пинги не ходят, сайты не открываются, при этом DHCP работает исправно и связь с самим шлюзом есть. Стоит выставить политику ACCEPT для INPUT и FORWARD - все начинает работать, но вариант с ACCEPT меня не устраивает.
Подскажите, где закралась ошибка? Ниже привожу листинг iptables.
*filter
Политика по умолчанию для всех цепочек - DROP
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
# Разрешаем входящие ICMP пакеты и traceroute
-A INPUT -p icmp -m icmp --icmp-type 11 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3/3 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --sport 33434:33524 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# Разрешаем внутреннее кольцо
-A INPUT -i lo -j ACCEPT
# Разрешаем DNS запросы на сервер
-A INPUT -i eth0 -p tcp -m tcp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Разрешаем DHCP
-A INPUT -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
# Разрешаем входящие ICMP пакеты
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Дропаем неправильные плохие пакеты
-A INPUT -m conntrack --ctstate INVALID -j DROP
# Вычисляем правильный размер MSS / MTU
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# Разрешаем уже установленные и отоносящиеся к ним соединения из интернет
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Разрешаем соединения из локальной сети в интернет
-A FORWARD -i eth1 -o eth0 -j ACCEPT
# Дропаем плохие пакеты
-A FORWARD -m conntrack --ctstate INVALID -j DROP
# Разрешаем исходящий traceroute
-A OUTPUT -o eth0 -p udp -m udp --dport 33434:33524 -m state --state NEW -j ACCEPT
# Разрешаем внутреннее кольцо
-A OUTPUT -o lo -j ACCEPT
Разрешаем DNS запросы с сервера
-A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
#Разрешаем DHCP ответы
-A OUTPUT -o eth1 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
# Разрешаем исходящие ICMP
-A OUTPUT -p icmp -j ACCEPT
# Дропаем плохие пакеты
-A OUTPUT -m conntrack --ctstate INVALID -j DROP
*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
# Включаем маскарадинг (NAT) для внутренней сети
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
*raw
:PREROUTING ACCEPT
:OUTPUT ACCEPT
-A PREROUTING -i lo -j CT --notrack
-A OUTPUT -o lo -j CT --notrack
*mangle
:PREROUTING ACCEPT
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
Долгая инициализация сети при загрузке (Debian 7.8)
Столкнулся с такой проблемой. Имеется шлюз на Debian 7.8, на котором 5 сетевых интерфейсов: eth0 - смотрит в инет (статика), eth1-4 - локальные. Установлены squid3, dhcp, bind9, настроены iptables. Работает все нормально до тех пор, пока внешняя eth0 сама по себе не отваливается, в логе пишется следующее:
Jan 30 15:14:44 avahi-daemon[3420]: Interface eth0.IPv6 no longer relevant for mDNS.
Jan 30 15:14:44 avahi-daemon[3420]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::76d4:35ff:fe95:3182.
Jan 30 15:14:44 NetworkManager[3455]: <info> (eth0): carrier now OFF (device state 10)
Jan 30 15:14:44 avahi-daemon[3420]: Interface eth0.IPv4 no longer relevant for mDNS.
Jan 30 15:14:44 avahi-daemon[3420]: Leaving mDNS multicast group on interface eth0.IPv4 with address <<ext_ip>>.
Jan 30 15:14:44 avahi-daemon[3420]: Withdrawing address record for fe80::76d4:35ff:fe95:3182 on eth0.
Jan 30 15:14:44 avahi-daemon[3420]: Withdrawing address record for <<ext_ip>> on eth0.
..........
Jan 30 15:14:49 kernel: [77356.396068] r8169 0000:03:00.0 eth0: link down
Jan 30 15:14:49 kernel: [77356.396121] r8169 0000:03:00.0 eth0: link down
Jan 30 15:14:49 kernel: [77356.396204] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 30 15:14:50 kernel: [77358.098233] r8169 0000:03:00.0 eth0: link up
Jan 30 15:14:50 kernel: [77358.098244] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Также при загрузке очень долго инициализируется сеть; вот кусок из dmesg
[ 6.890556] r8169 0000:03:00.0 eth0: link down
[ 6.893902] r8169 0000:03:00.0 eth0: link down
[ 6.894017] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 9.219144] r8169 0000:03:00.0 eth0: link up
[ 9.221172] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 19.234930] r8169 0000:05:02.0 eth1: link down
[ 19.236756] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 43.358767] 8139too 0000:05:01.0 eth2: link down
[ 43.360036] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[ 55.419459] 8139too 0000:05:00.0 eth3: link down
[ 55.420918] IPv6: ADDRCONF(NETDEV_UP): eth3: link is not ready
[ 67.621163] r8169 0000:02:00.0 eth4: link down
[ 67.624001] IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
[ 79.912821] RPC: Registered named UNIX socket transport module.
[ 79.913712] RPC: Registered udp transport module.
[ 79.914571] RPC: Registered tcp transport module.
[ 79.915436] RPC: Registered tcp NFSv4.1 backchannel transport module.
Пробовал отключить IPv6 auto configuration в /etc/sysctl.conf: