Использование не непрерывных масок сети для классификации и балансировки трафика

Практически любой сетевой инженер, занимающийся эксплуатацией очень не любит десятичную форму записи маски сети. На устройствах под управлением Cisco IOS, каждый раз вводить 255.255.255.252 вместо лаконичного 30 или /30 немного раздражает. К счастью, современные сетевые ОС (Cisco IOS-XR, JunOS, Huawei VRP) позволяют использовать prefix-length вместо десятичной маски хотя бы при конфигурировании IP-адреса на интерфейсе.

Является ли длина префикса эквивалетной заменой маски сети? Почти всегда да, но есть исключения – классификаторы трафика. К примеру, на софтроутерах на базе ядра Linux можно использовать не непрерывные маски сети для классификации трафика с помощью netfilter/iptables:

# iptables -I INPUT -s 0.0.0.0/0.0.0.1 -m comment --comment even -j ACCEPT
# iptables -I INPUT -s 0.0.0.1/0.0.0.1 -m comment --comment odd -j ACCEPT

С помощью таких правил можно посчитать количество трафика, приходящих с чётных и нечётных IP. Для этого использована маска 0.0.0.1 (это не wildcard, это именно маска сети), которая накладывает ограничение на один единственный бит, последний. Первое правило требуется, чтобы последний бит классифицируемого IP-адреса был строго равен нулю, а второе правило, чтобы последние бит IP-адреса был равен 1.

У таких масок есть практическое применение – классификация трафика для его дальнешей балансировки. Рассмотрим пример с NAT-ом.

network-mask

Допустим, вы небольшой оператор или большое предприятие, у вас есть тысяча-другая клиентов, выходящих через 8 внешних IP-адресов (такую сеточку вам в своё время выдал ваш аплинк). Если NAT осуществляется на сервере с Linux-ом, то это будет реализовано примерно следующим образом:

# iptables -t nat -A POSTROUTING -o veth1 -s 100.64.0.0/255.255.0.0 -j SNAT --to-source 203.0.113.0-203.0.113.7 —persistent

Где 100.64/16 – адреса клиентов, а 203.0.113/29 – ваши реальные IP-адреса, veth1 – интерфейс в сторону аплинка. Через какое-то время клиенты стали жаловаться, что иногда стала появляться капча и ваш алпинк выдал вам ещё 8 реальных IP-адресов (198.51.100.0/29), чтобы вы могли в 2 раза снизить кол-во клиентов на один белый IP-адрес. Теперь возникает задача, как разбалансировать серые IP-адреса по 2ум белым сетям (2 сети в “–to-source” добавить нельзя). Можно разделить 100.64/16 на несколько небольших сетей и прописать несколько правил iptables, но такой способ может дать не очень равномерную балансировку (или потребуется большое количество правил iptables). Можно создать 2 ipset-а, в которых записать конкрентные source ip (т.е. половину(например, по принципу чётные/нечётные) серых IP абонентов поместить в один ipset, половину в другой) и обойтись всего двумя правилами iptables. Оба решения выглядят не очень красиво.

В самом деле, классифицировать чётные адреса из сети 100.64.0.0/16 можно следующим образом – 100.64.0.0/255.255.0.1, а нечётные – 100.64.0.1/255.255.0.1. А правило iptables для NAT превратится в 2 таких правила:

# iptables -t nat -A POSTROUTING -o veth1 -s 100.64.0.0/255.255.0.1 -j SNAT --to-source 198.51.100.0-198.51.100.7 —persistent
# iptables -t nat -A POSTROUTING -o veth1 -s 100.64.0.1/255.255.0.1 -j SNAT --to-source 203.0.113.0-203.0.113.7 —persistent

Запустим в интерфейс veth2 трафик с IP-адресов 100.64.0.5-12 и посмотрим таблицу трансляций на роутере:

root@NAT:~# conntrack -L | sort
conntrack v1.4.1 (conntrack-tools): 8 flow entries have been shown.
icmp     1 29 src=100.64.0.10 dst=192.0.2.2 type=8 code=0 id=29088 src=192.0.2.2 dst=198.51.100.1 type=0 code=0 id=29088 mark=0 use=1
icmp     1 29 src=100.64.0.11 dst=192.0.2.2 type=8 code=0 id=29089 src=192.0.2.2 dst=203.0.113.1 type=0 code=0 id=29089 mark=0 use=1
icmp     1 29 src=100.64.0.12 dst=192.0.2.2 type=8 code=0 id=29090 src=192.0.2.2 dst=198.51.100.4 type=0 code=0 id=29090 mark=0 use=1
icmp     1 29 src=100.64.0.5 dst=192.0.2.2 type=8 code=0 id=29082 src=192.0.2.2 dst=203.0.113.4 type=0 code=0 id=29082 mark=0 use=1
icmp     1 29 src=100.64.0.6 dst=192.0.2.2 type=8 code=0 id=29083 src=192.0.2.2 dst=198.51.100.5 type=0 code=0 id=29083 mark=0 use=1
icmp     1 29 src=100.64.0.7 dst=192.0.2.2 type=8 code=0 id=29084 src=192.0.2.2 dst=203.0.113.1 type=0 code=0 id=29084 mark=0 use=1
icmp     1 29 src=100.64.0.8 dst=192.0.2.2 type=8 code=0 id=29085 src=192.0.2.2 dst=198.51.100.4 type=0 code=0 id=29085 mark=0 use=1
icmp     1 29 src=100.64.0.9 dst=192.0.2.2 type=8 code=0 id=29086 src=192.0.2.2 dst=203.0.113.6 type=0 code=0 id=29086 mark=0 use=1

Как видно из этой таблицы, 100.64.0.5 транслировался в 203.0.113.4, 100.64.0.5 в 198.51.100.5, 100.64.0.7 в 203.0.113.1 и т.д. Желаемый результат достигнут.

Теперь рассмотрим пример, когда количество белых сетей (или других сущностей, которые являются элементами действия, а не классификации) не является степенью 2. Например, 3. Чтобы сделать равномерную балансировку по трём правилом, первое, что приходит в голову, это взять остаток от деления на 3 и сравнить с 0, 1 и 2. Но, к сожаленью, netfilter/iptables сам по себе не умеет делать арифметические операции при классификации source ip, поэтому придётся делать с помощью масок. Балансировка в соотношение 3:3:2 будет реализовывать следующим образом:

# iptables ... -s 100.64.0.0/255.255.0.7 ... -j ACTION1
# iptables ... -s 100.64.0.1/255.255.0.7 ... -j ACTION1
# iptables ... -s 100.64.0.2/255.255.0.7 ... -j ACTION1
# iptables ... -s 100.64.0.3/255.255.0.7 ... -j ACTION2
# iptables ... -s 100.64.0.4/255.255.0.7 ... -j ACTION2
# iptables ... -s 100.64.0.5/255.255.0.7 ... -j ACTION2
# iptables ... -s 100.64.0.6/255.255.0.7 ... -j ACTION3
# iptables ... -s 100.64.0.7/255.255.0.7 ... -j ACTION3

Маска 255.255.0.7 означает, что проверяются на совпадение первые 16 бит и последние 3 бита. Чтобы балансировка для трёх действий была более равномерная, можно использовать 4 бита и пропорцию 6:5:5.

P.S. Не только Linux netfilter поддерживает не непрерывные маски. Множество традиционного сетевого оборудования поддерживает такие маски/wildcard-ы при классификации трафика (пример, архив)

Advertisements

2 thoughts on “Использование не непрерывных масок сети для классификации и балансировки трафика

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s