Програмний інтернет шлюз для вже не маленької компанії (Shorewall, OpenVPN, OSPF). Частина 2

Уявляю другу статтю із серії, орієнтованих на «середнього рівня» системних адміністраторів, для досвідчених я навряд чи відкрию щось нове.
У цих статтях ми розглянемо побудову інтернет шлюзу linux, що дозволяє зв'язати кілька офісів компанії, і забезпечити обмежений доступ в мережу, приоритетзацию трафіку (QoS) і просту балансування навантаження з резервуванням каналу між двома провайдерами.
Конкретно в цій частині:
  • Більш детальна настройка Shorewall
  • Страшний і не зрозумілий QoS
  • Балансування навантаження і резервування


А в попередній частині були розглянуті:
  • Найпростіша налаштування Shorewall
  • Страшенно складна настройка dnsmasq
  • Не менш складна налаштування OpenVPN
  • для багатьох продовжують адмінів нетипова, динамічна маршрутизація, на прикладі OSPF

Все описане нижче справедливо для CentOS 7.1 (і вище, 6 серія теж підійде, але з невеликими особливостями)

Поглиблена налаштування Shorewall

Минулого разу ми налаштували досить довірливий і примітивний режим роботи, зараз ми включимо трохи здоровою параної.
Це зробити не складно, давайте внесемо зміни у файл:
policy
#
# Shorewall -- /etc/shorewall/policy
#
# For information about entries in this file, type "man shorewall-policy"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-policy.html
#
###############################################################################
#SOURCE DEST POLICY LOG LIMIT: CONNLIMIT:
# LEVEL BURST MASK
$FW all REJECT
grn all REJECT
tun all REJECT
red DROP all


Нова конфігурація стала простіше, але радіти рано, файл rules значно розпухне:
/etc/shorewall/rules
#
# Shorewall -- /etc/shorewall/rules
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

INCLUDE rules.fw
INCLUDE rules.grn
INCLUDE rules.red
INCLUDE rules.red-dnat
INCLUDE rules.tun


І скористаємося директиви INCLUDE для рознесення правил з кількох файлів:
rules.fw
#
# Shorewall -- /etc/shorewall/rules.fw
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
DNS(ACCEPT) $FW red
Web(ACCEPT) $FW red
FTP(ACCEPT) $FW red
OpenVPN(ACCEPT) $FW red
Ping(ACCEPT) $FW all
OSPF(ACCEPT) $FW tun
SSH(ACCEPT) $FW all



rules.grn
#
# Shorewall -- /etc/shorewall/rules.grn
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
DNS(ACCEPT) grn $FW
Web(ACCEPT) grn red
FTP(ACCEPT) grn red
Ping(ACCEPT) grn all
SSH(ACCEPT) grn all - - - - s:3/min



rules.red
#
# Shorewall -- /etc/shorewall/rules.red
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
OpenVPN(ACCEPT) red $FW
SSH(ACCEPT) red $FW - - - - s:3/min



rules.tun
#
# Shorewall -- /etc/shorewall/rules.tun
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
Ping(ACCEPT) tun $FW
OSPF(ACCEPT) tun $FW
SSH(ACCEPT) tun $FW - - - - s:3/min
SSH(ACCEPT) tun grn - - - - s:3/min



