transparent VLAN bridge + squid3 + ipset+динамический шейпер HTB

Собственно схема:

как из нее видно, между одним из портов маршрутизатора и другим портом L3 коммутатора настроен VLAN trunk. В этих условиях мы собираемся использовать прозрачный мост и прозрачный прокси-сервер для управления http-трафиком пользователей. Также связку iptables и ipset для блокировки неугодных хостов и сетей, а также динамический шейпер скорости на основе скрипта htb.init.

Представленная схема была реализована на: 

ubuntu-server 12.04.4 LTS (GNU/Linux 3.8.0-35-generic x86_64)

root@bridge:~# uname -a
Linux bridge 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

0. При установке ОС закажем инсталяцию ssh-сервера.

1. Ставим:

apt-get install bridge-utils

apt-get install ebtables

apt-get install  vlan

apt-get install mc

2. Включаем опции ядра для bridge:

echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 1 > /proc/sys/net/bridge/bridge-nf-pass-vlan-input-dev
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables

echo 1 > /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged

3. Конфигурируем /etc/network/interfases:

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

auto eth0.5  #тэг vlan 5 для интерфейса eth0
iface eth0.5 inet manual
vlan_raw_device eth0

auto eth1.5 # #тэг vlan 5 для интерфейса eth1 (далее по аналогии)
iface eth1.5 inet manual
vlan_raw_device eth1

auto br0 # собственно мост у нас не один, в каждом vlan свой.
iface br0 inet static # трафик только одного VLAN
address 0.0.0.0 #  заворачивается на прокси
bridge-ports eth0.5 eth1.5
bridge_stp off

auto eth0.12
iface eth0.12 inet manual
vlan_raw_device eth0

auto eth1.12
iface eth1.12 inet manual
vlan_raw_device eth1

auto br1
iface br1 inet static
address 192.168.1.7 # сервером удобнее всего управлять
netmask 255.255.255.0 #  из клиентской сети (VLAN12).
broadcast 192.168.1.255 #  сообственно поэтому и назначаем 
gateway 192.168.1.1 # нашему мосту указанную адресацию,
bridge-ports eth0.12 eth1.12 # т.к. она соответствует
dns-nameservers 192.168.1.5 #  адресации VLAN 12
dns-search domain.local
bridge_stp off


auto eth0.97
iface eth0.97 inet manual
vlan_raw_device eth0

auto eth1.97
iface eth1.97 inet manual
vlan_raw_device eth1

auto br2
iface br2 inet static
address 0.0.0.0
bridge-ports eth0.97 eth1.97
bridge_stp off

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

4. Теперь перезапустим сеть:

/etc/init.d/networking restart

Или весь сервер:

reboot

Поставим мост в разрыв транка.

Должны суметь залогиниться по ssh на адрес моста.

5. Установим squid:

apt-get install squid

6. Приводим /etc/squid3/squid.conf к примерно такому виду:

http_port 3128 transparent

acl LocalNet src 192.168.1.0/24

http_access allow LocalNet
http_access deny all

Командуем:

squid3 -k reconfigure # эта команда говорит сквиду перечитать и применить конфигурацию не перезагружаясь, и соответственно не разрывая текущих сессий.

Также есть такие команды:

service squid3 start

service squid3 stop

В дальнейшем можно настроить прокси по своему вкусу, статей на тему разнообразных настроек Squid достаточно.

Например,  и вот как настроить анализатор логов lightsquid и web-server lighthttpd, а также закрыть доступ к  lightsquid паролем. В конечном итоге если вдруг будет надо, я смогу предоставить свои конфиги.

7. Издаем команду:

ebtables -t broute -A BROUTING -p IPv4 --ip-destination-port 80 -j redirect --redirect-target ACCEPT

8. Еще одну:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 ! -d 192.168.0.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 3128

заворачиваем пакты из нашей подсети (исключая адресованные в подсеть головного офиса) на порт сквида.

9. Смотрим:

 tail -f /var/log/squid3/access.log

Если видим изменяющиеся значения, значит все ОК - http трафик заворачивается на squid.

10. При настройке squid я не хотел настраивать фильтрацию https, т.к. нашел в сети множество отзывов с проблемами  реализации (подмена squid-ом ssl сертификатов - ssl bump). В связи с этим было принято решение блокировать неугодные адреса с помощью iptables используя ipset. 

