3.4.1. Просмотр списка сетевых интерфейсов с помощью утилиты ip

      
[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop 
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp       
      

Здесь приведен результат работы команды ip link list на моем домашнем маршрутизаторе ( с "поднятым" NAT), у вас он может несколько отличаться. Я поясню часть того, что вы видите, но не все, а только то, что нас интересует в данный момент.

Первым в списке находится локальный (loopback) интерфейс. В принципе, при крнфигурировании ядра, можно отключить поддержку этого интерфейса, но я бы не советовал этого делать. Размер максимального блока передачи данных (MTU -- Maximum Transfer Unit) для этого интерфейса составляет 3924 октета, и для него отсутствует очередь, поскольку он не соответствует никакому физическому устройству и существует только в "воображении" ядра.

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

Обратите внимание на отсутствие IP-адресов в листинге. iproute отделяет понятие "интерфейса" от понятия "IP-адреса". При назначении нескольких IP-адресов одному интерфейсу (IP-алиасинг), понятие IP-адреса становится достаточно расплывчатым.

Зато показываются MAC-адреса -- аппаратные идентификаторы сетевых интерфейсов.

3.4.2. Просмотр списка IP-адресов с помощью утилиты ip

      
[ahu@home ahu]$ ip address show        
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop 
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp 
    inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0      
      

Этот листинг содержит более подробную информацию. Здесь показаны все IP-адреса, и каким интерфейсам они принадлежат. Здесь "inet" соответствует термину "Internet (IPv4)". Существует целый ряд типов сетевых адресов, но нас они пока не интересуют.

Взглянем поближе на интерфейс eth0. Из листинга видно, что ему назначен адрес "inet" -- 10.0.0.1/8, где "/8" определяет число бит, соответствующих адресу сети. Таким образом, для адресации хостов в сети у нас остается 32 - 8 = 24 бита, что соответствует адресу сети -- 10.0.0.0 и маске сети -- 255.0.0.0.

Это говорит о том, что любой хост в этой сети, например 10.250.3.13, будет непосредственно доступен через наш интерфейс с IP-адресом 10.0.0.1.

Для ppp0 применима та же концепция, хотя числа в IP-адресе отличаются. Ему присвоен адрес - 212.64.94.251, без маски сети. Это означает, что он обслуживает соединение типа "точка-точка" (point-to-point), и что каждый адрес, за исключением 212.64.94.251, является удаленным. Но и это еще не все. Для этого интерфейса указывается адрес другого конца соединения -- 212.64.94.1. Здесь число "/32" говорит о том, что это конкретный IP-адрес и он не содержит адреса сети.

Очень важно, чтобы вы поняли суть этой концепции. Если у вас возникают какие либо затруднения, обращайтесь к документации, упомянутой в начале этого HOWTO.

Вы наверняка обратили внимание на слово "qdisc". Оно обозначает дисциплину обработки очереди (Queueing Discipline). Позднее мы коснемся этой темы подробнее.

3.4.3. Просмотр списка маршрутов с помощью утилиты ip

Итак, мы теперь знаем, как можно отыскать адреса 10.x.y.z, и как обратиться к адресу 212.64.94.1. Однако этого недостаточно, поскольку нам необходимо иметь возможность общения с внешним миром. Интернет доступен нам через ppp-соединение, которое объявляет, что хост с адресом 212.64.94.1, готов передать наши пакеты во внешний мир и вернуть результаты обратно.

      
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251 
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1 
127.0.0.0/8 dev lo  scope link 
default via 212.64.94.1 dev ppp0      
      

Этот листинг достаточно "прозрачен". Первые 3 строки сообщают сведения, которые нами уже обсуждались выше. Последняя строка говорит о том, что внешний мир доступен через 212.64.94.1 -- шлюз, заданный по-умолчанию. То что это шлюз, видно благодаря наличию слова "via" (в переводе с англ. -- "через"). Этот шлюз (с адресом 212.64.94.1) готов перенаправлять наши пакеты в Интернет и возвращать обратно результаты наших запросов.

Для примера, более "старая" утилита route, дает такой результат на моей машине:

      
[ahu@home ahu]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
212.64.94.1     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         212.64.94.1     0.0.0.0         UG    0      0        0 ppp0      
      

4.2.1. Раздельный доступ

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

Давайте определим некоторые переменные. Пусть $IF1 будет именем первого интерфейса (if1 на рисунке), а $IF2 -- именем второго. Тогда $IP1 будет IP адресом $IF1 , а $IP2 -- IP адресом $IF2 . Далее, $P1 это IP-адрес шлюза провайдера 1, а $P2 -- IP адрес шлюза провайдера 2. Наконец, $P1_NET это IP сеть, к которой принадлежит $P1 , а $P2_NET -- сеть, к которой принадлежит $P2 .

Создадим две дополнительные таблицы маршрутизации, скажем T1 и T2. Добавим их в файл /etc/iproute2/rt_tables. Теперь можно настроить эти таблицы следующими командами:

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
        

Теперь нужно настроить главную таблицу маршрутизации. Хорошо бы маршрутизировать пакеты для сетей провайдеров через соответствующие интерфейсы. Обратите внимание на аргумент `src', который обеспечивает правильный выбор исходного IP-адреса.

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2        
        

ip route add default via $P1       
        

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2        
        

Заметка читателя Рода Роака (Rod Roark): ' если $P0_NET это локальная сеть, а $IF0 -- соответствующий ей интерфейс, желательно задать следующие команды: ip route add $P0_NET dev $IF0 table T1 ip route add $P2_NET dev $IF2 table T1 ip route add 127.0.0.0/8 dev lo table T1 ip route add $P0_NET dev $IF0 table T2 ip route add $P1_NET dev $IF1 table T2 ip route add 127.0.0.0/8 dev lo table T2

4.2.2. Распределение нагрузки.

Второй вопрос заключается в балансировке нагрузки между двумя провайдерами. Это не сложно, если у вас уже настроен раздельный доступ, описанный в предыдущем разделе.

Вместо выбора одного из провайдеров в качестве маршрута по-умолчанию, вы настраиваете т.н. многолучевой (multipath) маршрут. В стандартном ядре это обеспечит балансировку нагрузки между двумя провайдерами. Делается это следующим образом (повторюсь, мы основываемся на примере из раздела Раздельный доступ):

ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1           
           

Обратите внимание, что балансировка не будет идеальной, так как она основывается на маршрутах, а маршруты кэшируются. Это означает, что маршруты к часто посещаемым сайтам не будут проходить через разных провайдеров.

Если вы действительно интересуетесь этим, вам стоит посмотреть на патчи Юлиана Анастасова (Julian Anastasov), расположеные по адресу http://www.ssi.bg/~ja/#routes. Они могут вам помочь.

5.3.1. Тоннелирование IPv4.

Давайте сначала разберемся с тоннелированием IPv4:

Допустим у вас есть три сети: внутренние сети A и B, и промежуточная сеть C (например, Internet).

Сеть А:

сеть          10.0.1.0
маска         255.255.255.0
маршрутизатор 10.0.1.1        
        

сеть B:

сеть          10.0.2.0
маска         255.255.255.0
маршрутизатор 10.0.2.1        
        

Мы полагаем, что сеть C передает пакеты от A к B и наоборот. Как и почему -- это нас не интересует.

На маршрутизаторе сети A, вам необходимо сделать следующее:

        
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb          
        

Вторая строка переводит устройство в активное состояние.

В третьей строке мы присваиваем созданному интерфейсу born адрес 10.0.1.1. Это нормально для небольших сетей, но когда вы становитель "шахтером" (т.е. создаете МНОГО тоннелей), возможно вам нужно будет выбрать другой диапазон адресов для тоннельных интерфейсов (в этом примере мы могли бы использовать 10.0.3.0).

В четвертой строке определяется маршрут к сети B. Обратите внимание на формат представления сетевой маски. Если вы не знакомы с такой нотацией, краткое пояснение: записываете сетевую маску в двоичной форме и считаете все "единички". Если вы не знаете как это делается, тогда просто запомните, что 255.0.0.0 это /8, 255.255.0.0 -- /16, а 255.255.255.0 -- /24. Да, а 255.255.254.0 выглядит как /23, если вам интересно.

Но хватит об этом, продолжим настройку маршрутизатора сети B.

ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta        
        

ip link set netb down
ip tunnel del netb        
        

5.3.2. Тоннелирование IPv6.

За кратким описанием адресации IPv6 обратитесь к шеcтой главе: Тоннелирование IPv6 при помощьи Cisco и/или 6bone.

Продолжим с тоннелями.

Предположим у вас есть сеть IPv6 и вы хотите подключить ее к 6bone, или к другу.

Network 3ffe:406:5:1:5:a:2:1/96        
        

ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone         
        

Тоннели GRE на сегодняшний день являются самыми предпочтительными. Это стандарт, который широко применяется за пределами сообщества Linux, а потому представляет собой Хороший выбор.

7.2.1. Теория.

Как уже говорилось ранее, в случае автоматической настройки, обновление и обмен ключевой информацией выполняется без нашего участия. Очевидно, что при этом "на лету" создаются защищенные каналы (SA), которые, как это ни странно, не обеспечиваются какой-либо политикой безопасности.

Таким образом, чтобы воспользоваться преимуществами IKE, необходимо установить для него политику безопасности. Для этого создается такая политика, которая не связана с каким-либо конкретным защищенным каналом (SA). Когда ядро обнаружит такую политику, то оно передаст ее демону IKE, который в свою очередь будет использовать ее в своей работе.

Повторюсь еще раз: Политика Безопасности определяет -- ЧТО следует предпринять в том или ином случае, а Контекст Безопасности (защищенный канал) определяет -- КАК производить обмен данными. Автоматическое управление ключевой информацией позволяет нам избежать неприятностей только с определением "ЧТО предпринять".

7.2.2. Пример.

Kame racoon имеет достаточно неплохие настройки по-умолчанию, так что мы не будем их касаться. Как уже говорилось выше, мы должны определить только политику безопасности, оставив право на создание защищенных каналов за демоном IKE.

В этом примере, мы опять вернемся к нашим хостам 10.0.0.11 и 10.0.0.216, и еще раз попробуем установить защищенное соединение между ними, но на сей раз с помощью racoon. Для упрощения конфигурации будем использовать предопределенные ключи, сертификаты X.509 будут обсуждаться в отдельном разделе (см. раздел Автоматизация с использованием сертификатов X.509).

Мы будем придерживаться конфигурации, заданной практически по-умолчанию и идентичной для обоих хостов:

    
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote anonymous
{
 	exchange_mode aggressive,main;
 	doi ipsec_doi;
 	situation identity_only;

	my_identifier address;

	lifetime time 2 min;   # sec,min,hour
	initial_contact on;
	proposal_check obey;	# obey -- повиноваться, требованиям и ограничениям

	proposal {
	        encryption_algorithm 3des;
	        hash_algorithm sha1;
	        authentication_method pre_shared_key;
	        dh_group 2 ;
	}
}
 
sainfo anonymous
{
 	pfs_group 1;
 	lifetime time 2 min;
 	encryption_algorithm 3des ;
 	authentication_algorithm hmac_sha1;
		compression_algorithm deflate ;
}      
      

Многие из параметров настройки, на мой взгляд, могут быть удалены, поскольку они достаточно близки к заданным по-умолчанию. Здесь приведены два анонимных параметра, которые применяются ко всем удаленным хостам, за счет чего достигается простота конфигурации. На данный момент пока нет особой потребности в создании настроек для каждого конкретного хоста.

Кроме того, в настройках задана самоидентификация на основе собственного IP-адреса (my_identifier address). Затем объявляются используемые алгоритмы шифрования -- 3des и sha1 и указывается, что будут использоваться предопределенные ключи, расположенные в файле psk.txt.

Содержимое файлов psk.txt с ключами приводится ниже. Для разных хостов они различны. Для хоста 10.0.0.11:

10.0.0.216	password2

10.0.0.11	password2

Назначте владельцем файла суперпользователя (root), и установите права доступа 0600, в противном случае racoon откажется доверять их содержимому.

Теперь можно приступить к формированию политик безопасности, которые в данной ситуации достаточно просты и незамысловаты. На хосте 10.0.0.216:

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
	esp/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
	esp/transport//require;
        

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
	esp/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
	esp/transport//require;        
        

12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA
  request for 10.0.0.11 queued due to no phase1 found.
12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
  phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]
12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode.
12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: 
  KAME/racoon
12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find
  the proper pskey, try to get one by the peer's address.
12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA
  established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680
12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 
  negotiation: 10.0.0.216[0]<=>10.0.0.11[0]
12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: 
  ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b)
12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
  ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)          
        

10.0.0.216 10.0.0.11 
	esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000)
	E: 3des-cbc  5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
	A: hmac-sha1  c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Nov 11 12:28:45 2002	current: Nov 11 12:29:16 2002
	diff: 31(s)	hard: 600(s)	soft: 480(s)
	last: Nov 11 12:29:12 2002	hard: 0(s)	soft: 0(s)
	current: 304(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 3	hard: 0	soft: 0
	sadb_seq=1 pid=17112 refcnt=0
10.0.0.11 10.0.0.216 
	esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000)
	E: 3des-cbc  d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
	A: hmac-sha1  41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Nov 11 12:28:45 2002	current: Nov 11 12:29:16 2002
	diff: 31(s)	hard: 600(s)	soft: 480(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 231(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 2	hard: 0	soft: 0
	sadb_seq=0 pid=17112 refcnt=0          
        

10.0.0.11[any] 10.0.0.216[any] tcp
	in ipsec
	esp/transport//require
	created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
	lifetime:0(s) validtime:0(s)
	spid=3616 seq=5 pid=17134
	refcnt=3
10.0.0.216[any] 10.0.0.11[any] tcp
	out ipsec
	esp/transport//require
	created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
	lifetime:0(s) validtime:0(s)
	spid=3609 seq=4 pid=17134
	refcnt=3        
        

7.2.3. Автоматизация с использованием сертификатов X.509

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

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

Процедура создания ключей относительно проста, хотя и требует выполнения некоторых дополнительных действий. Ниже рассматривается пример использования, для этих целей, утилиты openssl.

$ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \
  laptop.private -outform PEM -out request.pem          
          

Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:Delft
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced
Routing & Traffic Control
Organizational Unit Name (eg, section) []:laptop
Common Name (eg, YOUR name) []:bert hubert
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:          
          

$ openssl x509 -req -in request.pem -signkey laptop.private -out \
  laptop.public
Signature ok
subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \
  Control/OU=laptop/CN=bert hubert/[email protected]
Getting Private key          
          

---

7.2.3.2. Настройка и запуск.

Теперь, после того как мы создали открытый и секретный ключи, мы можем передать их racoon.

Вернемся к нашей предыдущей конфигурации хостов 10.0.0.11 ('upstairs') и 10.0.0.216 ('laptop').

В файл racoon.conf, на 10.0.0.11, добавим:

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.216
{
 	exchange_mode aggressive,main;
	my_identifier asn1dn;
	peers_identifier asn1dn;

	certificate_type x509 "upstairs.public" "upstairs.private";

	peers_certfile "laptop.public";
	proposal {
                encryption_algorithm 3des;
		hash_algorithm sha1;
		authentication_method rsasig;
		dh_group 2 ;
	}
}          
          

Тем самым сообщив racoon, что сертификаты находятся в каталоге /usr/local/etc/racoon/certs/. Кроме того, добавим раздел, описывающий удаленный компьютер 10.0.0.216.

Строки asn1dn говорят о том, что локальный и удаленный идентификаторы следует извлекать из открытых ключей. Это -- 'subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic Control/OU=laptop/CN=bert hubert/[email protected]' из листинга, приведенного выше.

Строка certificate_type указывает имена файлов с локальными открытым и секретным ключами. peers_certfile указывает, что открытый ключ удаленного узла следует взять из файла laptop.public.

Блок proposal остается, по сравнению с предыдущей конфигурацией, практически без изменений, за исключением authentication_method для которого теперь указано rsasig, что означает -- использовать для аутентификации RSA открытый/секретный ключи.

Аналогичные изменения вносятся и в конфигурацию хоста 10.0.0.216:

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.11
{
 	exchange_mode aggressive,main;
	my_identifier asn1dn;
        peers_identifier asn1dn;

        certificate_type x509 "laptop.public" "laptop.private";
 
 	peers_certfile "upstairs.public";

	proposal {
                encryption_algorithm 3des;
	        hash_algorithm sha1;
		authentication_method rsasig;
	        dh_group 2 ;
	}
}          
          

После внесения изменений в конфигурацию, нам необходимо разместить файлы ключей. На машине 'upstairs', в каталоге /usr/local/etc/racoon/certs, следует разместить файлы upstairs.private, upstairs.public и laptop.public.

ВНИМАНИЕ! Владельцем этого каталога должен быть суперпользователь (root) и ему должны быть назначены права доступа 0700, иначе racoon откажется работать с ним!

А на машине 'laptop', опять же в каталоге /usr/local/etc/racoon/certs, нужно разместить файлы laptop.private, laptop.public и upstairs.public. Короче говоря, на каждом хосте должны размещаться его собственные открытый и секретный ключи, а так же открытые ключи удаленных систем.

Проверьте настройки политик безопасности (выполните строки spdadd, из раздела Пример). Теперь запустите racoon -- все должно работать.

7.2.4. Как сохранить настройки туннеля в безопасности.

Чтобы иметь возможность установить защищенное соединение с удаленной стороной, необходимо обменяться открытыми ключами. Несмотря на то, что открытый ключ можно распространять свободно, очень важно сохранить его целостность. Другими словами, всегда следует проверять -- не получили ли вы "кота в мешке".

Сделать это довольно просто, OpenSSL имеет команду digest, которая вычисляет контрольную сумму файла с ключом:

$ openssl dgst upstairs.public 
MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1        
        

Другой вариант -- воспользоваться услугами третьей доверенной стороны -- Certificate Authority, которая может подписать созданные вами сертификаты.

7.5.1. Windows.

Андреас Йеллингаус (Andreas Jellinghaus) <[email protected]> утверждает: "win2k: работает для случая с предопределенными ключами и IP-адресом в качестве идентификатора (не думаю, что Windows поддерживает FQDN или строки USERFQDN). Сертификаты также должны работать, но я их не пробовал. ".

7.5.2. Check Point VPN-1 NG

Питер Биринджер ( Peter Bieringer) сообщает:

Ниже приводятся некоторые результаты (тестировался только туннельный режим, auth=SHA1):

DES:     ok 
3DES:    ok 
AES-128: ok 
AES-192: not supported by CP VPN-1
AES-256: ok 
CAST* :  not supported by used Linux kernel

Tested version: FP4 aka R54 aka w/AI         
         

9.2.1. pfifo_fast

Эта дисциплина работает, как видно из названия, по принципу "первым пришел, первым ушел" (First In, First Out). Это означает, что ни один пакет не получает специальной обработки. Однако это не совсем так. Данная очередь имеет три, так называемых, "полосы". В каждой "полосе" пакеты обрабатываются по принципу FIFO. Но полоса 1 не будет обслуживаться до тех пор, пока есть пакеты в полосе 0. Аналогично, пока есть пакеты в полосе 1, не обрабатывается полоса 2.

Ядро учитывает значение поля пакета Type of Service, и направляет пакеты с установленным флагом 'минимальная задержка' в полосу 0.

Не путайте эту простую бесклассовую дисциплину с классовой дисциплиной PRIO! Хотя они ведут себя похожим образом, pfifo_fast является бесклассовой и вы не можете добавлять к ней другие дисциплины командой tc.

9.2.2. Token Bucket Filter

Token Bucket Filter (TBF) простая дисциплина очереди, которая передает поступающие пакеты со скоростью не превышающей административно заданный порог, но с возможностью превышающих его коротких всплесков.

TBF очень точная дисциплина, при этом она не создает серьезных нагрузок на сеть и процессор. Если вам нужно просто ограничить скорость на интерфейсе, то это первый кандидат на использование.

Реализована TBF в виде буфера, постоянно заполняющегося токенами с заданой скоростью. Наиболее важным параметром буфера является его размер, определяющий количество хранимых токенов.

Каждый прибывающий токен сопоставляеться с одним пакетом данных из очереди после чего удаляется. Связав этот алгоритм с двумя потоками -- токенов и данных, получим три возможных ситуации:

• Данные прибывают со скоростью равной скорости входящих токенов. В этом случае каждый пакет имеет соответствующий токен и проходит очередь без задержки.

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

• Данные прибывают быстрее, чем токены. Это означает, что в буфере скоро не останеться токенов, что заставит дисциплину приостановить передачу данных. Эта ситуация называется "превышением". Если пакеты продолжают поступать, они начинают уничтожаться.

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

Учтите, что в реальной реализации дисциплины, токены соответствуют байтам, а не пакетам.

# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540          
          

9.2.3. Stochastic Fairness Queueing.

Stochastic Fairness Queueing (SFQ) -- простая реализация семейства алгоритмов справедливой очередизации. Она не так точна, как другие дисциплины, но требует меньше рассчетов, и при этом поровну распределяет доступную полосу пропускания между сеансами.

Ключевым понятием в SFQ является диалог (или поток), который приблизительно соответствует сеансу TCP или потоку UDP. Трафик делится на достаточное количество очередей типа FIFO, по одной на каждый диалог. После этого, все очереди обрабатываются в циклическом порядке, тем самым обеспечивая каждому сеансу равные шансы на передачу данных.

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

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

Стоит заметить, что SFQ эффективен только если исходящий интерфейс полностью загружен! В противном случае очередь будет отсутствовать и, следовательно, никакого положительного эффекта наблюдаться не будет. Позже мы рассмотрим варианты комбинирования SFQ с другими дисциплинами для достижения наилучшего результата.

В частности, применение SFQ на ethernet интерфейсе к которому подключен кабельный модем или DSL маршрутизатор совершенно бессмыслено без органичения полосы пропускания!

# tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec 
 Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)           
          

9.5.1. Порядок движения пакетов внутри полноклассовых дисциплин и классов.

Когда трафик передается на обработку классовой дисциплине, он должен быть отнесен к одному из классов (классифицирован). Определение принадлежности пакета к тому или иному классу выполняется фильтрами. Очень важно понимать, что именно фильтры вызываются из дисциплины, а не наоборот!

Фильтры, присоединенные к дисциплине, возвращают результат классификации (грубо говоря -- класс пакета), после чего пакет передается в очередь, соответствующую заданному классу. Каждый из классов, в свою очередь, может состоять из подклассов и иметь свой набор фильтров, для выполнения более точной классификации свой доли трафика. В противном случае пакет обслуживается дисциплиной очереди класса.

Кроме того, в большинстве случаев классовые дисциплины выполняют шейпинг (формирование) трафика, с целью переупорядочивания пакетов (например, с помощью SFQ) и управления скоростью их передачи. Это определенно необходимо в случае перенаправления трафика с высокоскоростного интерфейса (например, ethernet) на медленный (например, модем).

9.5.2. Элементы дисциплины: корень, дескриптор, родительские элементы и элементы одного уровня.

Каждый из интерфейсов имеет одну исходящую корневую дисциплину. По-умолчанию это, упоминавшаяся ранее дисциплина -- pfifo_fast. Каждой дисциплине и каждому классу назначается уникальный дескриптор, который который может использоваться последующими инструкциями для ссылки на эти дисциплины и классы. Помимо исходящей дисциплины, интерфейс так же может иметь и входящую дисциплину, которая производит управление входящим трафиком.

Дескрипторы дисциплин состоят из двух частей -- старшего и младшего номеров, в виде: <старший>:<младший>. Корневой дисциплине общепринято присваивать дескриптор '1:', что эквивалентно записи '1:0'. Младший номер в дескрипторе любой дисциплины всегда '0'.

Старшие номера дескрипторов классов всегда дублируют старший номер дескриптора своего "родителя". Старший номер должен быть уникальным в пределах блоков настроек для входящего и исходящего трафиков. Младший номер должен быть уникальным в пределах дисциплины и ее классов.

                      1:   корневая дисциплина
                      |
                     1:1    дочерний класс
                   /  |  \
                  /   |   \
                 /    |    \
                 /    |    \
              1:10  1:11  1:12   дочерние классы
               |      |     | 
               |     11:    |    краевой класс
               |            | 
               10:         12:   дисциплины
              /   \       /   \
           10:1  10:2   12:1  12:2   краевые классы
          

9.5.3. Дисциплина PRIO.

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

Постановка пакета в очередь выполняется дисциплиной PRIO на основе фильтров, заданных вами. По-умолчанию создаются три класса. Эти классы по-умолчанию содержат обычные дисциплины FIFO, но они могут быть заменены дисциплинами любого типа, какие вам только доступны.

Когда необходимо извлечь пакет из очереди, то первым проверяется класс :1. Каждый последующий класс проверяется только в том случае, если в предыдущем нет ни одного пакета.

Эта дисциплина может с успехом применяться в тех случаях, когда необходимо "раскидать" трафик по приоритетам, основываясь не только на флагах TOS. Вы можете так же добавить другие дисциплины к предопределенным классам, что повысит возможности управления трафиком, по сравнению с pfifo_fast.

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

Формально, дисциплина PRIO относится к разряду планировщиков типа Work-Conserving.

             1:   корневая дисциплина
           / | \ 
          /  |  \
         /   |   \
       1:1  1:2  1:3    классы
        |    |    |
       10:  20:  30:    дисциплины
       sfq  tbf  sfq
полоса  0    1    2
          

# tc qdisc add dev eth0 root handle 1: prio 
## Эта команда создаст классы 1:1, 1:2, 1:3
  
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq     
          

# tc -s qdisc ls dev eth0 
qdisc sfq 30: quantum 1514b 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 132 bytes 2 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 174 bytes 3 pkts (dropped 0, overlimits 0) 
          

# scp tc [email protected]:./
[email protected]'s password: 
tc                   100% |*****************************|   353 KB    00:00    
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b 
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 2230 bytes 31 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 389140 bytes 326 pkts (dropped 0, overlimits 0) 
          

# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b 
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) 

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms 
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) 

 qdisc sfq 10: quantum 1514b 
 Sent 14926 bytes 193 pkts (dropped 0, overlimits 0) 

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 401836 bytes 488 pkts (dropped 0, overlimits 0) 
          

9.5.4. Дисциплина CBQ.

Как уже упоминалось ранее, CBQ -- одна из самых сложных дисциплин. Пожалуй я не погрешу против истины, если заявлю, что это самая объемная, самая непонятная и самая запутанная дисциплина организации очередей. Это не потому, что авторы алгоритма некомпетентны, а потому, что идеология этого алгоритма абсолютно не совпадает с идеологией Linux.

Кроме того, что эта дисциплина является классовой, она так же может выполнять и шейпинг трафика, правда именно эта ее сторона является самым слабым местом. Если вы попробуете ограничить 10 мегабитный канал величиной в 1 мегабит, то окажется, что соединение будет просто простаивать 90% всего времени. Вместо определения объема трафика, CBQ измеряет время в микросекундах между запросами и на основе полученного времени рассчитывается средняя загруженность канала.

Такой алгоритм работы не всегда дает нужные результаты. Например, что если сетевой интерфейс не может обеспечить полную загрузку канала на всю его возможную ширину, из-за некачественного драйвера? Как тогда правильно определить время простоя?

Проблема становится еще острее, если вам приходится иметь дело с такими вещами, как PPP через Ethernet или PPTP через TCP/IP. Эффективная пропускная способность в данном случае может быть определена как пропускная способность канала в пространство пользователя, а это величина очень не маленькая.

Те, кто близко сталкивался с CBQ отмечают, что эта дисциплина не всегда точна, и иногда допускает грубые просчеты при измерении времени.

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

               1:           корневая дисциплина
               |
              1:1           дочерний класс
             /   \
            /     \
          1:3     1:4       краевые классы
           |       |
          30:     40:       дисциплины
         (sfq)   (sfq)
            

# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit         \
  avpkt 1000 cell 8
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit  \
  rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20      \
  avpkt 1000 bounded
            

# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit  \
  rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000                       
# tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit  \
  rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000
            

# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
# tc qdisc add dev eth0 parent 1:4 handle 40: sfq
            

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 80 0xffff flowid 1:3
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 25 0xffff flowid 1:4
            

# tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit allot 1514 \
  cell 8 avpkt 1000 mpu 64
 
# tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 10Mbit    \
  rate 10Mbit allot 1514 cell 8 weight 1Mbit prio 8 maxburst 20        \
  avpkt 1000
          

TC_PRIO..        Число  Значение поля TOS
-------------------------------------------------
BESTEFFORT         0    Maximize Reliablity (0x04) (Максисальная надежность)
FILLER             1    Minimize Cost (0x02)       (Минимальная стоимость)
BULK               2    Maximize Throughput (0x08) (Максимальная пропускная способность) 
INTERACTIVE_BULK   4                               
INTERACTIVE        6    Minimize Delay (0x10)      (Минимальная задержка)
CONTROL            7                               
          

# tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit     \
  rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20        \
  avpkt 1000 split 1:0 defmap c0

# tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 10Mbit     \
  rate 8Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20        \
  avpkt 1000 split 1:0 defmap 3f
          

приоритет	класс
0		      1:3
1		      1:3
2		      1:3
3		      1:3
4		      1:3
5		      1:3
6		      1:2
7		      1:2
          

# tc class change dev eth1 classid 1:2 cbq defmap 01/01
          

приоритет	класс
0		      1:2
1		      1:3
2		      1:3
3		      1:3
4		      1:3
5		      1:3
6		      1:2
7		      1:2
          

9.5.5. Hierarchical Token Bucket

Мартин Девера (Martin Devera) aka <devik> справедливо отмечает, что CBQ слишком сложна и слабо оптимизирована для большинства типичных ситуаций. Его подход более точно соответствует конфигурациям, когда необходимо распределить заданную полосу пропускания между различными видами трафика на полосы гарантированной ширины, с возможностью заимствования.

HTB работает точно так же, как и CBQ, но, в отличие от последней, принцип работы основан не на вычислении времени простоя, а на определении объема трафика, что полностью соответствует названию Token Bucket Filter. Эта дисциплина имеет незначительное число параметров настройки, которые достаточно хорошо описаны на сайте http://luxik.cdi.cz/~devik/qos/htb/.

Хотя конфигурирование HTB -- задача достаточно сложная, тем не менее конфигурации хорошо масштабируются. В случае же с CBQ процесс конфигурирования становится слишком сложным даже в самых простых случаях! HTB3 теперь стала частью ядра (начиная с версий 2.4.20-pre1 и 2.5.31). Однако, вам может потребоваться пропатченная версия утилиты tc: старший номер версии HTB в ядре и пользовательских утилит должны совпадать, в противном случае tc откажется работать с HTB.

Если у вас установлено достаточно свежее или пропатченное ядро, вам определенно стоит посмотреть в сторону HTB!

# tc qdisc add dev eth0 root handle 1: htb default 30

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k

# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k
        

# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
        

# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20
        

9.6.1. Ряд простых примеров фильтрации.

Для начала продемонстрируем самый обычный случай, который, к счастью, достаточно прост. Допустим, что у нас имеется дисциплина PRIO, с дескриптором 10:, которая содержит три класса и нам нужно весь трафик, отправляемый на 22 порт и с 80 порта, отдать в самую высокоприоритетную полосу, тогда набор фильтров мог бы выглядеть так:

# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ 
  ip dport 22 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
  ip sport 80 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2
        

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

Отбор пакетов по IP-адресам выполняется аналогичным образом:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \ 
  match ip dst 4.3.2.1/32 flowid 10:1
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
  match ip src 1.2.3.4/32 flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2      \
  flowid 10:2
        

Допускается смешивать проверку IP-адреса и номера порта:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32 \
  match ip sport 80 0xffff flowid 10:1
        

9.6.2. Наиболее употребимые способы фильтрации.

В большинстве случаев, команды фильтрации начинаются так:

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..
        

9.7.1. Пример конфигурирования.

Первое, что может прийти на ум -- попытаться сформировать входящий трафик так, чтобы дать себе наивысший приоритет ;) Конфигурация IMQ очень похожа на конфигурацию любого другого интерфейса:

tc qdisc add dev imq0 root handle 1: htb default 20

tc class add dev imq0 parent 1: classid 1:1 htb rate 2mbit burst 15k

tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1mbit
tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1mbit

tc qdisc add dev imq0 parent 1:10 handle 10: pfifo
tc qdisc add dev imq0 parent 1:20 handle 20: sfq

tc filter add dev imq0 parent 10:0 protocol ip prio 1 u32 match \
		ip dst 10.0.0.230/32 flowid 1:10
        

Отбираемый трафик маркируется средствами iptables:

iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

ip link set imq0 up
        

IMQ [ --todev n ]	
        

Это действие существует и в ip6tables.

Обратите внимание: трафик попадает на интерфейс не в тот момент, когда переходит к цели IMQ, а после обработки соответствующей цепочки. Точное место входа на устройство imq зависит от типа трафика (входящий/исходящий).

Для входящего трафика imq регистрируется с приоритетом NF_IP_PRI_MANGLE + 1. Это означает, что пакеты попадают на устройство сразу после прохождения цепочки PREROUTING. Для исходящего трафика, imq использует приоритет NF_IP_PRI_LAST, который гарантирует, что пакеты, уничтоженные пакетным фильтром не будут занимать полосу пропускания устройства.

Дополнительные сведения и "заплаты" вы найдете на сайте http://luxik.cdi.cz/~patrick/imq/

12.1.1. Селектор U32.

Селектор U32 содержит определение шаблона, который будет сопоставляться с обрабатываемым пакетом. Если быть более точным, он определяет -- какие биты в заголовке пакета будут проверяться и не более того, но, не смотря на свою простоту, это очень мощный и гибкий метод. Рассмотрим примеры, взятые из реально работающего и достаточно сложного фильтра:

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
  match u32 00100000 00ff0000 at 0 flowid 1:10        
        

# tc filter add dev eth0 protocol ip parent 1:0 pref 10 u32 \
  match u32 00000016 0000ffff at nexthdr+0 flowid 1:10        
        

Уловив все, что говорилось выше, вы без труда поймете смысл следующего селектора: match c0a80100 ffffff00 at 16. Данный селектор будет пытаться найти 3-х байтовую последовательность в IP-заголовке, начиная с 17-го байта, отсчитываемого от начала заголовка, что соответствует любому адресу назначения в сети 192.168.1.0/24.

12.1.2. Селекторы общего назначения.

Селекторы общего назначения задают шаблон, маску и смещение. Используя эти селекторы вы сможете выполнять проверку практически любого, отдельно взятого бита в заголовке IP (или протокола более высокого уровня). При написании и чтении они более сложны, чем селекторы специального назначения, которые будут обсуждаться в следующем разделе. Синтаксис селекторов общего назначения:

match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET]        
        

Приведем несколько примеров:

Этим селектором будут отобраны пакеты, у которых "время жизни" (поле TTL) равно 64. Поле TTL находится в 9-м (в 8-м, если считать с нуля) байте IP-заголовка.

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match u8 64 0xff at 8 \
     flowid 1:4        
        

# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match ip protocol 6 0xff \
     match u8 0x10 0xff at nexthdr+13 \
     flowid 1:3        
        

## отбор ack-пакетов более сложным способом,
## IP protocol 6,
## Длина IP-заголовка 0x5 (32-х битных слов),
## Общая длина 0x34 (ACK + 12 байт опций TCP)
## TCP ACK (бит 5, смещение 33)
# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
            match ip protocol 6 0xff \
            match u8 0x05 0x0f at 0 \
            match u16 0x0000 0xffc0 at 2 \
            match u8 0x10 0xff at 33 \
            flowid 1:3        
        

Фильтр, приведенный ниже, является модификацией предыдущего примера. На этот раз не производится проверка длины IP-заголовка. Вы спросите -- почему? Потому, что фильтр, приведенный выше, работает только на 32-х битных системах.

tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
     match ip protocol 6 0xff \
     match u8 0x10 0xff at nexthdr+13 \
     match u16 0x0000 0xffc0 at 2 \
     flowid 1:3        
        

12.1.3. Селекторы специального назначения.

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

FIXME: таблица находится в отдельном файле selector.html.

FIXME: Она по-прежнему остается на польском языке :-(

FIXME: надо перевести в формат sgml.

Несколько примеров:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
     match ip tos 0x10 0xff \
     flowid 1:4        
        

Правило выше отберет пакеты, в которых поле TOS имеет значение 0x10. Поле TOS -- это второй байт в IP-заголовке, причем это однобайтовое поле (8 бит). Таким образом, эквивалентный селектор можно было бы записать как: match u8 0x10 0xff at 1. Это наталкивает на мысль, что селекторы специального назначения, внутри фильтров U32, преобразуются в селекторы общего назначения и в таком виде сохраняются в памяти ядра. Отсюда следует другое заключение -- селекторы tcp и udp суть есть одно и то же. По этой причине вы не сможете использовать единичный селектор match tcp dport 53 0xffff, для отбора TCP-пакетов, направляющихся на 53-й порт. Этим селектором будут отобраны как TCP-пакеты, так и UDP-пакеты. Вы обязательно должны добавлять селектор типа протокола:

# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
        match tcp dport 53 0xffff \
        match ip protocol 0x6 0xff \
        flowid 1:2        
        

12.3.1. Способы ограничения.

Существует две основных возможности ограничения. Если вы собрали ядро с "функциями оценки" (estimators), то оно сможет более или менее точно измерять объем трафика, переданного тому или иному фильтру. Устройство функции оценки достаточно несложное -- 25 раз в секунду подсчитывается объем переданных данных, на основе которого вычисляется загруженность канала.

Другой способ -- Token Bucket Filter, который реализуется в пределах вашего фильтра. Это типичный шейпер, который может использоваться, если вам нужно просто ограничить полосу пропускания по какому-нибудь критерию.

12.3.2. Действия в случае превышения ограничения.

Если правило "решит", что произошло превышение заданного предела, то оно выполнит соответствующее действие. Имеются четыре вида действий:

12.3.3. Примеры.

Единственный, известный нам, реальный пример приведен в разделе Защита от SYN flood

Ограничение входящего icmp-трафика до 2 Кбит. При превышении предела -- пакеты отбросить.

tc filter add dev $DEV parent ffff: \
    protocol ip prio 20 \
    u32 match ip protocol 1 0xff \
    police rate 2kbit buffer 10k drop \
    flowid :1        
        

tc filter add dev $DEV parent ffff: \
   protocol ip prio 20 \
   u32 match tos 0 0 \
   police mtu 84 drop \
   flowid :1        
        

tc filter add dev $DEV parent ffff: \
   protocol ip prio 20 \
   u32 match ip protocol 1 0xff \
   police mtu 1 drop \
   flowid :1        
        

12.5.1. Почему не работают tc-фильтры в IPv6?

Дело в том, что в ядре Linux, модель маршрутизации и адресации IPv4 (замечательные особенности которой описывает этот HOWTO) строилась на основе Базы Политик Маршрутизации (RPDB -- Routing Policy Database). К сожалению, модель IPv6 в Linux была реализована совершенно иным образом. Хотя они используют совместно некоторые средства, но основа основ -- RPDB, не принимает участия в адресации и маршрутизации IPv6.

Надеюсь, что такое положение дел наверняка изменится, надо только подождать.

FIXME: : Ждем ваших замечаний и предложений по этому поводу, может кто-то работает над этим?

12.5.2. Маркировка пакетов IPv6 средствами ip6tables.

ip6tables имеет возможность пометить пакеты:

# ip6tables -A PREROUTING -i eth0 -t mangle -p tcp -j MARK --mark 1        
        

12.5.3. Использование селектора u32 для пакетов IPv6.

Для передачи по сетям IPv4, трафик IPv6 обычно инкапсулируется в SIT-туннель. За дополнительной информацией по созданию такого рода туннелей, обращайтесь к разделу Тоннелирование IPv6. Это позволяет выполнять фильтрацию IPv4-пакетов, которые, в качестве полезной нагрузки, несут пакеты IPv6.

Следующий фильтр отберет все пакеты IPv6, инкапсулированные в IPv4:

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff flowid 42:42        
        

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
           match ip protocol 41 0xff \
           match u8 0x05 0x0f at 0 \
           match u8 0x3a 0xff at 26 \
           flowid 42:42        
        

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff \
            match u8 0x05 0x0f at 0 \
            match u8 0x3f 0xff at 44 \
            match u8 0xfe 0xff at 45 \
            match u8 0x20 0xff at 46 \
            match u8 0x2c 0xff at 47 \
            match u8 0xff 0xff at 48 \
            match u8 0xff 0xff at 49 \
            match u8 0x00 0xff at 50 \
            match u8 0x32 0xff at 51 \
            match u8 0x02 0xff at 52 \
            match u8 0x30 0xff at 53 \
            match u8 0x4f 0xff at 54 \
            match u8 0xff 0xff at 55 \
            match u8 0xfe 0xff at 56 \
            match u8 0x08 0xff at 57 \
            match u8 0x35 0xff at 58 \
            match u8 0x8d 0xff at 59 \
            flowid 10:13        
        

# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
            match ip protocol 41 0xff \
            match u8 0x05 0x0f at 0 \
            match u8 0x20 0xff at 28 \
            match u8 0x01 0xff at 29 \
            flowid 10:13        
        

13.2.1. Параметры настройки IPv4.

Небольшое примечание: в большинстве своем, приводимые здесь временные параметры не воздействуют на локальный (loopback) интерфейс, так что вы не сможете проверить их, не имея реального сетевого интерфейса. Кроме того, указываемые пределы измеряются в 'тиках', и предполагают использование ранее упомянутого Token Bucket Filter.

Ядро имеет встроенные 'часы', которые 'тикают' определенное число раз в секунду. Для платформы Intel -- обычно 100 раз в секунду (в ядрах серии 2.6.x этот параметр можно изменить с помощью утилит конфигурирования. прим. перев.). Таким образом, число 50, в некоем параметре *_rate, будет означать '2 пакета в секунду'. Token Bucket Filter сконфигурирован так, чтобы иметь возможность превышения лимита не более чем на 6 пакетов.

Некоторые пункты, из приводимого ниже списка, мы просто скопировали из /usr/src/linux/Documentation/networking/ip-sysctl.txt, написанного Алексеем Кузнецовым <[email protected]> и Энди Клином (Andi Kleen) <[email protected]>.

От переводчика (А.К.): Я взял на себя смелость привести описание части параметров из "ipsysctl tutorial", поскольку они более точные и полные.

От переводчика (А.К.): По поводу двух предыдущих параметров (icmp_paramprob_rate и icmp_timeexceed_rate) у меня есть большие сомнения в том, что они присутствуют в файловой системе /proc. Вероятно в более ранних версиях ядра (до 2.4) эти параметры присутствовали, но у себя я их не нашел, зато имеются два других параметра, которые обеспечивают данную функциональность.

13.2.2. Параметры настройки устройств.

Каталог conf/DEV/, где под DEV следует понимать название того или иного устройства, содержит настройки для конкретного сетевого интерфейса. Настройки в каталоге conf/all/ применяются ко ВСЕМ сетевым интерфейсам. Настройки в каталоге conf/default/ -- настройки по-умолчанию, они не влияют на настройки существующих интерфейсов, но используются для первоначальной настройки вновь устанавливаемых устройств.

13.2.3. Параметры сетевых политик.

Каталог neigh/DEV/, где под DEV следует понимать название того или иного устройства, содержит настройки для конкретного сетевого интерфейса. Настройки в каталоге neigh/all/ применяются ко ВСЕМ сетевым интерфейсам. Настройки в каталоге neigh/default/ -- настройки по-умолчанию, они не влияют на настройки существующих интерфейсов, но используются для первоначальной настройки вновь устанавливаемых устройств.

13.2.4. Параметры маршрутизации.

14.1.1. Параметры и порядок использования.

14.3.1. Введение.

Прежде всего, было бы неплохо, если бы вы предварительно ознакомились с RFC, посвященными данной теме (RFC2474, RFC2475, RFC2597 и RFC2598) по адресам: IETF DiffServ working Group и домашняя страничка проекта diffserv.

14.3.2. Что такое Dsmark и с чем его "едят"?

Dsmark -- это дисциплина организации очереди, которая предлагает возможности, необходимые в "Differentiated Services" (известной также, как DiffServ, или просто -- DS). DiffServ -- фактически одна из двух архитектур QoS (вторая называется "Integrated Services"), которая базируется на значении поля DS в заголовке IP-пакетов.

Одним из первых решений в IP, которое предлагало некоторый уровень QoS, был "Type of Service" (Тип Обслуживания) -- поле TOS в IP-заголовке. Изменяя это поле, можно было выбрать высокую/низкую пропускную способность, минимальную задержку или высокую надежность. Но это решение не обеспечивало достаточной гибкости, которую требовали вновь появляющиеся услуги (например, приложения реального времени, интерактивные приложения и т.п.). С появлением новых требований, появились и новые архитектуры. Одна из них -- DiffServ, которая подменяет первые шесть битов ToS в пакете IPv4 или октет "класс трафика" в пакете IPv6, полем, с названием DS, в котором можно указать до 64 классов трафика.

14.3.3. Основные принципы.

Differentiated Services (Дифференцированное Обслуживание) ориентирован на группы. Имеется ввиду, что эта технология ничего не знает о потоках, она ориентирована на группы, а применяемые правила зависят от того, к какой группе направляется пакет.

Сеть маршрутизаторов с поддержкой механизмов DiffServ называют "облаком DiffServ" (или "доменом DiffServ"). Классификация, формирование и установка меток (под установкой меток понимается установка значений в поле DS) происходит на входе в "облако". Внутри домена метка определяет -- какой уровень QoS должен применяться к трафику внутренними маршрутизаторами сети.

Самым большим преимуществом модели DiffServ является то, что она действует на границе "облака". После того как данные пересекли границу, внутренним маршрутизаторам можно не заниматься поддержанием информации о статусе QoS и полностью сосредоточиться на своей основной функции -- маршрутизации.

Фактически, внутри своих локальных доменов, вы можете диктовать любую политику обслуживания, но при соединении с другими DS-доменами вы должны следовать Соглашению об Уровне Обслуживания (SLA).

К этому моменту у вас наверняка возникла масса вопросов. Diffsrv -- это много больше, чем я смог сказать. Вы должны понять, что я не в состоянии в 50 строках изложить содержимое трех RFC. :-)

14.3.4. Как работать с Dsmark.

Как уже было определено выше, в случае с DiffServ, пограничные и внутренние узлы различаются между собой. Это два важных пункта на пути трафика. Оба типа узлов выполняют классификацию трафика. Результат классификации может использоваться для различной DS-обработки, прежде чем пакет уйдет в сеть. Код diffserv представляет пакет в виде структуры sk_buff, в которой имеется поле skb->tc_index. В данном поле сохраняется результат начальной классификации, который может использоваться для различной интерпретации DS на пограничных и внутренних маршрутизаторах.

Значение skb->tc_index изначально устанавливается дисциплиной DSMARK qdisc для каждого входящего пакета, в соответствии с полем DS в IP-заголовке. Кроме того, классификатор cls_tcindex считывает, целиком или частично, значение skb->tcindex и использует его для выбора нужного класса.

Для начала рассмотрим команду DSMARK qdisc и ее параметры:

... dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]
        

• indices: размер таблицы пар маска-значение. Максимальное значение 2^n, где n >= 0.

• Default_index: индекс в таблице, принимаемый по-умолчанию, если классификатор не находит ни одного совпадения.

• Set_tc_index: инструкция, которая считывает значение поля DS и записывает его в skb->tc_index.

14.3.5. Как работает SCH_DSMARK.

Эта дисциплина выполняет следующие шаги:

• Если вставлена инструкция set_tc_index, то считывается поле DS и сохраняется в skb->tc_index.

• Вызывается классификатор. Он возвращает идентификатор класса, который будет сохранен в skb->tc_index. Если такой класс не найден, то используется класс по-умолчанию из параметра default_index. Если ни set_tc_index, ни default_index не объявлены, то результат может оказаться непредсказуемым.

• После этого управление передается внутренней qdisc, где вы можете повторно использовать результаты фильтрации. Идентификатор класса, возвращаемый внутренней qdisc, запоминается в skb->tc_index. Это значение будет использоваться в качестве индекса таблицы маска-значение. Конечный результат, который будет связан с пакетом, получается из выражения:

  New_Ds_field = ( Old_DS_field & mask ) | value            
              

• Таким образом, конечный результат получается в результате объединения по "И" ds_field и маски, и затем объединения по "ИЛИ" с параметром value. Следующая диаграмма иллюстрирует этот процесс:

                           skb->ihp->tos
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >
       |                                                       |     ^
       | -- Если объявлена инструкция set_tc_index,            |     |  <-----Значение поля
       |    то значение DS переписывается в skb->tc_index      |     |O       DS может измениться
       |                                                      A|     |R
     +-|-+      +------+    +---+-+    внутренняя +-+     +---N|-----|----+
     | | |      | tc   |--->|   | |-->  . . .  -->| |     |   D|     |    |
     | | |----->|index |--->|   | |     Qdisc     | |---->|    v     |    |
     | | |      |filter|--->| | | +---------------+ |   ---->(mask,value) |
  -->| O |      +------+    +-|-+--------------^----+  /  |  (.  ,  .)    |
     | | |          ^         |                |       |  |  (.  ,  .)    |
     | | +----------|---------|----------------|-------|--+  (.  ,  .)    |
     | | sch_dsmark |         |                |       |                  |
     +-|------------|---------|----------------|-------|------------------+
       |            |         | <- tc_index -> |       |
       |            |(read)   |    может       |       |  <--------------Индекс в таблице
       |            |         |    измениться  |       |                    (mask,value)
       v            |         v                v       |                               
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
                           skb->tc_index            
              

tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8        
        

Теперь перейдем к описанию фильтра TC_INDEX. Кроме всего прочего, фильтр TC_INDEX может использоваться и в других конфигурациях, а не только в тех, которые включают DS услуги.

14.3.6. Фильтр TC_INDEX.

Базовый синтаксис команды, объявляющей фильтр TC_INDEX:

... tcindex [ hash SIZE ] [ mask MASK ] [ shift SHIFT ]
            [ pass_on | fall_through ]
            [ classid CLASSID ] [ police POLICE_SPEC ]        
        

tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index

tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc  shift 2

tc qdisc add dev eth0 parent 1:0 handle 2:0 cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64

# EF traffic class

tc class add dev eth0 parent 2:0 classid 2:1 cbq bandwidth 10Mbit rate 1500Kbit avpkt 1000 prio 1 bounded isolated allot 1514 weight 1 maxburst 10

# Packet fifo qdisc for EF traffic

tc qdisc add dev eth0 parent 2:1 pfifo limit 5

tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on        
        

Будем исходить из предположения, что мы получаем пакет, помеченный как EF. Если вы прочитаете RFC2598, то увидите, что рекомендуемое значение DSCP для EF трафика -- 101110. Это означает, что в поле DS будет записано 10111000 (не забывайте, что младшие биты в поле TOS не используются в DS), или 0xb8, в шестнадцатиричном представлении.

              TC INDEX
              FILTER
   +---+      +-------+    +---+-+    +------+                +-+    +-------+
   |   |      |       |    |   | |    |FILTER|  +-+    +-+    | |    |       |
   |   |----->| MASK  | -> |   | | -> |HANDLE|->| |    | | -> | | -> |       |
   |   |  .   | =0xfc |    |   | |    |0x2E  |  | +----+ |    | |    |       |
   |   |  .   |       |    |   | |    +------+  +--------+    | |    |       |
   |   |  .   |       |    |   | |                            | |    |       |
-->|   |  .   | SHIFT |    |   | |                            | |    |       |-->
   |   |  .   | =2    |    |   | +----------------------------+ |    |       |
   |   |      |       |    |   |       CBQ 2:0                  |    |       |
   |   |      +-------+    +---+--------------------------------+    |       |
   |   |                                                             |       |
   |   +-------------------------------------------------------------+       |
   |                          DSMARK 1:0                                     |
   +-------------------------------------------------------------------------+        
        

Value1 = skb->tc_index & MASK
Key = Value1 >> SHIFT        
        

Value1 = 10111000 & 11111100 = 10111000
Key = 10111000 >> 2 = 00101110 -> 0x2E (в шестнадцатиричном виде)
        

И последние два параметра, которые мы опишем, это hash и pass_on. Первый из них определяет размер хеш-таблицы. Pass_on -- означает, что если не будет найден classid, равный результату этого фильтра, то необходимо попробовать применить следующий фильтр. Действие по-умолчанию -- fall_through (см. следующую таблицу).

В заключение посмотрим -- какие значения параметров TCINDEX допустимы:

TC Name                 Value           Default
-----------------------------------------------------------------
Hash                    1...0x10000     Зависит от реализации   
Mask                    0...0xffff      0xffff
Shift                   0...15          0
Fall through / Pass_on  Flag            Fall_through
Classid                 Major:minor     None
Police                  .....           None        
        

Я настоятельно рекомендую вам внимательно просмотреть все примеры DiffServ, включаемые в дистрибутив iproute2. Со своей стороны я обещаю, что дополню этот текст, как только найду время. Все, что я здесь описал -- есть результат длительных экспериментов. Я буду весьма признателен, если вы сообщите мне об обнаруженных ошибках.

14.4.1. Параметры и порядок использования.

Входные дисциплины, сами по себе не требуют каких-либо параметров. Пример создания входной дисциплины:

# tc qdisc add dev eth0 ingress        
        

Примеры использования входящей дисциплины вы найдете в главе Решебник.

15.5.1. Схема движения пакетов после настройки.

|-----------------------------------------|
|         Схема движения пакетов          |
|-----------------------------------------|

ИНТЕРНЕТ
/\
||
\/
---------------------donmuang------------------------
/\                                      /\         ||
||                                      ||         ||
||                                      \/         ||
naret                                  silom       ||
*destination port 80 ================>(cache)      ||
/\                                      ||         ||
||                                      \/         \/
\\===================================kaosarn, RAS, и пр.        
        

Ниже приводится путь, проделываемый пакетами в/из Интернет для компьютера kaosarn.

Для web/http трафика:

kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn        
        

kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn        
        

15.6.1. Решение

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить 'Path MTU Discovery' и установить MTU вручную. Koos van den Hout пишет:

Вообще, можно запретить 'PMTU Discovery' путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000          
          

15.8.1. Почему все так сложно?

Поставщикам услуг Интернет хорошо известно, что пользователей в основном интересует скорость, с которой они могут получать данные. Но помимо пропускной способности канала, на скорость скачивания очень сильно влияют факты потери пакетов. Увеличение очередей способствует уменьшению потерь, что в свою очередь приводит к увеличению скорости скачивания. Поэтому поставщики услуг, как правило, создают очереди очень большого объема.

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

В этом руководстве мы расскажем вам, о способах обслуживания очередей, но, к большому сожалению, не все очереди нам доступны. Так, очереди поставщика услуг нам не подвластны совершенно, в то время, как очередь исходящего трафика, скорее всего находится внутри вашего кабельного или DSL модема. Некоторые модели допускают возможность конфигурирования очередей, но чаще всего такая возможность отсутствует.

Итак, что же дальше? Поскольку мы лишены возможности управлять этими очередями, то напрашивается очевидное решение -- они должны быть перемещены на наш Linux-маршрутизатор. К счастью это возможно. Для этого необходимо:

При выполнении этих условий, входящая очередь будет ликвидирована полностью (за исключением коротких пиков), и появляется возможность управления исходящей очередью, используя всю мощь, которую предоставляет операционная система Linux.

После этого остается обеспечить первоочередную передачу интерактивного трафика. А для того, чтобы входящий трафик не блокировался исходящим, необходимо так же обеспечить первоочередную передачу ACK-пакетов. При наличии объемного трафика в обоих направлениях, возникают значительные задержки, поэтому входящие ACK-пакеты не должны проигрывать в конкурентной борьбе с исходящим трафиком.

После выполнения необходимых настроек, мы получили следующие результаты на ADSL соединении в Нидерландах:

Базовое время ожидания отклика:
туда-обратно мин/ср/макс = 14.4/17.1/21.7 мсек

Во время скачивания, без формирователя трафика:
туда-обратно мин/ср/макс = 560.9/573.6/586.4 мсек

Во время отправки большого объема, без формирователя трафика:
туда-обратно мин/ср/макс = 2041.4/2332.1/2427.6 мсек

С формирователем трафика, при отправке большого файла на скорости 220 Кбит/сек:
round-trip min/avg/max = 15.7/51.8/79.9 мсек

С формирователем трафика, при скачивании на скорости 850 Кбит/сек:
туда-обратно мин/ср/макс = 20.4/46.9/74.0 мсек

При наличии исходящего трафика, скорость входящего достигает ~80% 
от максимально возможного значения. Скорость исходящего трафика
колеблется около 90%. При этом время ожидания подскакивает до 850 мсек, 
причина пока не выяснена.
        

Чего можно ожидать от этого сценария, во многом зависит от фактической пропускной способности канала для исходящего потока. При наличии объемного исходящего трафика, перед исходящим интерактивным пакетом практически всегда будет стоять какой либо другой пакет, что и обусловливает нижний предел времени ожидания. Вы можете рассчитать этот предел, разделив MTU на максимальную скорость для исходящего потока. Типичные значения будут несколько выше. Чтобы достичь лучшего эффекта, можно попробовать несколько уменьшить MTU!

Ниже приводятся две версии сценария формирователя трафика. Одна версия построена на базе HTB, разработанной Девиком (Devik), другая -- на базе CBQ, которая, в отличие от HTB, включена в состав ядра Linux. Оба сценария проверены и дают прекрасные результаты.

15.8.2. Формирователь трафика на базе CBQ.

Может работать практически с любой версией ядра. В данной реализации, внутри CBQ qdisc размещаются две SFQ (Stochastic Fairness Queues), что даст возможность равноправного сосуществования нескольких потоков данных.

Входящий трафик формируется с помощью tc-фильтров, содержащих Token Bucket Filter.

Вы можете улучшить сценарий за счет добавления ключевых слов bounded в строках, начинающихся со слов tc class add .. classid 1:20. Если вы предполагаете уменьшать MTU, не забудьте уменьшить и значения allot и avpkt!

#!/bin/bash 

# Формирователь трафика для домашнего соединения с Интернет
# 
#
# Установите следующие параметры так, чтобы они были немного меньше фактических
# Единицы измерения -- килобиты
DOWNLINK=800
UPLINK=220
DEV=ppp0

# очистка входящей и исходящей qdisc
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### исходящий трафик

# установка корневой CBQ

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit 

# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит
# появление огромных очередей в DSL модеме,
# которые отрицательно сказываются на величине задержки:
# базовый класс

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated 

# высокоприоритетный (интерактивный) класс 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
   allot 1600 prio 1 avpkt 1000

# класс по-умолчанию 1:20 -- получает немного меньший объем трафика
# и имеет более низкий приоритет:

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
   allot 1600 prio 2 avpkt 1000

# оба получают дисциплину Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# определения фильтров
# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10

# ICMP (ip protocol 1) -- в интерактивный класс 1:10
# так мы сможем удивить своих друзей:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
	match ip protocol 1 0xff flowid 1:10

# Поднять скорость входящего трафика, при наличии исходящего -- передать ACK-пакеты
# в интерактивный класс:

tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# остальной трафик не является интерактивным поэтому передаем его в 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
   match ip dst 0.0.0.0/0 flowid 1:20

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

tc qdisc add dev $DEV handle ffff: ingress

# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой скоростью.

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1        
        

Если вы собираетесь использовать этот сценарий совместно с ppp -- скопируйте его в /etc/ppp/ip-up.d.

Если последние две строки в сценарии порождают сообщения об ошибке -- обновите версию tc!

15.8.3. Формирователь трафика на базе HTB.

Следующий вариант сценария достигает поставленных целей за счет использования замечательных особенностей HTB (см. раздел Hierarchical Token Bucket). Требует наложения "заплаты" на ядро!

#!/bin/bash

# Формирователь трафика для домашнего соединения с Интернет
# 
#
# Установите следующие параметры так, чтобы они были немного меньше фактических
# Единицы измерения -- килобиты
DOWNLINK=800
UPLINK=220
DEV=ppp0

# очистка входящей и исходящей qdisc
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### исходящий трафик

# установка корневой HTB, отправить трафик по-умолчанию в 1:20:

tc qdisc add dev $DEV root handle 1: htb default 20

# ограничить общую исходящую скорость величиной $UPLINK -- это предотвратит
# появление огромных очередей в DSL модеме,
# которые отрицательно сказываются на величине задержки:

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# высокоприоритетный (интерактивный) класс 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
   burst 6k prio 1

# класс по-умолчанию 1:20 -- получает немного меньший объем трафика
# и имеет более низкий приоритет:

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
   burst 6k prio 2

# оба получают дисциплину Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# TOS = Minimum-Delay (ssh, НО НЕ scp) -- в 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10

# ICMP (ip protocol 1) -- в интерактивный класс 1:10
# так мы сможем удивить своих друзей:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
	match ip protocol 1 0xff flowid 1:10

# Поднять скорость входящего трафика, при наличии исходящего -- передать ACK-пакеты
# в интерактивный класс:

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# остальной трафик не является интерактивным поэтому он попадает в 1:20


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

tc qdisc add dev $DEV handle ffff: ingress

# сбрасывать все подряд (0.0.0.0/0), что приходит со слишком большой скоростью.

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1        
        

Если вы собираетесь использовать этот сценарий совместно с ppp -- скопируйте его в /etc/ppp/ip-up.d.

Если последние две строки в сценарии порождают сообщения об ошибке -- обновите версию tc!

15.10.1. Начнем с оптимизации пропускной способности.

Для начала создадим несколько дисциплин (qdiscs), которые будут обслуживать трафик. Первой создается htb qdisc с 6-ю классами и различными приоритетами. Каждому классу назначена определенная пропускная способность, но при этом они могут задействовать неиспользуемую пропускную способность, если она не занята другими классами. Напомню, что классы с более высоким приоритетом (т.е. с более низким числом prio) будут получать "излишек" канала первыми. Подключение к Интернет осуществляется через модем ADSL, с пропускной способностью для входящего трафика 2 Мбит/сек, исходящего -- 300 Кбит/сек. Я ограничиваю исходящую пропускную способность величиной в 240 Кбит/сек по той простой причине, что это максимальное значение, при котором время ожидания отклика остается минимальным. Величина этот параметра может быть определена экспериментально, путем наблюдения за изменением времени отклика при изменении величины пропускной способности.

Для начала, присвойте переменной CEIL величину, составляющую 75% от общей пропускной способности для исходящего трафика. Там, где я использую eth0 -- назначьте свой интерфейс, который "смотрит" в Интернет. Сценарий (на языке командной оболочки), выполняющий настройку, начинается со следующих строк:

CEIL=240
tc qdisc add dev eth0 root handle 1: htb default 15
tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil 80kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10        
        

+---------+
| root 1: |
+---------+
     |
+---------------------------------------+
| class 1:1                             |
+---------------------------------------+
  |      |      |      |      |      |      
+----+ +----+ +----+ +----+ +----+ +----+
|1:10| |1:11| |1:12| |1:13| |1:14| |1:15| 
+----+ +----+ +----+ +----+ +----+ +----+         
        

15.10.2. Классификация пакетов.

Мы создали различные классы обработки трафика, но классификация пока отсутствует, поэтому, к настоящему моменту, весь трафик пойдет через класс 1:15 ( который назначен классом по-умолчанию: tc qdisc add dev eth0 root handle 1: htb default 15 ). Теперь самое главное -- нужно распределить трафик по имеющимся классам.

Устанавим фильтры, которые будут выполнять классификацию пакетов, основываясь на метках iptables. Мне нравятся iptables за их чрезвычайную гибкость и за возможность подсчитывать количество пакетов, пропущенных тем или иным правилом. Добавим в сценарий следующие строки:

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15        
        

Для начала необходимо разобраться с тем, как движутся пакеты через iptables:

        +------------+   принятие     +---------+               +-------------+
Вход ---| PREROUTING |--- решения о --| FORWARD |-------+-------| POSTROUTING |- Выход
        +------------+  маршрутизации +---------+       |       +-------------+    
                             |                          |
                        +-------+                    +--------+   
                        | INPUT |-Локальные процессы-| OUTPUT |
                        +-------+                    +--------+        
        

Добавим правило iptables, которое будет выполнять SNAT, что позволит пользователям локальной сети общаться с внешним миром, и разрешим форвардинг пакетов:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -o eth0 -j SNAT --to-source 212.170.21.172          
        

tc -s class show dev eth0        
        

iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN        
        

tc-s класс показывают dev eth0
        

iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x5
iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j RETURN
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x6
iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j RETURN        
        

iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j RETURN        
        

iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j RETURN        
        

iptables -t mangle -A PREROUTING -j MARK --set-mark 0x6        
        

Нелишним будет добавить те же правила в цепочку OUTPUT, заменив имя цепочки PREROUTING на OUTPUT (s/PREROUTING/OUTPUT/). Тогда трафик, сгенерированный локальными процессами на маршрутизаторе, также будет классифицирован по категориям. Но, в отличие от вышеприведенных правил, в цепочке OUTPUT, я устанавливаю метку -j MARK --set-mark 0x3, таким образом трафик от маршрутизатора получает более высокий приоритет.

15.10.3. Дополнительная оптимизация

В результате приведенных настроек, мы получили вполне работоспособную конфигурацию. Однако, в каждом конкретном случае, эти настройки всегда можно немного улучшить. Найдите время и проследите -- куда идет основной трафик и как лучше им распорядиться. Я потратил огромное количество времени и наконец довел свою конфигурацию до оптимального уровня, практически сведя на нет бесчисленные таймауты.

Если вдруг обнаружится, что через некоторые классы проходит подавляющее большинство трафика, то к ним можно прикрепить другую дисциплину организации очереди, чтобы распределить канал более равномерно:

tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10        
        

15.10.4. Выполнение настроек во время загрузки системы.

Уверен, что можно найти множество способов, чтобы произвести настройку маршрутизатора во время загрузки. Для себя я создал скрипт /etc/init.d/packetfilter, который принимает команды [start | stop | stop-tables | start-tables | reload-tables]. Он конфигурирует дисциплины (qdiscs) и загружает необходимые модули ядра. Этот же сценарий загружает правила iptables из файла /etc/network/iptables-rules, которые предварительно могут быть сохранены утилитой iptables-save и восстановлены -- iptables-restore.

16.3.1. ARP и проксирование ARP

Когда некий узел сети желает установить связь с другим узлом, находящимся в том же физическом сегменте сети, то он отсылает пакет ARP-запроса, который, в переводе на человеческий язык, может звучать примерно так: "У кого установлен адрес 10.0.0.1? Сообщите по адресу 10.0.0.7". В ответ на запрос, 10.0.0.1 ответит коротким пакетом "Я здесь! Мой аппаратный адрес xx:xx:xx:xx:xx:xx".

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

При настройке моста мы можем указать ему на необходимость отвечать на ARP-запросы. Это вынудит узлы сети передавать ARP-запросы мосту, который затем обработает их и передаст на соответствующий интерфейс.

Таким образом, всякий раз, когда компьютер по одну сторону моста запрашивает аппаратный адрес компьютера, находящегося по другую сторону, то на запрос отвечает мост, как бы говоря "передавай все через меня".

Вследствие чего весь трафик попадет на мост и будет передан в нужном направлении.

16.3.2. Реализация

В ранних версиях Linux, для реализации проксирования протокола ARP, вам пришлось бы настраивать ядро. Для того, чтобы сконфигурировать псевдо-мост, вам пришлось бы вручную описать все маршруты по обе стороны моста И создать соответствующие правила. Это требовало достаточно большого объема ручного ввода, что само по себе могло повлечь за собой большое число ошибок.

В Linux 2.4/2.5 (а возможно и в 2.2) все это было заменено установкой флага proxy_arp в файловой системе proc. Теперь процедура настройки псевдо-моста выглядит так:

1. Назначить IP-адреса интерфейсам с обоих сторон.

2. Создать маршруты, так чтобы ваша машина знала, какие адреса, по какую сторону находятся.

3. Включить проксирование ARP для обоих интерфейсов, например командами:

   echo 1 > /proc/sys/net/ipv4/conf/ethL/proxy_arp 
   echo 1 > /proc/sys/net/ipv4/conf/ethR/proxy_arp              
                 

   где символами L и R обозначены интерфейсы по одну и по другую сторону моста ( Left и Right -- "слева" и "справа").

Кроме того, не забывайте включить флаг ip_forwarding! Для истинного моста установка этого флага не требуется.

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

На Cisco для этого существует команда clear arp-cache, в Linux -- команда arp -d ip.address. В принципе, вы можете подождать, пока кэши очистятся самостоятельно, за счет истечения срока хранения записей, но это может занять довольно продолжительное время.

Вы можете ускорить этот процесс, используя замечательный инструмент arping, который во многих дистрибутивах является частью пакета iputils. Утилитой arping вы может отослать незапрошенные arp-сообщения, чтобы модифицировать удаленные кэши arp.

Это очень мощный метод, который, к сожалению, может использоваться злоумышленниками для нарушения правильной маршрутизации!

В Linux 2.4, возможно потребуется выполнить команду echo 1>/proc/sys/net/ipv4/ip_nonlocal_bind прежде, чем появится возможность отправлять незапрошенные arp-сообщения!

17.1.1. Предварительные условия.

17.1.2. Конфигурирование.

Рассмотрим конфигурирование Zebra на примере сети:

----------------------------------------------------
| 192.168.0.0/24                                   |
|                                                  |
|      Area 0    100BaseTX Switched                |
|     Backbone     Ethernet                        |
----------------------------------------------------
  |           |                |              |
  |           |                |              |
  |eth1       |eth1            |eth0          |
  |100BaseTX  |100BaseTX       |100BaseTX     |100BaseTX
  |.1         |.2              |.253          |
 ---------   ------------   -----------      ----------------
 |R Omega|   |R Atlantis|   |R Legolas|      |R Frodo       |
 ---------   ------------   -----------      ----------------
  |eth0         |eth0             |             |          |
  |             |                 |             |          |
  |2MbDSL/ATM   |100BaseTX        |10BaseT      |10BaseT   |10BaseT
------------   ------------------------------------       -------------------------------
| Internet |   | 172.17.0.0/16        Area 1      |       |  192.168.1.0/24 wlan  Area 2|
------------   |         Student network (dorm)   |       |       barcelonawireless     |
               ------------------------------------       -------------------------------        
        

hostname omega
password xxx 
enable password xxx
!
! Описание интерфейсов.
!
!interface lo
! пример описания интерфейса.
!
interface eth1
multicast
!
! Статический маршрут по-умолчанию
!
ip route 0.0.0.0/0 212.170.21.129
!
log file /var/log/zebra/zebra.log        
        

zebra=yes
ospfd=yes        
        

hostname omega
password xxx
enable password xxx
!
router ospf
  network 192.168.0.0/24 area 0
  network 172.17.0.0/16 area 1
!
! направить вывод на stdout в журнал
log file /var/log/zebra/ospfd.log        
        

17.1.3. Запуск Zebra

Теперь запустим Zebra. Сделать это можно вручную -- дав прямую команду zebra -d, либо с помощью сценария начальной загрузки -- /etc/init.d/zebra start. После запуска, в журнале ospfd.log, появятся строки, примерно с таким содержанием:

2002/12/13 22:46:24 OSPF: interface 192.168.0.1 join AllSPFRouters Multicast group.
2002/12/13 22:46:34 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:46:44 OSPF: SMUX_CLOSE with reason: 5
2002/12/13 22:46:54 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: SMUX_CLOSE with reason: 5   
2002/12/13 22:47:04 OSPF: DR-Election[1st]: Backup 192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2002/12/13 22:47:04 OSPF: DR-Election[2nd]: DR     192.168.0.1
2002/12/13 22:47:04 OSPF: interface 192.168.0.1 join AllDRouters Multicast group.
2002/12/13 22:47:06 OSPF: DR-Election[1st]: Backup 192.168.0.2
2002/12/13 22:47:06 OSPF: DR-Election[1st]: DR     192.168.0.1
2002/12/13 22:47:06 OSPF: Packet[DD]: Negotiation done (Slave).
2002/12/13 22:47:06 OSPF: nsm_change_status(): scheduling new router-LSA origination
2002/12/13 22:47:11 OSPF: ospf_intra_add_router: Start
        

И zebra, и ospfd допускают возможность интерактивного взаимодействия с ними через telnet:

$ telnet localhost zebra
$ telnet localhost ospfd        
        

root@atlantis:~# telnet localhost zebra
Trying 127.0.0.1...
Connected to atlantis.
Escape character is '^]'.

Hello, this is zebra (version 0.92a).
Copyright 1996-2001 Kunihiro Ishiguro.

User Access Verification

Password: 
atlantis> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.0.1, eth1
C>* 127.0.0.0/8 is directly connected, lo
O   172.17.0.0/16 [110/10] is directly connected, eth0, 06:21:53
C>* 172.17.0.0/16 is directly connected, eth0
O   192.168.0.0/24 [110/10] is directly connected, eth1, 06:21:53
C>* 192.168.0.0/24 is directly connected, eth1
atlantis> show ip ospf border-routers
============ OSPF router routing table =============
R    192.168.0.253         [10] area: (0.0.0.0), ABR
			   via 192.168.0.253, eth1
				 [10] area: (0.0.0.1), ABR
			   via 172.17.0.2, eth0        
        

root@omega:~# ip route
212.170.21.128/26 dev eth0  proto kernel  scope link  src 212.170.21.172 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1 
172.17.0.0/16 via 192.168.0.2 dev eth1  proto zebra  metric 20 
default via 212.170.21.129 dev eth0  proto zebra 
root@omega:~#         
        

Для захвата и анализа OSPF-пакетов можно воспользоваться командой:

tcpdump -i eth1 ip[9] == 89        
        

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

17.2.1. Конфигурация сети (пример).

Последующие примеры будем рассматривать на основе конфигурации сети, которая приведена ниже. AS 1 и 50 имеют еще ряд "соседей", но мы будем рассматривать только эти две Автономные Системы, в качестве своих "соседей". Взаимодействие между сетями, в данном примере, производится через туннели, но в общем случае это не обязательно.

В данном примере используются зарезервированные номера AS, поэтому вы должны будете подставить свои собственные числа.

          --------------------
          | 192.168.23.12/24 |
          |    AS: 23        |
          --------------------
            /             \
           /               \
          /                 \
------------------       ------------------
| 192.168.1.1/24 |-------| 10.10.1.1/16   |
|    AS: 1       |       |    AS: 50      |
------------------       ------------------        
        

17.2.2. Конфигурирование (пример).

Следующая конфигурация написана для узла 192.168.23.12/24, но может быть с легкостью адаптирована и для других узлов.

Начинается с установки некоторых общих параметров, таких как: имя хоста, пароль и ключи отладки:

! имя хоста
hostname anakin

! пароль
password xxx

! разрешить пароль (режим суперпользователя)
enable password xxx

! путь к файлу журнала
log file /var/log/zebra/bgpd.log

! отладка: выводить отладочную информацию (этот раздел позднее может быть удален)
debug bgp events
debug bgp filters
debug bgp fsm
debug bgp keepalives
debug bgp updates        
        

! RFC 1918 networks
access-list local_nets permit 192.168.0.0/16
access-list local_nets permit 172.16.0.0/12
access-list local_nets permit 10.0.0.0/8
access-list local_nets deny any        
        

! Собственный номер AS
router bgp 23

    ! IP-адрес маршрутизатора
    bgp router-id 192.168.23.12

    ! наша сеть, для оповещения "соседей"
    network 192.168.23.0/24

    ! объявлять о всех подключенных маршрутах (= непосредственно подключенных интерфейсах)
    redistribute connected

    ! объявлять о корневых маршрутах (= подставленных вручную)
    redistribute kernel
        

neighbor 192.168.1.1 remote-as 1
neighbor 192.168.1.1 distribute-list local_nets in
neighbor 10.10.1.1   remote-as 50
neighbor 10.10.1.1   distribute-list local_nets in        
        

17.2.3. Проверка конфигурации.

vtysh -- это мультиплексор, соединяющий все интерфейсы Zebra.

anakin# sh ip bgp summary 
BGP router identifier 192.168.23.12, local AS number 23
2 BGP AS-PATH entries
0 BGP community entries

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.0.1       4    50      35      40        0    0    0 00:28:40        1
192.168.1.1     4     1   27574   27644        0    0    0 03:26:04       14

Total number of neighbors 2
anakin#
anakin# sh ip bgp neighbors 10.10.0.1
BGP neighbor is 10.10.0.1, remote AS 50, local AS 23, external link
  BGP version 4, remote router ID 10.10.0.1
  BGP state = Established, up for 00:29:01
  ....
anakin#        
        

anakin# sh ip ro bgp 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

B>* 172.16.0.0/14 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 172.30.0.0/16 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.10/32 [20/0] via 192.168.1.1, tun0, 2d10h27m
B>* 192.168.5.26/32 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.36/32 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 192.168.17.0/24 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.17.1/32 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.32.0/24 [20/0] via 192.168.1.1, tun0, 2d10h27m
anakin#