Тепер весь трафік під нашим контролем, пускаємо лише ті протоколи, що хочемо. Зверніть увагу на правила для SSH, ми обмежили частоту сполук до 3-х в хвилину, з кожного ip джерела. Але треба бути дуже обережним з цим параметром, неправильно вказавши ключ s: або d:, можна зробити ваш сервіс легко піддається DDoS атаці. А для Web трафіку (та й взагалі будь-якого), треба враховувати, що багато потенційних клієнтів може сидіти за NAT, і тоді один IP, джерело сполук, може генерувати значну кількість підключень.
Якщо нам потрібно прокинути порти до внутрішніх серверів, зробити це не складно:
rules.red-dnat
#
# Shorewall -- /etc/shorewall/rules.red-dnat
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT(S) PORT(S) DEST LIMIT GROUP
Web(DNAT) red grn:172.16.0.2
#Варіант, якщо у нас кілька зовнішніх адрес, а ми хочемо DNAT тільки з одного з них:
#Web(DNAT) red grn:172.16.0.2 - - - 192.168.10.37
#Варіанти, все руками:
#DNAT red grn:172.16.0.2 tcp 80,443
#DNAT red grn:172.16.0.2 tcp 80,443 - 192.168.10.37
#Варіант з нестандартними портами:
#DNAT red grn:172.16.0.2:80 tcp 8080



Проста балансування навантаження і резервування в Shorewall

Скажу відразу, і балансування і резервування, лише настроюються за допомогою Shorewall, сам він не надає ніякого функціоналу з виявлення пропажі каналу або рівномірному розподілу реального навантаження.
Вся настройка зводиться до редагування одного файлу:
providers
#
# Shorewall -- /etc/shorewall/providers
#
# For information about entries in this file, type "man shorewall-providers"
#
# For additional information, see http://shorewall.net/MultiISP.html
#
############################################################################################
#NAME NUMBER MARK DUPLICATE GATEWAY INTERFACE OPTIONS COPY
pr1 1 0x10000 - $IF_RED1 $GW_RED1 fallback=1
pr2 2 0x20000 - $IF_RED2 $GW_RED2 fallback=4


Якщо хто пам'ятає, в минулій статті була секція «Shorewall.conf». Вона потрібна якраз для налаштування маркування пакетів і роботі з провайдерами. Там ми задали, які біти з мітки пакету, задають ідентифікатор провайдера, які просто мітки (я такі поки ніде не використовую, але Shorewall сам їх здійснює, для своїх потреб), а які для відстеження з'єднань.
Тут ми описали двох провайдерів, поставили як маркувати пакети для них, на якому інтерфейсі кожен сидить і який у кого шлюз.
Ось стовпець OPTIONS, треба пояснити трохи. Тут ключ fallbaсk змушує згенерувати додаткові правила маршрутизації, на випадок якщо балансувальні не зможуть обробити пакет (інтерфейс приліг до прикладу), а цифра вказує вага інтерфейсу. Чим вагу більше, тим частіше в інтерфейс будуть надходити нові сполуки (використовується в результаті відносний вагу, у кого в пропорції вага вище, туди і трафік частіше, задавати велике значення ваги не рекомендується). Балансування відбувається за принципом roundrobin вже самим ядром і базується на факті встановлення з'єднання за маршрутом клієнт-сервер (в якості клієнта ваш маршрутизатор, а сервер відповідно, віддалений сервер). При цьому маршрути кешуються на деякий час, і виходить такий ефект: хто-то в локалці, поліз до прикладу на якийсь сайт (у якого один IP), трафік пішов через провайдера 1, потім ще хтось поліз туди ж, і трафік побіжить знову через провайдера 1 (якщо кеш не встиг скинеться). Ще може вийде, що у вас не симетричні провайдери, як у прикладі, і так пощастить, кожне четверте з'єднання, що потрапляють на першого провайдера, і виявиться самим «важким», а ми хотіли цього уникнути… Тут вже простих рішень немає, і ця стаття вам ніяк не допоможе.
Давши команду:
shorewall show routing

Можна побачити побудовану схему маршрутизації:
Приклад маршрутизації
Shorewall 5.0.2.1 Routing at cent1.domain.local - Пт січ 8 23:41:30 MSK 2016


Routing Rules

0: from all local lookup
999: from all main lookup
10000: from all fwmark 0x10000/0xff0000 lookup pr1
10001: from all fwmark 0x20000/0xff0000 lookup pr2
20000: from 192.168.10.37 lookup pr1
20000: from 192.168.10.36 lookup pr2
32765: from all lookup balance
32767: from all lookup default

Table balance:


Table default:

default nexthop via 192.168.10.1 dev eth0 weight 1 nexthop via 192.168.10.1 dev eth2 weight 1

Table local:

local 192.168.10.37 dev eth0 proto kernel scope host src 192.168.10.37
local 192.168.10.36 dev eth2 proto kernel scope host src 192.168.10.36
local 172.16.3.1 dev tap0 proto kernel scope host src 172.16.3.1
local 172.16.3.129 dev tap1 proto kernel scope host src 172.16.3.129
local 172.16.248.1 dev lo proto kernel scope host src 172.16.248.1
local 172.16.0.1 dev eth1 proto kernel scope host src 172.16.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 192.168.10.255 dev eth2 proto kernel scope link src 192.168.10.36
broadcast 192.168.10.255 dev eth0 proto kernel scope link src 192.168.10.37
broadcast 192.168.10.0 dev eth2 proto kernel scope link src 192.168.10.36
broadcast 192.168.10.0 dev eth0 proto kernel scope link src 192.168.10.37
broadcast 172.16.3.255 dev tap1 proto kernel scope link src 172.16.3.129
broadcast 172.16.3.128 dev tap1 proto kernel scope link src 172.16.3.129
broadcast 172.16.3.127 dev tap0 proto kernel scope link src 172.16.3.1
broadcast 172.16.3.0 dev tap0 proto kernel scope link src 172.16.3.1
broadcast 172.16.248.1 dev lo proto kernel scope link src 172.16.248.1
broadcast 172.16.1.255 dev eth1 proto kernel scope link src 172.16.0.1
broadcast 172.16.0.0 dev eth1 proto kernel scope link src 172.16.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

Table main:

192.168.10.1 dev eth2 scope link src 192.168.10.36
172.16.3.1 dev tap0 proto zebra
172.16.3.129 dev tap1 proto zebra
172.16.248.2 via 172.16.3.2 dev tap0 proto zebra metric 13
172.16.12.129 via 172.16.3.2 dev tap0 proto zebra metric 3
172.16.11.1 via 172.16.3.2 dev tap0 proto zebra metric 3
172.16.3.128/25 dev tap1 proto kernel scope link src 172.16.3.129
172.16.3.0/25 dev tap0 proto kernel scope link src 172.16.3.1
192.168.10.0/24 dev eth2 proto kernel scope link src 192.168.10.36 metric 101
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.37 metric 100
172.16.8.0/23 via 172.16.3.2 dev tap0 proto zebra metric 13
172.16.0.0/23 dev eth1 proto kernel scope link src 172.16.0.1 metric 100

Table pr1:

192.168.10.1 dev eth0 scope link src 192.168.10.37
default via 192.168.10.1 dev eth0 src 192.168.10.37

Table pr2:

192.168.10.1 dev eth2 scope link src 192.168.10.36
default via 192.168.10.1 dev eth2 src 192.168.10.36


Але, не все так погано, і навіть так воно працює гідно (до речі, так воно працює у більшості рішень, для «чесної» балансування використовуються досить не прості рішення, які часто без підтримки на стороні провайдерів (обох) не працюють).
Доповнений файл змінних:
params
#
# Shorewall -- /etc/shorewall/params
#
# Assign any variables that you need here.
#
# It is suggested that variable names begin with an upper case letter
# to distinguish them from variables used within the internally
# Shorewall programs
#
# Example:
#
# NET_IF=eth0
# NET_BCAST=130.252.100.255
# NET_OPTIONS=routefilter,norfc1918
#
# Example (/etc/shorewall/interfaces record):
#
# net $NET_IF $NET_BCAST $NET_OPTIONS
#
# The result will be the same as if the record had been written
#
# net eth0 130.252.100.255 routefilter,norfc1918
#
###############################################################################
IF_RED1=eth0
GW_RED1=192.168.10.1
IF_RED2=eth2
GW_RED2=detect
IF_GRN=eth1
NET_GRN=172.16.0.0/23
IF_TUN=tap+
#LAST LINE -- DO NOT REMOVE


Можна помітити, що у другого провайдера шлюз вказано ключове слово «detect», яке працює на з'єднаннях з динамічною адресацією. Для деякий випадків (наприклад PPtP), сам Shorewall не може коректно визначити шлюз, для чого використовується файл з допоміжним скриптом:
findgw
#
# Shorewall version 4 - Findgw File
#
# /etc/shorewall/findgw
#
# The code in this file is executed when Shorewall is trying to detect the
# gateway through an interface in /etc/shorewall/providers that has GATEWAY
# specified as 'detect'.
#
# The function should echo the IP address of the gateway knows what if it
# it is the name of the interface is in $1.
#
# See http://shorewall.net/shorewall_extension_scripts.htm for additional
# information.
#
###############################################################################
LANG='C' nmcli --terse --fields IP6.GATEWAY device show ${1} | cut -f2- -d':' #IPv6
LANG='C' nmcli --terse --fields I4.GATEWAY device show ${1} | cut -f2- -d':' #IPv4


І доповнить все це скрипт для NetworkManager (більш проста версія була в минулій статті, і вона не враховувала, що після підняття інтерфейсу, Shorewall не завжди коректно будує політику маршрутизації, тому ми для таких інтерфейсів просто його перезапускаємо).
/etc/NetworkManager/dispatcher.d/30-shorewall.sh
#!/bin/bash

IF=$1 # ім'я мережевого інтерфейсу, з яким пов'язано подія
STATUS=$2 # новий стан мережного інтерфейсу
function check_prov() {
PARAM=$(grep -v '^#' /etc/shorewall/params | grep $1 | cut -d '=' -f 1)
if [ -z "$PARAM" ]; then
grep -v '^#' /etc/shorewall/providers | grep -q $1
[[ $? == 0 ]] && shorewall restart
else
grep -v '^#' /etc/shorewall/providers | grep -q $PARAM
[[ $? == 0 ]] && shorewall restart
fi
}
case $STATUS in
up)
# команди виконуються після встановлення з'єднання
shorewall enable $IF
shorewall6 enable $IF
check_prov $IF
;;
down)
# команди виконуються після розриву з'єднання
shorewall disable $IF
shorewall6 disable $IF
check_prov $IF
;;
esac


Але, чи можна направити якийсь трафік конкретного провайдера? Відповідь Так!
mangle
#
# Shorewall -- /etc/shorewall/mangle
#
# For information about entries in this file, type "man shorewall-mangle"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
# For usage in selecting among multiple ISPs, see
# http://shorewall.net/MultiISP.html
#
# See http://shorewall.net/PacketMarking.html for a detailed description of
# the Netfilter/Shorewall packet marking mechanism.
#
####################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP
# PORT(S) PORT(S)
MARK(0x20000):P 172.16.0.4 0.0.0.0/0!172.16.0.0/12


Тут ми позначили весь трафік від 172.16.0.4 в будь-яку мережу, крім 172.16.0.0/12, міткою другого провайдера. Умови можуть бути і хитріше, треба тільки враховувати, для трафіку згенерованого на нашому шлюзі, правила потрібно прибрати ":P".

Страшний і жахливий QoS

Відразу треба пояснити ось що: по справжньому регулювати швидкість ми можемо тільки при відправці. Вхідний трафік, вже дійшов до нашого інтерфейсу минаючи всі вузькі місця, і штовхаючись в чергах, за право опинитися у нас на порозі.
Але зневірятися рано, і є механізми, не настільки витончені і надійні, як хотілося б, але вирішують цю проблему. У мережах на базі протоколів сімейства IP, це вирішується таким чином:
Джерело плавно нарощує швидкість відправлення, поки відповіді про доставку (пакети ACK в протоколі TCP) взагалі приходять або приходять з нормальною затримкою. Якщо є втрати або зростає затримка ACK, швидкість знижується. Потім, через деякий проміжок часу, швидкість намагаються знову підняти. І так відбувається до закінчення передачі.
А як же UDP? А з ним все просто, немає контролю доставки, немає головного болю. Відправив і ОК (це нехай одержувач мучиться).
Звичайно, в чистому вигляді UDP зазвичай не використовують у складних завданнях з передачі даних. Цей протокол зазвичай використовують як основу при реалізації свого варіанта контролю доставки (можна сказати, своїх реалізацій TCP, у випадках, коли стандартний не влаштовує). Тому в багатьох протоколах працюють поверх UDP, контроль доставки теж є. Що не скасовує можливості слати безперервний потік UDP на всю міць, забиваючи канал зв'язку мети (той самий варіант DDoS).
Як же ми можемо організувати пріоритет трафіку і виділення смуги пропускання вхідного трафіку? Відповідь є вище: створити затримку в отриманні на своїй стороні (як наслідок, затримку в генерації ACK) або якщо затримка непристойно висока, пакет відкинути.

В Linux це реалізується створенням псевдо-інтерфейсу IFB, який як би встає між фізичним інтерфейсом і самим шлюзом, пропускаючи через себе вхідний трафік. Трафік входить у фізичний інтерфейс (ми його вже взяли на ньому), і тут же відправляється в IFB, який вже регулює, з якою швидкістю і в якому порядку пропустити цей трафік (або взагалі відкинути).
У налаштуванні нам допоможе Shorewall (хоча можна і в /etc/modprobe.d прописати):
/etc/shorewall/init
#
# Shorewall -- /etc/shorewall/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall start", "shorewall-reload" або "shorewall restart" command.
#
# For additional information, see
# http://shorewall.net/shorewall_extension_scripts.htm
#
###############################################################################
modprobe ifb numifbs=3
ip link set ifb0 up
ip link set ifb1 up
ip link set ifb2 up


Тут тривіально, створили три псевдо-інтерфейсу IFB і їх підняли.
Далі опишемо інтерфейси, на яких ми будемо регулювати трафік:
tcdevices
#
# Shorewall -- /etc/shorewall/tcdevices
#
# For information about entries in this file, type "man shorewall-tcdevices"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
#
###############################################################################
#NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED
#INTERFACE INTERFACES
1:$NET_GRN - 1000mbit hfsc,classify
2:ifb1 - 1000mbit hfsc,classify $NET_GRN
3:$NET_RED1 - 10mbit hfsc,classify
4:ifb0 - 10mbit hfsc,classify $NET_RED1
5:$NET_RED2 - 10mbit hfsc,classify
6:ifb2 - 10mbit hfsc,classify $NET_RED2


Тут ми в явному вигляді, задаємо номера використовуваних інтерфейсів (якщо не поставити, Shorewall пронумерует їх у порядку оголошення файлі), асоціювали IFB з реальними інтерфейсами, поставили максимальну вихідну швидкість (пам'ятаємо, тільки її і ми регулюємо, і інтерфейс ifb по суті це входить лінія) і задали дисципліни класифікації і що трафік ми будемо класифікувати.
Опишемо ті самі класи:
tcclasses
#
# Shorewall -- /etc/shorewall/tcclasses
#
# For information about entries in this file, type "man shorewall-tcclasses"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
#
###############################################################################
#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
1:1:2 - 1mbit 3mbit 2 default
1:1:3 - 256kbit full 1
2:1:2 - 1mbit 3mbit 2 default
2:1:3 - 256kbit full 1
3:1:2 - 1mbit 3mbit 2 default
4:1:3 - 256kbit full 1
5:1:2 - 1mbit 3mbit 2 default
5:1:3 - 256kbit full 1
6:1:2 - 1mbit 3mbit 2 default
6:1:3 - 256kbit full 1


Поки не будемо робити нічого складного (і тому цікавого і корисного), поки прив'яжемо до кожного інтерфейсу (включаючи IFB) по два класи.
У першому стовпці ми асоціюємо інтерфейс з класами. <номер інтерфейсу>:<номер батьківського класу>:<номер описуваного класу>.
На інтерфейсі завжди є клас 1, який ми, по суті, описали в tcdevices.
Далі, пакети ми не маркували (при класифікації цього не можна зробити), і тому стовпець використовувати не будемо, далі йде найцікавіше, мінімально гарантована смуга пропускання, і максимально можлива (не більше ніж така у класу батька), для даного класу. Пріоритет задасть порядок вирішення спірної ситуації (у кого менше, той і піде першим, якщо вийшов за межі гарантованої смуги, і вона вже кимось іншим зайнята повністю). У висновку йдуть опції, default говорить про те, що якщо фільтрами нічого не знайдено (пакети не віднесені до класів), то присвоїти їм клас за замовчуванням).
Далі, так історично склалося, що правила класифікації реальних інтерфейсів, знаходяться у файлі:
mangle
#
# Shorewall -- /etc/shorewall/mangle
#
# For information about entries in this file, type "man shorewall-mangle"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
# For usage in selecting among multiple ISPs, see
# http://shorewall.net/MultiISP.html
#
# See http://shorewall.net/PacketMarking.html for a detailed description of
# the Netfilter/Shorewall packet marking mechanism.
#
####################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP
# PORT(S) PORT(S)
CLASSIFY(1:3) 0.0.0.0/0 0.0.0.0/0 tcp - 80,443
CLASSIFY(3:3) 0.0.0.0/0 0.0.0.0/0 tcp 80,443


А для віртуальних IFB в:
tcfilters
#
# Shorewall -- /etc/shorewall/tcfilters
#
# For information about entries in this file, type "man shorewall-tcfilters"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
#
########################################################################################################
#INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH PRIORITY
#CLASS PORT(S) PORT(S)
2:3 0.0.0.0/0 0.0.0.0/0 tcp - 80,443
4:3 0.0.0.0/0 0.0.0.0/0 tcp 80,443


У прикладі вище, я помістив вхідний трафік від HTTP(S) сервера в клас з номером 3 на фізичному інтерфейсі, і на віртуальний, асоційований з ним, і вихідний я зробив аналогічно, але «розгорнувши порти». Дуже уважно поставтеся до того, що з'єднання часто двунаправленны, і розписувати їх класифікацію треба окремо для кожного напряму, не залежно від того, хто ініціював, клієнт або сервер.
Саме тут і починає тріщати дах. Для розуміння допоможе картинка (прошу ногами особливо не бити, Visio працювати толком не вмію).

Різати трафік у підсумку можна на різних ділянках, не застосовуючи IFB, якщо у вас один провайдер, а сам шлюз, трафік не бере (не є його одержувачем). Якщо провайдерів більше, а шлюз сам активно бере трафік (наприклад обслуговує VPN), тоді без IFB викручуватися не легко.

P. S.
У наступній статті я планую детальніше зупиниться на QoS, особливо в світлі поширення VoIP технологій. Тема велика, і потрібно все добре спланувати. Якщо вас цікавить якийсь аспект більш детально, пишіть запит коментарі, я врахую побажання в наступній статті.

Пізнавальними ці статті? (Мотивуючий опитування)

/>
/>


<input type=«radio» id=«vv70707»
class=«radio js-field-data»
name=«variant[]»
value=«70707» />
Так
<input type=«radio» id=«vv70709»
class=«radio js-field-data»
name=«variant[]»
value=«70709» />
Скоріше так
<input type=«radio» id=«vv70711»
class=«radio js-field-data»
name=«variant[]»
value=«70711» />
Для мене нічого нового
<input type=«radio» id=«vv70713»
class=«radio js-field-data»
name=«variant[]»
value=«70713» />
Немає

Проголосувало 20 осіб. Утрималося 13 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.