Узнаем у Google ip-адреса неугодных ресурсов:

# dig @google-public-dns-a.google.com. mail.yandex.ru

; <<>> DiG 9.8.1-P1 <<>> @google-public-dns-a.google.com. mail.yandex.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48890
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mail.yandex.ru. IN A

;; ANSWER SECTION:
mail.yandex.ru. 3077 IN A 87.250.250.25
mail.yandex.ru. 3077 IN A 93.158.134.25
mail.yandex.ru. 3077 IN A 213.180.193.25
mail.yandex.ru. 3077 IN A 213.180.204.25

;; Query time: 70 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 30 19:04:45 2014
;; MSG SIZE rcvd: 96

11. Ставим ipset:

apt-get install ipset

Добавляем сеты...

a.Создаем список:

ipset -N ip_set_1 iphash

b.Добавляем адреса в сет:

ipset -A ip_set_1  87.250.250.25
ipset -A ip_set_1  93.158.134.25

pset -A ip_set_1  213.180.193.25

ipset -A ip_set_1  213.180.204.25

c.Можно делать сеты для сетей:

ipset -N net_set_1 nethash

d.Добавляем сети в сет:

ipset -A net_set_1 1.1.1.1/32
ipset -A net_set_1 2.2.2.2/24

e.Также можем создать сет для привелегированных пользователей нашей сети:

ipset -N managers iphash

f.Добавляем адреса в сет:

ipset -A managers  192.168.1.111
ipset -A managers  192.168.1.222 

Просмотреть сеты можно командой:

ipset -L

g.Запретим доступ к яндекс почте нашей сети, кроме адресов входящих в managers:

iptables -A FORWARD -m set ! --match-set managers src -p tcp -m tcp -m set --match-set ip_set_1  dst --dport 443 -j DROP

e.Запретим доступ к сетям указанных в сете  net_set_1:

iptables -A FORWARD -m set ! --match-set managers src -p tcp -m tcp -m set --match-set net_set_1   dst --dport 443 -j DROP

h.Сохраним наши сеты. 

Cоздадим файл:

touch /directory/directory2/ipset-save

i.Скомандуем:

ipset -S >  /directory/directory2/ipset-save

(При каждом изменении в сеты сохраняемся.)

j.Устраиваем автозагрузку.

Открываем /etc/rc.local и добавляем в него строку:

cat  /directory/directory2/ipset-save | /usr/sbin/ipset -R

12. Назначим наименьший приоритет задержки пакетам наиболее нуждающимся в нем:

iptables -A OUTPUT -t mangle -p udp -m multiport --dport 53,5060 -j TOS --set-tos Minimize-Delay

iptables -A FORWARD -t mangle -p tcp -m tcp -d 192.168.0.0/24 -j TOS --set-tos 0x10/0x3f

iptables -A FORWARD -t mangle -p udp -m udp -d 192.168.0.0/24 -j TOS --set-tos 0x10/0x3f

13.Смотрим вывод: 

iptables-save

и далее настраиваем автозапуск правил по своему вкусу.

14. Шейпер.

Для начала следует здраво понимать, что ограничиваться, и попадать в очередь (шейпиться), могут только исходящие с интерфейса пакеты, а не входящие т.к. они уже пришли на интерфейс. Соответственно имея устройство с двумя сетевыми интерфейсами, и соответствующим образом настроенным шейпером можно управлять пропускной способностью канала.

a.Перейдем в свою директорию (работаем от рута, как вы заметили):

cd /home/user 

b.Скачиваем скрипт htb.init:

wget http://switch.dl.sourceforge.net/project/htbinit/HTB.init/0.8.5/htb.init-v0.8.5

c.Переименуeм покороче наш скрипт:

mv  htb.init-v0.8.5  htb

и переместим куда следует:

cp htb /usr/sbin

d.сделаем скрипт исполняемым:

chmod +x /usr/sbin/htb

e.теперь создадим файлы и директории необходимые для работы скрипта:

mkdir /etc/sysconfig
mkdir /etc/sysconfig/htb
touch /var/cache/htb.init

f.начнем писать конфиги для нашего шейпера. перейдем:

cd /etc/sysconfig/htb

g.Создаем конфигурационные файлы (eth0 смотрит в 100Gb порт роутера, eth1 в гигабитный порт свитча):

Для исходящего трафика:sudo touch eth0 # Описываем интерфейс eth0
sudo nano eth0

DEFAULT=10 # метка на файл, создаваемый ниже, eth0-2:10.dfl
R2Q=100 # точность ограничений

sudo touch eth0-2.root # корневой класс
sudo nano eth0-2.root

RATE=100Mbit # гарантированная пропускная способность
CEIL=100Mbit # максимальная пропускная способность
BURST=15k # первые 15k без ограничений

sudo touch eth0-2:10.dfl # сюда попадает трафик, не попадающий ни в одно из правил ниже
sudo nano eth0-2:10.dfl

RATE=1024Kbit # гарантированная пропускная способность
CEIL=99Mbit # максимальная пропускная способность
LEAF=sfq # равномерное распределение между участниками очереди.

sudo touch eth0-2:20.rdp # гарантированный канал для rdp
sudo nano eth0-2:20.rdp

RATE=1Mbit # гарантированная пропускная способность
CEIL=2Mbit # максимальная пропускная способность
BURST=15k # первые 15k без ограничений
LEAF=sfq # равномерное распределение между участниками очереди.
RULE=*:3389 # Применять правило для трафика, у которого исходящий порт 3389

MARK=100 # Метка для исходящего трафика (входящий нарезается нормально и без меток).

Маркируем трафик RDP:

iptables -t mangle -A PREROUTING -s 192.168.1.5 -j MARK --set-mark 100 

Соответсвенно 192.168.1.5 адрес терминального сервера.

Для входящего трафика:

sudo touch eth1 # Описываем интерфейс eth1
sudo nano eth1

DEFAULT=10 # метка на файл, создаваемый ниже, eth1-2:10.dfl
R2Q=100 # точность ограничений

sudo touch eth1-2.root # корневой класс
sudo nano eth1-2.root

RATE=330Mbit # гарантированная пропускная способность
CEIL=330Mbit # максимальная пропускная способность
BURST=15k # первые 15k без ограничений

sudo touch eth1-2:10.dfl # сюда попадает трафик, не попадающий ни в одно из правил ниже
sudo nano eth1-2:10.dfl

RATE=1024Kbit # гарантированная пропускная способность
CEIL=300Mbit # максимальная пропускная способность
LEAF=sfq # равномерное распределение между участниками очереди.
PRIO=2 # PRIO задает приоритет класса трафика (1- максимальный, чем больше число — тем меньшt приоритет).

sudo touch eth1-2:20.rdp # гарантированный канал для rdp
sudo nano eth1-2:20.rdp

RATE=1024Kbit # гарантированная пропускная способность
CEIL=2048Kbit # максимальная пропускная способность
BURST=15k # первые 15k без ограничений
LEAF=sfq # равномерное распределение между участниками очереди.
RULE=*:3389 # Применять правило для трафика, у которого порт назначения - rdp-порт
PRIO=1

sudo touch eth1-2:30.100 # ограничиваем скорость для ip 192.168.1.100
sudo nano eth1-2:30.100

RATE=64Kbit # гарантированная пропускная способность

CEIL=64Kbit  # максимальная пропускная способность

BURST=15k # максимальная пропускная способность
LEAF=sfq # равномерное распределение между участниками очереди.
RULE= 192.168.1.100
PRIO=3

Осталось запустить скрипт:

htb compile # тест. можно посмотреть какие правила будут сформированы и ошибки, если есть.
htb start # запуск
htb stop # остановка
htb restart # перезапуск после внесения изменений в файлы конфигурации

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

Максимальный приоритет у входящего и исходящего RDP-трафика (удаленные приложения Remote App также используют этот протокол).

IP-адрес 192.168.1.100 ограничен во входящей скорости до 64 kb/sec, в исходящей скорости ограничений нет.

Подробнее о работе htb.init можно почитать по следующим ссылкам:

http://habrahabr.ru/post/73257/

http://linux-bash.ru/mseti/74-htb.html http://habrahabr.ru/post/73257/

и вообще найти что-то поиском.

15. Графики за N-период по работе сервера:

16. Отчет Lightsquid: