UFW - Ubuntu firewall - такая нужная вещь? :)

Была как-то давно мысль посмотреть на все эти фронтенды к iptables, написанные для "упрощения жизни". Да, возможно, не все могут понимать синтаксис правил iptables, всю его гибкость и мощь, так что им нужно пользоваться чем-то более простым. Итак, сейчас речь пойдет про ufw - Ubuntu-фронтенд к iptables.
Наверное, использовать именно его - самый простой способ "защититься". Включается он просто -

$ sudo ufw enable

По-умолчанию он запрещает весь входящий траффик и разрешает исходящий:

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

Теперь посмотрим, что же стоит за всем этим...

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

# iptables -L -v -n
Chain INPUT (policy DROP 2 packets, 64 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  344 31500 ufw-before-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  344 31500 ufw-before-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   23  2608 ufw-after-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    5   160 ufw-after-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    5   160 ufw-reject-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    5   160 ufw-track-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ufw-before-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-before-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-after-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-after-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ufw-reject-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  254 23653 ufw-before-logging-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  254 23653 ufw-before-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   56  3591 ufw-after-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   56  3591 ufw-after-logging-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   56  3591 ufw-reject-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   56  3591 ufw-track-output  all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Что радует (или огорчает) - он по-умолчанию сразу разрешает DHCP запросы, так что хотя-бы DHCP-клиент у вас ломаться не должен. Одновременно с этим он разрешает и сервис avahi. Все остальное нужно разрешать самим. Кроме того, он настраивает логирование заблокированных пакетов, так что в dmesg или syslog они будут.

Как же после этого разрешать что-либо?

$ sudo ufw allow 22/tcp

Просто разрешить ssh. Или только себе, скажем:

$ ufw allow from 172.20.1.4 to any port 22 proto tcp

На этом моменте начинает казаться, что ufw писали фанатики синтаксиса ipfw. :)

Дальше - хуже. Удобства от ufw кончаются, как только вам нужно что-то более сложное, например, nat. Тут вам придется таки учить синтаксис iptables:

/etc/ufw/before.rules:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE
COMMIT

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

Кроссплатформенный путь для проверки порта TCP

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

Вот такой вывод обычно подсказывает, что соединение установить можно:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

А вот такой - что нельзя. И скорее всего потому что порт не прослушивается каким-либо приложением (либо незаметно закрыт фаерволом с REJECT --with tcp-reset)
$ telnet localhost 81
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Многие очень расстраиваются, если telnet после установки соединения не выходит.
Для того чтобы выйти из telnet в этом случае, нужно нажать то что называется Escape character - telnet нам его подсказывает - это Ctrl + ]. После этого вы увидите приглашение встроенной оболочки telnet (если не видно, попробуйте нажать enter), в котором можно просто набрать quit.

Еще один хинт - если вы вдруг куда-то (например, на другую систему) все-таки ходите через telnet и запустили telnet там, то ^] сработает для вашего локального telnet, но не для того, что запущен удаленно. Это решаемо. Выходим в оболочку локального telnet - ^] и меняем escape character на новый:
^]

telnet> set escape ^B

После этого ^] уже будет срабатывать для удаленного telnet-клиента (что логично).

В свеженьких Windows 7 telnet почему-то из установки по-умолчанию выпилили, так что придется ее сначала установить через панель управления. Это добавит геморроя для техподдержки, Microsoft, так держать :)

IPSec - что же это такое

Вот, как и обещал, да и пока есть время и энергия, чтобы начать.

IPSec - это широко используемая технология, которая позволяет добавить дополнительный уровень шифрования и проверки подлинности/целостности сообщений к любому траффику, который передается поверх IP. Ее используют как для создания VPN, так и просто для защиты отдельно взятых хостов или данных.
Принципиально в IPSec можно выделить три отдельные части:
1. это протокол AH, который позволяет подписывать/хешировать IP-пакеты, что позволяет проверять подлинность отправителя и целостность пакета. Он просто добавляет подписи к пакетам и ничего не шифрует.
2. Протокол ESP - Encapsulated Security Payload - позволяет шифровать все данные в пакете целиком, используя различные алгоритмы.
3. Протокол IKE, который опционально может использоваться для обмена ключами шифрования между сторонами.

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

IPSec может использоваться в двух разных режимах, у которых разные области применения.
1. Транспортный режим. Просто шифрует/подписывает пакеты с данными в соответствии с заданной политикой. Используется в соединениях хост-хост.
2. Туннельный режим. Используется на маршрутизаторах для создания шифрованных туннелей между приватными сетями через публичные сети, например Интернет. Отличается тем что траффик из защищаемой сети инкапсулируется в IP-пакеты вместе с заголовками и шифруется/подписывается, а затем отправляется другому маршрутизатору, который это расшифровывает и передает дальше.

Таким образом, есть различные режимы, в которых можно использовать IPSec:
1. Соединение хост-хост.
2. Соединение хост-шлюз.
3. Соединение шлюз-шлюз.

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

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

Основной сложностью в установке IPSec-соединений между различными ОS/устройствами является возможная несовместимость реализаций или разные множества поддерживаемых протоколов и методов аутентификации.
Об этом тоже пойдет речь.

NCSI.txt - ааа! Большой брат следит за мной!

Навеяно параноидальностью одного пользователя IRC

А именно - MS Windows Vista (а может и все более новые системы) сразу же после появления сетевого подключения делают примерно вот это:
1. Спрашивают у DNS адрес dns.msftncsi.com
2. Спрашивают у DNS адрес www.msftncsi.com
3. Скачивают файлик http://www.msftncsi.com/ncsi.txt

Что это? У людей истерика.

Это вот та самая штука, которая проверяет, есть ли у машины подключение к Internet. NCSI -Network Connectivity Status Indicator

Читать про это можно на MS TechNet
Там же написано как это, на ваш страх и риск, выключается.

Squid: отчет по посещенным доменам

На случай если маленькая конторка просит высылать краткий анализ логов сквида на мыло...

$ squid-parser.pl 2009-07-12 < squid-access.log | mail blabla@company.com 

Собственно, скрипт, наваянный на скорую руку:

#!/usr/bin/perl -w

# aggregates squid logs

use strict;

use POSIX qw(strftime);
my $pattern = $ARGV[0];


my $line;
my @fields;

my $date;

my $ip;
my $bytes;
my $url;

my %ipstats;

my %urlstats;
my %ipurlstats;
while ($line=<STDIN>)

{
        @fields = split ' ', $line;
        $date=POSIX::strftime("%Y-%m-%d %H:%M:%S", localtime($fields[0]));

        $ip=$fields[2];
        $bytes=$fields[4];

        $url=$fields[6];
        $url=~s/.*:\/\/([^\/]*)\/.*/$1/;

        if ($date =~ m/$pattern/)
        {

                $ipstats{$ip}+=$bytes;
                $ipurlstats{$ip}{$url}+=$bytes;


        }
}

my $urls;
my $mbytes;

while (($ip, $urls) = each (%ipurlstats))

{
        print "-------------------------------------------------\n";
        print "$ip:\n";

        print "----------------------------------------------- \n";
        foreach $url (sort {$urls->{$b} <=> $urls->{$a}} (keys %$urls))

        {
                print "$url: $urls->{$url} bytes \n";
        }

        $bytes = $ipstats{$ip};
        $mbytes = sprintf "%8.3f", $bytes/1024/1024;

        print "----------------------------------------------\n";
        print "Total: $bytes b ($mbytes MB)\n";
        print "----------------------------------------------\n\n";

}

Красная шляпка и IPSec

Когда все просто - транспортный режим и нужно только зашифровать весь траффик от хоста А до хоста Б все понятно - делаем ifcfg-ipsec0 с содержимым вида

ONBOOT=yes
TYPE=ipsec
DST=A.A.A.A
IKE_METHOD=PSK

ну и потом ifup ipsec0. Но вот захотелось посмотреть, как же можно прикрутить более сложную политику, скажем, требовать шифрования или аутентификации только для пакетов на определенный порт и тут магия вдруг неожиданно исчезла... (пробовал A.A.A.A:AA или A.A.A.A[AA]). Ковыряние в ifup-ipsec не помогло совершенно.



Неужели дальше все делается только руками?

OpenVPN: очень быстрый старт

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


Все что нужно сделать - это написать простой конфигурационный файл, сгенерировать ключ и запустить серверную и клиентскую часть.

На примере debian или ubuntu:
1. Устанавливаем OpenVPN (одинаково на сервере и на клиенте):

# aptitude install openvpn

Настраиваем сервер:
1. Создаем вот такой вот /etc/openvpn/openvpn.conf:

# Использовать tun-интерфейсы вместо tap
dev  tun
# Локальный IP и IP дальней стороны туннеля
ifconfig 192.168.111.1 192.168.111.2
# Местоположение общего ключа
secret  /etc/openvpn/openvpn.key
# Порт клиента и сервера
port   1194
# Используемый транспортный протокол
proto  udp
# Сжимаем пакеты с помощью lzo, используя адаптирующийся алгоритм. 
comp-lzo
# проверяем работу туннеля каждые 10 секунд и перезапускаем в случае обрыва через 60
keepalive 10 60
# Не проверять таймауты, если клиент не подключен
ping-timer-rem
# не выключаем интерфейс при перезапуске соединения
persist-tun
# Очень полезная опция - не перечитывать ключ при рестарте соединения. 
# Дело в том что OpenVPN может снижать привелегии (см ниже) при запуске после 
# чтения конфигурационного файла и ключа в целях безопасности. 
persist-key
# Пользователь, под которым работает демон после запуска
user  nobody
# Собственно, становиться ли демоном
daemon
# Куда пишем журнал. 
log-append /var/log/openvpn.log

После этого генерируем общий ключ для соединения:

# openvpn --genkey --secret /etc/openvpn/openvpn.key

Заметим, что он сразу создается с правильными правами - только root может прочитать его.
Перезапускаем OpenVPN:

# /etc/init.d/openvpn restart

Настраиваем клиента:
/etc/openvpn/openvpn.conf

# Единственная строка, которая отличает клиента от сервера - адрес удаленной стороны
remote   our.openvpn.server
dev  tun
# Здесь адреса концов туннеля просто меняются местами
ifconfig 192.168.111.2 192.168.111.1
secret  /etc/openvpn/openvpn.key
port   1194
proto  udp
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user  nobody
daemon
log-append /var/log/openvpn.log

Осталось только скопировать openvpn.key с сервера на клиента и перезапустить OpenVPN на клиенте:

# /etc/init.d/openvpn restart

Если что-то не работает, сначала смотрим лог (/var/log/openvpn.log).

МТС-Коннект

Так уж складывается, что каждый год в районе нового года у меня улучшаются качества беспроводного интернета.
В 2007 году у меня вообще появился такой интернет - через GPRS, все знают его скорости и задержки - на самом деле это около 6 кБ/с и в среднем RTT пакета составляет около 1000 мс. К концу года качество этой услуги упало катастрофически ). Частые разрывы связи, ухудшение RTT, вот как это стало выглядеть.
В 2008 году он вырос до EDGE, выросла только скорость, максимум до 30 кБ/с. Поначалу - без разрывов, скорость оставалась более-менее приличной. Качал гигабайтами в месяц. ) Но потом качество услуг стало ухудшаться. Появились потери пакетов, скорость упала, часто до уровня GPRS, несмотря на наличие покрытия EDGE. Я перестал принимать звонки во время работы в Internet. Нужно было что-то менять.
И вот, в 2009 году я заменил его на CDMA. Приобрел комплект "МТС Коннект", протестировал. В среднем качество связи удовлетворительное (но иногда все-таки пропадает сигнал, неожиданно и неизвестно куда), что особенно радует - RTT упал до 100-200 миллисекунд, так что стало проще работать с такими вещами как SSH и RDP... опять же, телефон свободен от интернета вообще. Единственное, что плохо - траффик стал несколько дороже. Но и скорость выросла - около 850кб/с вниз и 100кб/с вверх, не пределы конечно, но лучше чем было...

VLSM, CIDR и опять про маски сетей и адресацию.

Итак, мир давно отказался от классовой адресации. Сейчас классы сетей в основном используются только для назначения "умолчательной" классовой маски при настройке интерфейсов хостов. Вот, скажем, введете вы у себя в Windows в настройках tcp/ip адрес 10.0.0.1 - а он автоматически предложит маску 255.0.0.0. В остальном важность понятия класса сети уже утрачена.
Взамен пришли две технологии - VLSM, о которой я уже немножко писал и CIDR. Это две разные технологии, которые замечательно работают вместе и сетевым администраторам могут облегчать жизнь, если использовать их с умом (т.е. там где это реально нужно). Естественно, если у вас в конторе всего один офис из 7 компьютеров, вы можете вообще не изучать ничего из сетевых технологий - вам на этом месте это даже не пригодится. )

Итак, как я уже говорил - VLSM позволяет разделять сети на меньшие по размеру подсети, что позволяет экономить адреса (реальный денежный эквивалент этой экономии получается, если речь идет о покупке подсетей зарегистрированных публичных IP у провайдера)
Забавно, что вместо ручного подсчета есть онлайн и оффлайн-калькуляторы для разбиения адресного пространства. Например, http://www.vlsm-calc.net. ) Но для понимания механизма, полезно все-таки иногда посчитать вручную.
Так как про разбиение диапазонов адресов на подсети я уже писал, пришло время рассказать и об обратной процедуре.
Эта процедура как раз и является частью технологии CIDR и позволяет экономить:
1. На количестве забиваемых руками в таблицу маршрутизации записей.
2. На количестве передаваемых маршрутов в обновлениях протоколов динамической маршрутизации.
3. На числе записей, которые нужно обрабатывать маршрутизатору при поиске маршрутов для каждого пакета.
А называется это "суммирование маршрутов".

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

CIDR расшифровывается как "Бесклассовая междоменная маршрутизация" (Classless interdomain routing).
CIDR привносит новую и очень краткую форму записей масок - это запись маски в виде количества установленных в "1" бит маски.
Например - 10.0.0.0/8 - означает маску 255.0.0.0 - т.к. 8 бит маски установлены в "1". 192.2.0.0/30 - это 255.255.255.252 - т.к. 30 бит маски установлены в "1", и это просто можно посчитать, переведя маску в двоичный вид.
Для ленивых в Википедии есть табличка, которая поможет перевести такую маску в обычный десятичный вид и наоборот.
Итак, а что же есть суммирование маршрутов?



Ну, возьмем такой пример - допустим у нас есть маршрутизатор, у которого есть "аплинк" в виде другого маршрутизатора, с одной стороны, и две сети - например, 192.168.0.0/24 и 192.168.1.0/24 - с другой. Ну вот прямо как на рисунке. Если перевести оба этих числа в двоичный вид и отсчитать слева совпадающую часть и закрыть ее маской - мы получим суммарную маску для этих двух сетей. :

11000000.10101000.00000000.00000000
11000000.10101000.00000001.00000000
11111111.11111111.11111110.00000000

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

И добавив один этот маршрут - 192.168.0.0/23 - на аплинк, мы вполне нормально обеспечим маршрутизацию пакетов в эти обе сети через наш роутер.

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

О настройке RIPv1 в Windows 2003 Server

Я не знаю, как Microsoft позиционирует свою систему на маршрутизаторы и почему, потому что, имхо, это не лучший выбор по соотношению цены и возможностей. Но Windows Server поддерживает динамическую маршрутизацию и RIP в том числе. Как обычно, есть два варианта настройки - через rrasmgmt.msc и netsh

Рассмотрим первый вариант.

Пуск -> Выполнить -> rrasmgmt.msc

Получаем консоль управления маршрутизацией и удаленным доступом. Удалим оттуда маршруты, которые мы добавили ранее. Далее кликнем правой кнопкой своего грызуна на "General" и выберем пункт "New Routing Protocol".



В появившемся окне выбираем "RIPv2 for Internet Protocol".
У нас в дереве под "IP Routing" появится соответсвующая ветка, тыкая опять же на которую правой кнопкой, можно добавлять интерфейсы, которые будут участвовать в работе протокола. Добавим туда все интерфейсы, кроме Control - RIP на нем работать не должен.



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



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



На вкладке "Security" можно настроить фильтры для обновлений - какие принимать и какие рассылать (или не принимать и не рассылать).



На вкладке "Neighbors" можно настроить отношения с соседями. Либо вы общаетесь с ними стандартным методом, либо прописываете дополнительных соседей, которым обновления будут посылаться направленно, либо - всем соседям будете посылать обновления направленно.



На вкладке "Advanced" включаются и отключаются дополнительные функции RIP - расщепление горизонта, poisoned reverse и триггерные обновления. Кроме того, можно поменять умолчательные значения таймеров и задать дополнительные условия для рассылки маршрутов на хосты или сети, а также маршрут по-умолчанию. Здесь лучше оставить все как есть. )



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

Как я уже и говорил, аналогичные действия можно выполнить с помощью netsh. Только этот интерфейс не назовешь особенно удобным.
Итак, если теперь снова удалить RIP из протоколов маршрутизации и пойти в netsh...
Для начала установим RIP:

C:\Documents and Settings\Administrator>netsh
netsh>routing ip rip
netsh routing ip rip>install
Ok.

Затем, то же самое что и в консоли - добавим интерфейсы с настройками:

netsh routing ip rip>add int "Stub3" announce=rip1 accept=rip1
Ok.

netsh routing ip rip>a int "n253" ann=rip1 acc=rip1
Ok.

netsh routing ip rip>a int "n254" ann=rip1 acc=rip1
Ok.

netsh routing ip rip>

Ну и напоследок - проверим таблицу маршрутизации на предмет появляющихся там маршрутов от соседей:

netsh>routing ip sh rtmr

            Prefix  Protocol    Prf  Met  Gateway          Vw  Interface
------------------  ----------  ---  ---  ---------------  --  ----------------
        10.0.0.0/8  Local         1   10  10.0.0.7         UM  Control
       10.0.0.7/32  Local         1   10  127.0.0.1        U   Loopback
 10.255.255.255/32  Local         1   10  10.0.0.7         UM  Control
       127.0.0.0/8  Local         1    1  127.0.0.1        U   Loopback
      127.0.0.1/32  Local         1    1  127.0.0.1        U   Loopback
    192.168.3.0/24  Local         1   10  192.168.3.1      UM  Stub3
    192.168.3.1/32  Local         1   10  127.0.0.1        U   Loopback
  192.168.3.255/32  Local         1   10  192.168.3.1      UM  Stub3
    192.168.4.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.250.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.251.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.252.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.253.0/24  Local         1   10  192.168.253.2    UM  n253
  192.168.253.2/32  Local         1   10  127.0.0.1        U   Loopback
192.168.253.255/32  Local         1   10  192.168.253.2    UM  n253
  192.168.254.0/24  Local         1   10  192.168.254.2    UM  n254
  192.168.254.2/32  Local         1   10  127.0.0.1        U   Loopback
192.168.254.255/32  Local         1   10  192.168.254.2    UM  n254
       224.0.0.0/4  Local         1   10  10.0.0.7         UM  Control
       224.0.0.0/4  Local         1   10  192.168.3.1      UM  Stub3
       224.0.0.0/4  Local         1   10  192.168.253.2    UM  n253
       224.0.0.0/4  Local         1   10  192.168.254.2    UM  n254
255.255.255.255/32  Local         1    1  10.0.0.7         UM  Control
255.255.255.255/32  Local         1    1  192.168.3.1      UM  Stub3
255.255.255.255/32  Local         1    1  192.168.253.2    UM  n253

Вот, собственно, и вся настройка. )

Как включить и настроить Routed в BSD-системах

Тема эта - больше классика, чем практически полезная, потому что routed морально устарел. Но мне очень хотелось попробовать. )

Итак, чтобы включить routed в BSD-системе, необходимо в случае FreeBSD добавить вот такие строки в /etc/rc.conf:

router_flags=""
router="/sbin/routed"
router_enable="YES"

Либо, в случае OpenBSD - достаточно просто исправить "routed_flags="NO"" на что-то другое, например просто убрать "NO" в том же /etc/rc.conf:

router_flags=""

Можно, конечно, в соответстии с man routed, задать все опции в этих самых кавычках, но так как нам нужен RIP-демон, мы оставим конфигурацию по-умолчанию без ключей и будем пользоваться /etc/gateways для для его настройки. Routed сам определит, что он запущен на маршрутизаторе и начнет распространять маршруты. (Условия для этого - gateway="yes" и наличие более одного сетевого интерфейса).
Кроме RIP этот демон поддерживает и другие методы настройки маршрутизации, например, протокол ICMP, а точнее - сообщения, которые отвечают за анонс/поиск/объявление маршрутизатора. Но так как эти функции пока выходят за пределы рассказа про RIP, рассматривать их я не буду. Да и они, опять же - мало применимы практически и больше относятся к старой доброй классике...
Итак, судя по топологии из предыдущих постов, у нас есть по крайней мере один интерфейс, на котором мы RIP использовать не должны.
Поэтому наш /etc/gateways у нас будет выглядеть вот так:

if=lnc4 no_rip passive
no_rdisc

Он в первую очередь отключает рассылку обновлений через интерфейс lnc4, во вторых - отключает ICMP-функции по работе с маршрутами.

Но на OpenBSD такой метод запрета рассылки анонсов почему-то не прокатил. Поэтому в hostname.pcn3 к настойкам интерфейса я просто добавил метрику 16, что сделало маршрут в сеть на этом интерфейсе недоступным для RIP.:

# cat /etc/hostname.pcn3
inet 10.0.0.5 255.0.0.0 NONE description "Control Interface" metric 16

Да, и надо не забыть запустить routed:

# routed

Для отладки полезно использовать ключи -d и -t:

# routed -d -t 
-- 08:25:51 --
Tracing actions started
Add interface lo0                 -->/32             <loopback> <passive> 
RCVBUF=61440
Add interface pcn0 127.0.0.1      -->/24              
turn on RIP
Add interface pcn1 192.168.1.0    -->/24              
Add interface pcn2 192.168.249.0  -->/24              
Add interface pcn3 192.168.255.0  -->/8              metric=16 <passive> 
start suppying routes
Add    127.0.0.1       -->10.0.0.0         metric=16 <if> pcn3 08:25:51
Add    192.168.1.1     -->192.168.255.0    metric=0  <if> pcn2 08:25:51
Add    192.168.249.1   -->192.168.249.0    metric=0  <if> pcn1 08:25:51
Add    10.0.0.0        -->192.168.1.0      metric=0  <if> pcn0 08:25:51
Add    10.0.0.5/32     -->127.0.0.1        metric=0  <if> lo0 08:25:51

Еще один метод отладки - это использование tcpdump:

# tcpdump -s 512 -i pcn1 -n udp port 520
tcpdump: listening on pcn1, link-type EN10MB
08:29:45.192544 192.168.249.2.520 > 192.168.249.255.520:  RIPv1-resp [items 9]:
{192.168.2.0}(3) {192.168.3.0}(4) {192.168.4.0}(2) {192.168.6.0}(1) 
{192.168.250.0}(1) {192.168.251.0}(2) {192.168.252.0}(2) {192.168.253.0}(2) 
{192.168.254.0}(3) (DF)

Все это позволяет увидеть и то, что рассылает routed, и то, что он получает от соседей. В tcpdump мы видим как раз один из пакетов, которые выслала Quagga на linux-роутере, с маршрутами в известные ей сети.

Иными словами, настройка routed практически тривиальна и не сулит ничего сложного. Кроме RIPv1 он поддерживает и RIPv2. Кроме того, в нем отстутвуют настройки поведения протокола. И почему-то он ведет себя иногда довольно-таки странно. В общем, я так и не понял его местами. Например, в openbsd он почему-то не хочет делать ращепление горизонта, хотя в мануале написано - что он просто не умеет не делать этого.

Настройка RIP в Cisco IOS и Quagga.

Так как в Debian просто нет routed, я использую другой демон динамической маршрутизации - Quagga. Это форк другого демона - Zebra. Основной идеей в нем проглядывается попытка во всем быть похожей на Cisco IOS, поэтому настраиваются они в плане RIP одинаково. Ну почти. )


Итак, чтобы включить RIPv1 в Cisco IOS, достаточно такой последовательности команд:

router rip
 network 192.168.251.0
 network 192.168.252.0
 network 192.168.4.0
 network 192.168.253.0
 network 192.168.250.0

Мы просто включаем rip для перечисленного нами списка сетей. Характерная особенность конфигурации RIP - что любой введенный номер сети автоматически обрезается до классового номера сети.
Сама команда network включает указанную сеть в обновления RIP и одновременно активирует рассылку и прием обновлений RIP на интерфейсах, адреса которых попали в эти сети.


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


Чтобы проверить конфигурацию протоколов динамической маршрутизации в IOS, достаточно команды "show ip protocols"

c3745-center#sh ip proto
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 24 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       1     1 2                                  
    FastEthernet0/1       1     1 2                                  
    FastEthernet1/0       1     1 2                                  
    FastEthernet2/0       1     1 2                                  
    FastEthernet3/0       1     1 2                                  
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    192.168.4.0
    192.168.250.0
    192.168.251.0
    192.168.252.0
    192.168.253.0
  Routing Information Sources:
    Gateway         Distance      Last Update

Вывод перечислит нам списки фильтров рассылки/приема обновлений для сетей, установки таймеров RIP, типы маршрутов, которые распространяются RIP, какие версии обновлений рассылаются и принимаются интерфейсами и какими. Включена ли суммаризация - об этом подробнее в RIPv2, а также список сетей, для которыx RIP включен. Кроме того, мы могли увидеть список соседей, от которых мы получали обновления - но пока он пуст. )


Теперь установим на linux-роуетере демон Quagga и настроим его:

stasikos@linux-router:~$ sudo aptitude install quagga 

после установки необходимо активировать zebra и ripd в /etc/quagga/daemons:

zebra=yes
ripd=yes

И создадим пустой конфиг для zebra и ripd:

touch /etc/quagga/zebra.conf
touch /etc/quagga/ripd.conf

Теперь рестартуем quagga:

root@linux-router:/etc/quagga# /etc/init.d/quagga restart

После этого, можно подсоединиться к "консоли" Quagga с помощью vtysh:

root@linux-router:/etc/quagga# vtysh

Hello, this is Quagga (version 0.99.5).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

linux-router# 

Не пугаемся. Мы оказались в режиме, который в IOS называется "Privelegied EXEC Mode". Теперь мы можем перейти в режим глобальной конфигурации маршрутизатора и настроить себе rip )

linux-router# conf t
linux-router(config)# router rip
linux-router(config-router)# network 192.168.6.0/24
linux-router(config-router)# network 192.168.249.0/24
linux-router(config-router)# network 192.168.250.0/24

Уже заметна разница между Quagga и IOS - во-первых, Quagga требует ввода маски сети. Во-вторых, она поддерживает указание маски через ее длину. )


Аналог show ip protocols rip в Quagga - это show ip rip status:

Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in -1203234300 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interface is not set
  Incoming update filter list for all interface is not set
  Default redistribution metric is 1
  Redistributing:
  Default version control: send version 2, receive any version 
    Interface        Send  Recv   Key-chain
    eth0             2     1 2    
    eth1             2     1 2    
    eth2             2     1 2    
  Routing for Networks:
    192.168.6.0/24
    192.168.249.0/24
    192.168.250.0/24
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
    192.168.250.2            0         0       120   00:00:03
  Distance: (default is 120)
 

Кстати, внизу мы видим соседнюю циску. Это не может не радовать. Но она нас не видит. Очевидно, Quagga по-умолчанию рассылает обновления версии 2, что из вышепоказанного вывода мы и видим. ) Исправим это:

linux-router(config)# router rip
linux-router(config-router)# version 1

Вот теперь с3745-center нас увидит. Проверим, какие маршруты мы получили от него через RIP:

linux-router# sh ip ro rip

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

R   192.168.4.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46
R   192.168.251.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46
R   192.168.252.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46
R   192.168.253.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46

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

Протокол динамической маршрутизации RIP версии 1

Нет, RIPv1, конечно, R.I.P в каком-то смысле, но это фактически первый и самый простой протокол динамической маршрутизации, который был стандартизован, открыт и реализован практически в любой операционной системе.

Если мы наберем в поисковике фразу "RFC RIP", мы тут же найдем RFC 1058, в котором полностью описана история, работа и реализация такого протокола.

Этот документ описывает работу RIP в routed, стандартном юниксовом демоне динамической маршрутизации - самой первой практической реализации этого протокола. )

RIP является протоколом внутренней маршрутизации, основанном на дистанционно-векторном протоколе Беллмана-Форда.

Протокол ограничен максимальным расстоянием в 15 хопов (маршрутизаторов) между конечными сетями и не распространяет в своих обновлениях маски сети, то есть не поддерживает такие технологии как VLSM и CIDR. Кроме того, его использование может приводить к "маршрутным петлям", эффект от которых уменьшается только наличием поля TTL в заголовках IP-пакетов. Кроме того, мерой стоимости маршрута (и основанием для выбора между несколькими маршрутами в одну сеть) является только число хопов. RIP не может учитывать ни загрузку каналов, ни их пропускную способность.
В своей работе RIP использует udp-дейтаграммы, рассылаемые широковещательно с порта 520 на порт 520. Дейтаграмма имеет очень простой формат, в котором, к тому же, заложены возможности развития протокола. Фиксированная часть заголовка содержит только поле версии и тип дейтаграммы - запрос или ответ. Остальную часть занимают записи маршрутов, которые состоят из типа протокола, чья информация переносится (для IP это 2), адреса сети назначения, пары забитых нулями зарезервированных полей и поля метрики маршрута. Максимальный размер сообщения составляет 512 байт, что означает, что переносить в нем можно только 25 маршрутных записей (но это не значит, что больше 25 маршрутов вообще переносить нельзя - вполне себе можно делать это в отдельных сообщениях).

Как работает маршрутизатор с протоколом RIP.
Сразу после включения маршрутизатор рассылает широковещательно пакеты, содержащие его таблицу маршрутизации, в которой будут находиться только маршруты в подключенные сети. При этом для каждой записи он будет указывать метрику 1. То же самое делают и его соседи. Кроме того, он прослушивает сеть на предмет появления таких же сообщений от других маршрутизаторов и анализирует их.
Если в сообщении встречается маршрут в неизвестную до этого сеть, маршрутизатор добавляет ее в собственную таблицу маршрутизации.
Если в сообщении встречается маршрут в уже известную сеть, и его метрика меньше метрики уже имеющегося маршрута - он заменяет запись в своей таблице на новую. Если метрика больше - считается, что этот маршрут хуже и добавлять его не стоит. ) Поэтому он просто проигнорирует такую запись.
После того, как пройдет 30 секунд после первого обновления, маршрутизаторы повторяют эту процедуру снова, рассылая свои таблицы маршрутизации широковещательно. При этом стоит заметить, что полученные от соседей маршруты в подключенные к ним сети они будут рассылать уже с метрикой, большей на единицу, то есть равной двум. Это будет продолжаться, пока все маршрутизаторы в сети не будут иметь маршруты во все известные сети.
Время, которое будет затрачено на полное построение всех таблиц маршрутизации на всех маршрутизаторах в сети называется временем сходимости сети (convergence), и, с учетом 30-секундного интервала обмена маршрутами, для сети из трех маршрутизаторов, это время будет равно максимум 30 секундам, в случае если все маршрутизаторы просто включили одновременно. Для сети, в которой между двумя максимально удаленными сетями находится 16 маршрутизаторов (предел для RIP) это время составит уже 7 минут. Это также худшее время сходимости при добавлении новой сети.

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

Нам необходимо не только отслеживать появление новых сетей, но и исчезновение старых. Механизм для этого есть - для каждого маршрута, полученного через протокол RIP, в маршрутизаторе создается отдельный таймер, по истечении которого маршрут удаляется. Это время по-умолчанию установлено в 180 секунд, чтобы не считать маршруты недоступными в случае, если какие-то 1-4 пакета с обновлениями просто потеряются в сети.
Но стоит только промоделировать ситуацию с "отвалившейся" сетью на бумаге или на реальном железе, мы увидим, что в классическом варианте RIP она разрешается очень плохо. )
Дело в том, что маршрутизатор, сеть на котором была удалена из таблицы маршрутизации, тут же получит ее от соседа, хотя и с большей метрикой. И завернет весь траффик в нее - на соседа, и тут же образуется маршрутная петля. В течение 180 секунд, пока его сосед будет считать этот маршрут еще действительным, он будет пересылать пакеты в нее нашему роутеру, а он будет отсылать их обратно соседу - ведь маршрут в эту сеть он получил именно от него! ).
Но дальше ситуация становится еще более печальной. Как только маршрут удалится из таблицы второго маршрутизатора, он снова появится там с метрикой, выросшей на единицу - так как получит его сразу от соседей, образовав новые маршрутные петли. Ситуация будет развиваться в худшую сторону, образуя петли во всей сети, пока, наконец, метрика маршрута не станет равна 16. Это пометит маршрут как недоступный, и приведет к удалению его из таблицы маршрутизации (конечно, только если этот маршрут добавлен RIP). Таким образом, сеть все-таки сойдется, в самом плохом случае - через 48 минут. Это уже не такое приемлемое время, как 7 минут на "холодный старт" сети, с учетом того что все каналы связи будут заняты пересылкой пакетов в маршрутных петлях, вместо передачи полезных данных. Как раз тот случай, когда в математике все хорошо (сеть сошлась), но на практике неприемлемо (слишком долго сходилась).

С целью разрешить проблему сходимости сети для случаев, когда ранее доступные сети становятся недоступными, в RIP было добавлено два механизма.
1. Расщепление горизонта. Маршрутизатор анализирует маршруты перед отправкой и не рассылает через свои интерфейсы те маршруты, которые он получил через них же. Иными словами, если сеть отваливается, маршрутизатор не получит от соседа обновление через 180 секунд о маршруте, который он сам же ему отослал и петля образовываться не будет.
2. Отравление маршрутов или poisoned reverse. ) Маршрутизатор использует технику расщепления горизонта, но вместо того чтобы совсем не рассылать маршруты, полученные от соседей, им же - рассылает их с метрикой 16, сразу сообщая им о недоступности сети.

На самом деле в RIP может быть и больше таймеров - но особенности реализации все-таки присутствуют, как и умолчательные значения. Например, Cisco IOS после падения маршрута в первые 180 секунд считает его рабочим, далее - деактивирует, но все еще держит в таблице - причем, как "possibly down", с метрикой 16, пока не истечет еще один таймер - таймер захоронения. Опять же, чтобы не дай боже кто-нибудь не прислал его снова и не создал новую петлю )

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

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

О заголовке IP-пакета и назначении его полей.

Немножко перевода из RFC, а также про TTL и фрагментацию.


(RFC 791)

Заголовок пакета может занимать от 20 до 60 байт.

Version	IHL	Type Of Service	Total Lenght
Identification			Flags	Fragment Offset
Time To Live		Protocol	Header CheckSum
Source Address
Destination Address
Options			Padding

Поле Version (4 бита) - указывает на версию протокола IP, которой соответствует пакет. В настоящее время пакеты с таким заголовком содержат только значение "4".

IHL (4 бита) - Длина заголовка пакета - используется для определения границы, на которой заканчивается заголовок IP-пакета и начинаются данные, которые он переносит. Длина указывается в 32-битных словах.

Type Of Service (8 бит) - указывает на абстрактные параметры желаемого качества обслуживания для пакета. Может быть использовано маршрутизаторами и другими устройствами 3-го уровня для определения наиболее подходящего по параметрам маршрута. Основной выбор состоит между низкой задержкой, высокой надежностью или высокой пропускной способностью. При этом биты 0-2 указывают на приоритет пакета, бит 3 - на уменьшение задержки при доставке, бит 4 - на выбор маршрута с высокой надежностью доставки, бит 5 - выбор маршрута с наибольшей пропускной способностью, биты 6-7 - зарезервированы. На самом деле используется только внутри одной сети и может не сыграть вообще никакой роли при передаче пакета через Internet, так как политики обработки пакетов устанавливаются конкретной организацией, управляющей автономной системой.

Total Lenght (16 бит) - общая длина IP-пакета в байтах.

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

Дело в том, что в различных протколах канального уровня максимальный размер кадра может отличаться, а это значит, что максимальный размер IP-пакета ограничен этим самым размером, который называется MTU - Maximum Transfer Unit. Но так как при прохождении очередного маршрутизатора пакет может попасть в сеть с меньшим MTU, чем в той, в которой он был создан, он может быть разбит на меньшие части. При этом в заголовке каждой части будет указано одинаковое значение ID, которое говорит о том, к какому пакету эти части относились.

Flags - 3 бита - Поле флагов. Первый бит зарезервирован и всегда должен быть установлен в 0. Второй бит, при установке в значение "1" указывает на то, что фрагментация пакета запрещена (и если она понадобится, пакет не будет доставлен). Третий бит указывает на наличие или отсутствие следующего фрагмента этого пакета. Иными словами, установлен в 0 может быть либо, если пакет не фрагментирован, или если это - последний фрагмент пакета.

Fragment Offser - значение смещения начала фрагмента внутри оригинального пакета, единица в этом поле одначает 64 бита. Смещение первого фрагмента всегда равно 0.

Time To Live - используется для решения проблемы "count to infinity" и помогает маршрутизаторам "пристрелить" пакет, который слишком долго находится в сети. Уменьшается на единицу каждым маршрутизатором при пересылке пакета. Таким образом, даже если в сети есть маршрутная петля, пакет не будет пересылаться от одного маршрутизатора к другому и обратно вечно, а будет уничтожен, как только поле TTL примет значение 0.

Protocol - указывает номер протокола, PDU которого вложен внутрь этого IP-пакета.

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

Source Address (4 байта) - IP-адрес источника, отославшего пакет.

Destination Address (4 байта) - IP-адрес назначения, куда был послан пакет.

Поле опций (Options) - может появляться или не появляться в заголовке. Довольно-таки интересное поле. )
Опции могут быть двух типов - однобайтовые и многобайтовые. Многобайтовая опция состоит из полей "Тип опции", "Длина опции" и, собственно "данные опции". При этом "длина опции" - это общая длина поля, включая тип опции и поле длины.

Поле "Тип опции" содержит флаги - 1-й бит - нужно ли копировать опцию в каждый фрагмент пакета при фрагментации. 2-й бит - класс опции. 3-й бит - номер опции.

Классы опций - управляющая (0), зарезервировано (1), отладочная - (2) и опять зарезервированная (3).
Определены следующие номера опций:

Класс	Номер	Длина	Описание
0	0	-	Конец списка опций.
0	1	-	Поле-заполнитель, используемое для дополнения поля опций до кратной 32 бит границы заголовка
0	3	var	Включение мягкой маршрутизации от источника. Позволяет задавать маршрут пакета при его отправке.
0	9	var	Строгая маршрутизация от источника.
0	7	var	Запись маршрута. Включает запись адресов исходящих интерфейсов маршрутизаторов внутрь поля опций при пересылке пакетов.
2	4	var	Тайм-стамп опция. Включает запись временной метки на каждом маршрутизаторе, через который проходит пакет, при его пересылке.

Подробно об опциях можно почитать в RFC 791.

Динамическая маршрутизация

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

Такой подход позволяет снизить затраты труда администраторов сетей. Но у него есть и недостатки:
1. Протоколы динамической маршрутизации создают дополнительную нагрузку на сеть - для обмена информацией роутеры используют полосу пропускания. Не так, чтобы сильно, но факт остается фактом.
2. Протоколы динамической маршрутизации снижают безопасность сети. Дело в том, что пакеты, которые передаются между маршрутизаторами можно как перехватить для изучения, так и подделать и в протоколах нет средства для защиты от этого. Таким образом, злоумышленники могут провести как DOS-атаку, отключив какой-либо маршрут, либо перехватыват траффик в сети, заменив адрес маршрутизатора на адрес ложного маршрутизатора, который можно использовать для перехвата пакетов.
3. Настройка и использование протоколов динамической маршрутизации налагают на администратора сети дополнительное требование - знание и понимание принципов работы этих протоколов.
4. Использование динамической маршрутизации может повысить нагрузку на процессоры маршрутизаторов, в случае некоторых протоколов - достаточно сильно.

Все протоколы динамической маршрутизации классифицируются по различным признакам:

Протоколы внутренней маршрутизации.
Такие протоколы заточены под работу внутри автономной системы (Автономная система - это независимо управляемая одной организацией сеть с собственной политикой маршрутизации внутри). К ним относятся RIP, OSPF, IS-IS, IGRP, EIGRP.

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

Протоколы с поддержкой только классовой адресации
Эти протоколы не передают в информации о маршрутах маски сетей и поэтому уже вымерли. Иными словами, их нельзя применять в сетях с применением VLSM. (RIPv1, IGRP)

Протоколы с поддержкой бесклассовой адресации.
Противоположны протоколам с поддержкой только классовой адресации. Это RIPv2, OSPF, IS-IS, EIGRP

Протоколы, использующие в работе дистанционно-векторный алгоритм Беллмана-Форда.
Это RIP, IGRP, EIGRP
Это простые в реализации протоколы, маршруты в которых представляются векторами, направлением которых является адрес сети и следующий хоп, а длина зависит от числа хопов в сеть назначения.
После включения маршрутизаторы рассылают свою таблицу маршрутизации напрямую подключенным соседям, осуществляя таким образом заполнение их таблиц новыми маршрутами. Основной их недостаток - медленная "сходимость" сети. Т.е. полное обновление таблиц всех маршрутизаторов после изменений в сети может занимать продолжительное время. Этот недостаток исправлен в протоколе EIGRP, который, правда, стоит относить к "смешанным" протоколам, так как он все-таки отстраивает полную топологию связей в сети. Кроме того есть другой недостаток - они периодически рассылают полные таблицы маршрутизации, что в большой сети может вызвать интенсивное использование пропускной способности каналов связи.
Применение таких протоколов имеет смысл в сетях, построенных по звездообразной схеме, с наименьшим числом хопов между конечными маршрутизаторами, либо когда скорость сходимости не имеет значения. Либо если администраторы не имеют достаточной квалификации для понимания работы протоколов с отслеживанием состояний связей. =)

Протоколы, использующие алгоритм Дейкстры, или SPF, также известные как "протоколы с отслеживанием состояний связей"
Цель работы протокола - отстроить в памяти таблицу состояния связей в сети и, затем, на основании ее, используя SPF, отобрать кратчайшие маршруты во все известные сети, а затем добавить их в таблицу маршрутизации. Характеризуются низким использованием пропускной способности сети и быстрой сходимостью, но сильнее загружают процессор маршрутизатора из-за более сложных рассчетов при поиске оптимальных маршрутов. Такие протоколы - это OSPF, IS-IS.
Применять имеет смысл во всех случаях, в которых не подходят протоколы дистанционно-векторного типа.

Кроме них есть также path-vector протоколы, такие как BGP, но рассматривать их имеет смысл только администраторам автономных систем, так как внутри автономных систем и локальных сетей они не применяются.

Когда имеет смысл применять статическую маршрутизацию?
1. Когда сеть имеет топологию "hub-and-spoke", т.е. когда маршрутизаторы соединены вместе по схеме "звезда" и подключены к одному центральному маршрутизатору. В таком случае в их таблицах наиболее выгодно иметь только один маршрут по-умолчанию к центральному роутеру и уже на нем - статическую таблицу, обновляемую вручную.
2. Когда сеть небольшая и в ней очень редко происходят изменения топологии.

Во всех остальных случаях имеет смысл задействовать подходящий протокол динамической маршрутизации.

Статическая маршрутизация в Windows Server 2003

Взял триальный Windows Server 2003 R2. )
Да, они тоже умеют работать, как маршрутизаторы. Но способов настройки маршрутизаторов под Windows Server аж целых три.
Думаю, установку Windows описывать нет смысла.

Итак, первым делом каждый человек, которому чужд мазохизм, обязательно должен зайти в "папку" "Сетевые подключения" и переименовать каждый сетевой интерфейс в более понятный вид чем "Подключение по локальной сети #622". Ну и настроить IP-адреса и маски сети для каждого интерфейса. Кроме того - я активировал доступ к роутеру по RDP для удобства настройки.



Самый распространенный и простой способ настроить маршрутизацию в Windows Server - это оснастка "Маршрутизация и удаленный доступ". Запустить ее быстрее всего можно набрав "rrasmgmt.msc" в "Пуск->Выполнить".

Удобство этой штуки поражает воображение - как всегда, с одной консоли управления можно работать сразу с множеством серверов сразу. Но нам пока это не нужно. )

В дереве слева уже отображается наш сервер, нужно только выбрать его, нажать правую кнопку мыши и ткнуть "Configure and enable Routing and Remote Access".
Запустится мастер установки службы маршрутизации и удаленного доступа. Для нашего случая, единственный подходящий вариант - это "Custom configuration".
Среди предложенных к выбору сервисов после этого нужно отметить только LAN Routing - это и есть простая маршрутизация пакетов.

Next, Finish.
Разрешаем запустить службу.
После этого наш компутер в консоли получит зеленую стрелочку вверх, показывающую, что он является маршрутизатором. )

Если теперь тыкать на IP Routing -> Static Routes правой кнопкой мыши, можно добиться пункта меню "New static route", который позволяет добавить маршрут. Заполним таблицу маршрутизации с его помощью.



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

Первый способ оставим на потом - команду Route. В Windows есть более продвинутаяавтоматизируемая штука, которую зовут netsh. Вам просто необходимо полюбить ее! ) Поэтому я удалю все содержимое таблицы маршрутизации и остановлю саму службу.

Теперь делаю запуск этой же службы из консоли

sc config remoteaccess start= auto
sc start remoteaccess

А маршруты настраиваю с помощью netsh:

 netsh> routing ip
netsh routing ip> add persistentroute 192.168.1.0 255.255.255.0 nhop=192.168.254.1 name="n254"
netsh routing ip> add per 192.168.1.0 255.255.255.0 name="n254" nhop=192.168.254.1
netsh routing ip> add per 192.168.2.0 255.255.255.0 name="n254" nhop=192.168.254.1
netsh routing ip> add per 192.168.4.0 255.255.255.0 name="n253" nhop=192.168.253.1
netsh routing ip> add per 192.168.5.0 255.255.255.0 name="n253" nhop=192.168.253.1
netsh routing ip> add per 192.168.6.0 255.255.255.0 name="n253" nhop=192.168.253.1
netsh routing ip> add per 192.168.250.0 255.255.255.0 name="n253" nhop=192.168.253.1
netsh routing ip> add per 192.168.249.0 255.255.255.0 name="n254" nhop=192.168.254.1
netsh routing ip> add per 192.168.251.0 255.255.255.0 name="n253" nhop=192.168.253.1
netsh routing ip> add per 192.168.252.0 255.255.255.0 name="n253" nhop=192.168.253.1
netsh routing ip> add per 192.168.255.0 255.255.255.0 name="n254" nhop=192.168.254.1

Формат простой -
netsh - это пришлашение утилиты
routing - это настройка раздела маршрутизации
ip - настройка раздела ip
add - добавление
persistentroute - постоянного статического маршрута
далее указывается - номер сети, маска, name="название выходного интерфейса", nhop=Адрес следующего маршрутизатора
Можно вбивать это все в консоли. Можно поступить еще проще - сделать дамп конфигурации в файл, отредактировать и затем выполнить его! )

netsh dump > 1.txt
notepad 1.txt
netsh exec 1.txt

netsh позволяет также просмотреть таблицу маршрутизации
netsh ro ip sh rtmr (netsh routing ip show rtmroutes)

сделать это можно еще командой route print.

netsh также позволяет настраивать адреса сетевых интерфейсов, некоторые службы и т.д. Т.е. теоретически можно сохранять настройки большинства сервисов и потом восстанавливать их или копировать на другой сервер.
netsh, подобно iproute, IOS и некоторым другим, поддерживает сокращения для команд, но стоит быть внимательнее - вместо того чтобы ругаться на неоднозначность, эта штука выполняет первую попавшуюся совпадающую команду. Также в ней есть IOS-подобная контекстная справка (но кривая до безобразия) по клавише "?".

Поднимаем маршрутизатор на FreeBSD

Самый свежий дистрибутив, который у меня оказался - это FreeBSD 6.2. На его примере и опишу установку маршрутизатора.

Вставляем диск, загружаемся с него и имеем перед собой утилиту sysinstall - надежду и гордость всего народа, пользующегося FreeBSD. =)

Первое, что нам предлагают выбрать - это страну, регион или группу. Я выбираю "Украина".

Второе - умолчательный драйвер консоли. Я выбрал Ukrainian KOI8-U keymap. Если на первом этапе выбрать другой регион, будут доступны другие варианты.

Теперь мы попали в главное меню sysinstall и здесь мы должны выбрать, а чо собсно делать дальше? Выбираем - Standard - обычную инсталляцию системы. )

И нам сразу же, сходу, предлагают разбить жесткий диск. Опять же, для этих целей не замораичваясь особо, выбираем - A = Use Entire Disk, и Q = Finish.

А затем - выбор загрузчика для системы. Выбираем BootMgr - обычный загрузчик FreeBSD.

Далее нам предлагают создать разделы для системы. Можно, конечно, извернуться и создавать разделы вручную. Для того чтобы показать пример настройки маршрутизатора это делать необязательно, поэтому выбираем A = Auto Defaults, и disklabel автоматически создаст 5 разделов - /, swap, /var, /usr, /tmp. Все будут с FS - UFS и включенными SoftUpdates, кроме /.

Q = Finish.

Переходим к выбору пакетов для установки. На маршрутизаторе вряд-ли пригодится что-то кроме User-раздела. Отмечаем его и жмем OK.

Так как мы устанавливаем систему с CD-ROM, выбираем источник для установки - CD/DVD. ОК.

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

Теперь система сама создаст файловые системы и установит выбранные пакеты. Можно пока покурить или выпить чего-нибудь. =)

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

1. Хотим ли мы настроить какие-нибудь Ethernet или SLIP/PPP интерфейсы? Очевидно, да. Подтягиваем свою схему сети и выделенные маршрутизатору адреса поближе.
Выбираем из списка каждый интерфейс и вводим в диалоговом окне его настройки - IP и маски. Но, гг, после настройки первого попавшегося интерфейса, нас сразу выкинет к следующему вопросу...
2. Должна ли эта машина работать маршрутизатором? Однозначно, да, ради этого мы ее и настраиваем.
3. Нужно ли настроить inetd и сетевые сервисы, которые он предоставляет. Вообще, inetd - замечательная штука, но простому маршрутизатору все его сервисы, среди которых echo, quote of the day и т.д. - не нужны. =) Поэтому, отказываемся.
4. Нужно ли разрешить вход через SSH. Да, надо. Для удобства настройки.
5. Нужен ли анонимный FTP-доступ к машине. Нет, не нужен. Если что-то понадобится записать или скачать - мы воспользуемся scp - копированием файлов через ssh.
6. Нужно ли настроить машину как NFS-сервер. NFS - это сервер для предоставления доступа к локальным директориям через сеть. Тут он не нужен, отказываемся.
7. Настраивать ли установки консоли - скорее да, чем нет. )
8. Выбираем шрифт - IBM 866.
9. Keymap - Russia KOI8-R.
10. Repeat - Fast (скорость повтора клавиатуры).
11. Saver - Blank (хранитель экрана)
12. ScreenMap - KOI8-R to 866
13. TTY - KOI8-R. Exit. )
14. Установить часовой пояс - да, выбрать свой. ) На вопрос, установлены ли часы в BIOS в UTC, скорее всего нужно ответить - нет. Если вы знаете, что это не так, вы ответите "Да". Если не знаете вообще что это значит - скорее "Нет", чем "Да". Я выбираю "Нет". Потому что часы у меня установлены по местному времени.
15. Нужно ли включать бинарную совместимость с Linux. Иными словами - включить ли возможность запускать приложения, скомпилированные для Linux в FreeBSD. На этом маршрутизаторе это не пригодится. В крайнем случае, можно настроить потом. Так что - нет.
16. Есть ли мышь в системе - скорее да, чем нет. Если настроить, можно получить полезную возможность выделять и копировать в консоли мышью.
17. Нам предоставлена возможность установки программного обеспечения из пакетов. Если у вас дистрибутив на паре CD, можете выбрать, что нужно. Я ставлю vim-lite из пакетов, потому что работать с обычным vi мне очень тяжело.
18. Добавление пользователей в систему. Можно создать для себя отдельного пользователя и добавить его в группу wheel.
19. И - финальный аккорд - установка пароля root. Требует пароля посложнее, поэтому лучше постараться. Ввод не отображается на экране никак.
20. Финальный вопрос - отвечаем "нет", если все настроили. Я сказал "да", вернулся и донастроил остальные 4 сетевых карты. Это можно сделать и после перезагрузки, введя в консоли команду "sysinstall" в любое время.

После перезагрузки займемся настройкой маршрутов.
синтаксис команды route в freebsd мало отличается от синтаксиса аналогичной команды в других *nix системах. Прописываются статические маршруты в /etc/rc.conf:

static_routes="Stub1 Stub3 Stub4 Stub5 Stub6 net249 net250 net252 net253"
route_Stub1="-net 192.168.1.0/24 192.168.255.1"
route_Stub3="-net 192.168.3.0/24 192.168.254.2"
route_Stub4="-net 192.168.4.0/24 192.168.251.1"
route_Stub5="-net 192.168.5.0/24 192.168.251.1"
route_Stub6="-net 192.168.6.0/24 192.168.255.1"

route_n249="-net 192.168.249.0/24 192.168.255.1"
route_n250="-net 192.168.250.0/24 192.168.255.1"
route_n252="-net 192.168.252.0/24 192.168.251.1"
route_n253="-net 192.168.253.0/24 192.168.254.2"

т.е. в строке static_routes мы указываем список названий маршрутов, а в route_имямаршрута - аргументы команды route, для добавления этого маршрута.

После правки выполним sh /etc/netstart для перезапуска сети.
В результате мы должны получить правильную таблицу маршрутизации. Просмотреть ее можно в FreeBSD командой netstat -rn:

beasty-router# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
10                 link#5             UC          0        0   lnc4
10.0.0.1           00:0c:29:b5:59:3b  UHLW        2       38   lnc4   1196
127.0.0.1          127.0.0.1          UH          0        0    lo0
192.168.1          192.168.255.1      UGS         0        0   lnc0
192.168.2          link#4             UC          0        0   lnc3
192.168.3          192.168.254.2      UGS         0        0   lnc2
192.168.4          192.168.251.1      UGS         0        0   lnc1
192.168.5          192.168.251.1      UGS         0        0   lnc1
192.168.6          192.168.255.1      UGS         0        0   lnc0
192.168.249        192.168.255.1      UGS         0        0   lnc0
192.168.250        192.168.255.1      UGS         0        0   lnc0
192.168.251        link#2             UC          0        0   lnc1
192.168.251.1      link#2             UHLW        4        0   lnc1
192.168.252        192.168.251.1      UGS         0        0   lnc1
192.168.253        192.168.254.2      UGS         0        0   lnc2
192.168.254        link#3             UC          0        0   lnc2
192.168.254.2      00:0c:29:29:ba:92  UHLW        3        0    lo0
192.168.255        link#1             UC          0        0   lnc0
192.168.255.1      link#1             UHLW        5        0   lnc0

Вот и все. Сделаем "connectivity test", пропинговав все интерфейсы уже работающих маршрутизаторов, и можем считать свою работу законченной, если все работает.

Поднимаем маршрутизатор на OpenBSD

Тут установка практически с нуля. Хотя-бы потому что раз от раза (потому что редко делаю такие вещи) я забываю, как, собственно, в ней диск размечать...

Итак, вставляем диск (У меня это OpenBSD 3.9) в привод, жмем Power и настраиваем в BIOS загрузку с DVD. Перезагружаемся.

По экрану пробегают синие строки с серыми буквами внутри.
В конце концов поялвяется вопрос: "(I)nstall, (U)pgrade or (S)hell?". На него, очевидно, нужно ответить "I", т.е. начать установку.
Система тут же спросит тип терминала. Я думаю, что лучше оставить как есть - vt220 - пусть эмулирует.
kbd(8) mapping? - я оставил none.
Далее паффи спрашивает, продолжать ли установку, предупреждая, что я по-идее должен был сделать резервные копии всех важных данных. Так как мы устанавливаем систему на новый компьютер, можно уверенно набирать "yes" и жать Enter.

Дальше нам показывает список доступных дисков для установки и предлагают ввести нужный. У меня он один - wd0. Соглашаюсь.
У меня тут же уточняют, хочу ли я использовать весь wd0 для установки OpenBSD. Я соглашаюсь, утвердительно набирая "yes"
Установщик запускает утилиту disklabel. Это самый сложный этап установки, на самом деле. Я снова забыл, как размечать жеский диск в OpenBSD. Поэтому перехожу к чтению мануала на эту утилиту - жму "?". Мне подсказывают, что полный мануал доступен по команде "M" и я ее ввожу. По предыдущему опыту я знаю, что системе как минимум нужен слайс, на нем - корневой раздел и раздел подкачки. Ищу команды для создания разделов...
После прочтения мануала я понял, что для создания разделов нужно пользоваться командой "а".

>a
partition[b] a
offset: [63]
size: [8385867] 8000000
FS type: [4.2BSD]
mount point: [none] /
>

Кажется, я вспомнил! ) В общем, я создал раздел для корневой фс, типа 4.2BSD, размером 80000000 байт.
Повторяю операцию для раздела подкачки:

>a
partition: [b]
offset: [8000063]
size: [385867]
FS type: [swap]

>
Т.е. я просто со всем согласился.
Теперь тыкаю "w" для записи новой таблицы разделов. И "q" чтобы выйти.
Теперь инсталлятор предупреждает меня что уничтожит все содержимое жесткого диска и спрашивает, в своем ли я уме. Я отвечаю "да", (и даже весел).

И все. Он тут же создал файловые системы на разделах и продолжил установку.
Дальше нас спрашивают про имя машины. Я назову ее "puffy-router", в честь символа OpenBSD.
"Настраивать ли сеть". Пожалуй, сейчас я от этого откажусь.
Теперь спрашивают рутовый пароль. Лучше ввести хороший пароль. Отображать ничего система при вводе не будет.
На вопрос об источнике установки, я отвечаю "cd". Меня спрашивают, какой именно, предлагая список. Соглашаюсь с единственным CDROM в системе. На путь к пакетам на диске отвечаю также, соглашаясь с умолчаниями.
Следующий вопрос касается, что устанавливать. Устанавливаю все предложенное, т.е. отвечаю просто done.
Больше ничего полезного не заметил. )

Началась установка системы. Заняла она около 5 минут. )
На второй вопрос "Location of sets", который подразумевает выбор еще одного источника для установки, отвечаю просто "done".
Далее разрешаю запускать сервис ssh по-умолчанию. Пригодится. И отказываю ntpd - он не нужен сейчас. X-server мне тоже не нужен - как можно заметить, я его даже не устанавливал.
Теперь финальный аккорд - установка часового пояса. Ввожу по памяти "Europe/Kiev" и установка завершается. Ввожу "halt" и перезагружаю свежеустановленную OpenBSD.

теперь очень хочется создать для себя удобную среду для работы.
Входим в систему.
Первым делом смонтирую DVD с пакетами для системы:

mount /dev/cd0a /mnt

теперь доустановлю кое-что:

cd /mnt/packages/i386
pkg_add vim-6.4.6p1-no_x11.tgz

Ура. Этого пока хватит.

Настраиваем сеть:

vim /etc/hostname.pcn0

Вбиваю конфиг для карты pcn0:

inet 192.168.1.0 255.255.255.0 NONE description "Stub1 Network"

и т.д. для каждой сетевой карты:

hostname.pcn1
inet 192.168.249.0 255.255.255.0 NONE description "To Linux-router"

hostname.pcn2
inet 192.168.255.0 255.255.255.0 NONE description "To FreeBSD-router"

hostname.pcn3
inet 10.0.0.5 255.0.0.0 NONE description "Control Interface"

Теперь стартуем эти интерфейсы:

sh /etc/netstart

Проверяем командой ifconfig и смотрим, что на каждом интерфейсе теперь правильный IP-адрес:

# ifconfig
...
pcn0: flags=8843 mtu 1500
lladdr 00:0c:29:c3:d0:2d
description: Stub1 Network
media: Ethernet autoselect (autoselect)
inet 192.168.1.0 netmask 0xffffff00 broadcast 192.168.1.255
...

Теперь займемся настройкой маршрутов.
Раскомментируем строку с net.inet.ip.forwarding=1 в /etc/sysctl.conf.
И теперь все в тех же /etc/hostname.if, пишем команды добавления маршрутов

/etc/hostname.pcn1
!route add 192.168.250.0/24 192.168.249.2
!route add 192.168.6.0/24 192.168.249.2
!route add 192.168.252.0/24 192.168.249.2
!route add 192.168.5.0/24 192.168.249.2
!route add 192.168.253.0/24 192.168.249.2
!route add 192.168.254.0/24 192.168.249.2
!route add 192.168.3.0/24 192.168.249.2
!route add 192.168.4.0/24 192.168.249.2
!route add 192.168.251.0/24 192.168.249.2
!route add 192.168.2.0/24 192.168.249.2

и в

/etc/hostname.pcn2
!route add 192.168.250.0/24 192.168.255.2 -mpath
!route add 192.168.6.0/24 192.168.255.2 -mpath
!route add 192.168.252.0/24 192.168.255.2 -mpath
!route add 192.168.5.0/24 192.168.255.2 -mpath
!route add 192.168.253.0/24 192.168.255.2 -mpath
!route add 192.168.254.0/24 192.168.255.2 -mpath
!route add 192.168.3.0/24 192.168.255.2 -mpath
!route add 192.168.4.0/24 192.168.255.2 -mpath
!route add 192.168.251.0/24 192.168.255.2 -mpath
!route add 192.168.2.0/24 192.168.255.2 -mpath

mpath пришлось добавить, так как openbsd не позволяет иметь двух маршрутов в одну и ту же сеть. И при этом не понимает понятия "метрика".

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

sh /etc/netstart

Ну и в конце концов остается проверить связь с linux-router и c3745-center:

# ping 192.168.250.2
PING 192.168.250.2 (192.168.250.2): 56 data bytes
64 bytes from 192.168.250.2: icmp_seq=0 ttl=254 time=620.244 ms

# ping 192.168.249.1
PING 192.168.249.1 (192.168.249.1): 56 data bytes
64 bytes from 192.168.249.1: icmp_seq=0 ttl=255 time=2.327 ms

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

В продолжение темы предыдущего поста - статическая маршрутизация на Cisco

Осталась все та же самая топология и в ней уже настроен Linux-маршрутизатор. Теперь пришло время настроить соседний с ним Cisco-маршрутизатор. Все это работает внутри VMWare Workstation 6, Cisco эмулируется dynamips из Debian Etch, в него загружен entbase-IOS для Cisco 3745.

Просто приведу конфиг роутера =)

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
! Название маршрутизатора. Чтобы не путаться, если их много.
hostname c3745-center
!
boot-start-marker
boot-end-marker
! пароль на Privelegied EXEC Mode
enable password cisco
!
no aaa new-model
!
resource policy
!
memory-size iomem 5
ip cef
!Настройки интерфейсов маршрутизатора
interface FastEthernet0/0
 mac-address 000c.298a.0b72
 ip address 192.168.250.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 mac-address 000c.298a.0b7c
 ip address 192.168.252.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1/0
 description To Windows XP Router
 mac-address 000c.298a.0b86
 ip address 192.168.4.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 mac-address 000c.298a.0b90
 ip address 192.168.253.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet3/0
 mac-address 000c.298a.0b9a
 ip address 192.168.251.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet4/0
 mac-address 000c.298a.0ba4
 ip address 10.0.0.2 255.0.0.0
 duplex auto
 speed auto
! Толпа статических маршрутов.
ip route 192.168.1.0 255.255.255.0 FastEthernet0/0 192.168.250.1
ip route 192.168.1.0 255.255.255.0 FastEthernet3/0 192.168.251.2 2
ip route 192.168.1.0 255.255.255.0 FastEthernet2/0 192.168.253.2 3
ip route 192.168.2.0 255.255.255.0 FastEthernet3/0 192.168.251.2
ip route 192.168.2.0 255.255.255.0 FastEthernet2/0 192.168.253.2 2
ip route 192.168.2.0 255.255.255.0 FastEthernet0/0 192.168.250.1 3
ip route 192.168.3.0 255.255.255.0 FastEthernet2/0 192.168.253.2
ip route 192.168.3.0 255.255.255.0 FastEthernet3/0 192.168.251.2 2
ip route 192.168.3.0 255.255.255.0 FastEthernet0/0 192.168.250.1 3
ip route 192.168.5.0 255.255.255.0 FastEthernet0/1 192.168.252.2
ip route 192.168.6.0 255.255.255.0 FastEthernet0/0 192.168.250.1
ip route 192.168.6.0 255.255.255.0 FastEthernet3/0 192.168.251.2 2
ip route 192.168.6.0 255.255.255.0 FastEthernet2/0 192.168.253.2 3
ip route 192.168.249.0 255.255.255.0 FastEthernet0/0 192.168.250.1
ip route 192.168.249.0 255.255.255.0 FastEthernet3/0 192.168.251.2 2
ip route 192.168.249.0 255.255.255.0 FastEthernet2/0 192.168.253.2 3
ip route 192.168.254.0 255.255.255.0 FastEthernet3/0 192.168.251.2
ip route 192.168.254.0 255.255.255.0 FastEthernet2/0 192.168.253.2
ip route 192.168.254.0 255.255.255.0 FastEthernet0/0 192.168.250.1 2
ip route 192.168.255.0 255.255.255.0 FastEthernet0/0 192.168.250.1
ip route 192.168.255.0 255.255.255.0 FastEthernet3/0 192.168.251.2
ip route 192.168.255.0 255.255.255.0 FastEthernet2/0 192.168.253.2 3
! Отключаем веб-интерфейс на хттп и хттпс.
no ip http server
no ip http secure-server
!
control-plane
! Настройка консоли - вход по паролю, дебаг синхронно с выводом на экран.
line con 0
 password cisco
 logging synchronous
 login
line aux 0
! И тоже самое - для виртуальных терминалов (чтобы можно было входить через telnet
line vty 0 4
 password cisco
 logging synchronous
 login
!
end

При настройке маршрутизатора, для собственно передачи в него конфига можно пользоваться разными способами. Можно просто перейти в global config режим с помощью команды "configure terminal" и скопипастить на консоль конфиг полностью.

Я поступил несколько иначе - я поднял у себя tftp-сервер и потом просто выполнил команду

copy start tftp

Роутер загрузил свой конфигурационный файл на тфтп-сервер, где я смог спокойно отредактировать его текстовым редактором, а потом, командой

copy tftp start

загрузил его назад на маршрутизатор. После команды "reload" я просто убедился, что все заработало как надо:

c3745-center#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.250.2   YES NVRAM  up                    up
FastEthernet0/1            192.168.252.1   YES NVRAM  up                    up
FastEthernet1/0            192.168.4.1     YES NVRAM  up                    up
FastEthernet2/0            192.168.253.1   YES NVRAM  up                    up
FastEthernet3/0            192.168.251.1   YES NVRAM  up                    up
FastEthernet4/0            10.0.0.2        YES NVRAM  up                    up

c3745-center#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.251.0/24 is directly connected, FastEthernet3/0
C    192.168.4.0/24 is directly connected, FastEthernet1/0
C    192.168.250.0/24 is directly connected, FastEthernet0/0
S    192.168.5.0/24 [1/0] via 192.168.252.2, FastEthernet0/1
S    192.168.249.0/24 [1/0] via 192.168.250.1, FastEthernet0/0
C    10.0.0.0/8 is directly connected, FastEthernet4/0
S    192.168.6.0/24 [1/0] via 192.168.250.1, FastEthernet0/0
S    192.168.255.0/24 [1/0] via 192.168.250.1, FastEthernet0/0
S    192.168.254.0/24 [1/0] via 192.168.253.2, FastEthernet2/0
                      [1/0] via 192.168.251.2, FastEthernet3/0
S    192.168.1.0/24 [1/0] via 192.168.250.1, FastEthernet0/0
C    192.168.253.0/24 is directly connected, FastEthernet2/0
S    192.168.2.0/24 [1/0] via 192.168.251.2, FastEthernet3/0
C    192.168.252.0/24 is directly connected, FastEthernet0/1
S    192.168.3.0/24 [1/0] via 192.168.253.2, FastEthernet2/0

Cisco вообще очень неохотно признается о неактивных сейчас маршрутах. Но они неожиданно возникают при отключении работающих интерфейсов, если на них оказываются завязаны активные маршруты. Поэтому все маршруты с явно указанной метрикой больше единицы сейчас в таблице маршрутизации не видно. Маршрутов в 192.168.254.0/24 сейчас активно два, это довольно-таки наглядно показано.

Дальше про статическую маршрутизацию (или настройка Linux-маршрутизатора)

Я хочу показать, как настраиваются маршрутизаторы и под Linux, и под FreeBSD, и под OpenBSD, и под Windows, и, собственно Cisco.

Для этого пришлось сварганить нижепоказанную топологию с аж 6-ю маршрутизаторами, разнообразно связанными между собой и с "тупиковыми" сетями, которые имеют выход в остальные сети через эти самые маршрутизаторы.
Кроме всего нижепоказанного, каждый роутер подсоединен к сети 10.0.0.0/8, через которую я ими управляю вне зависимости от того, какие интерфейсы у них настроены и какие маршруты есть.




Для начала настроим интерфейсы маршрутизатора, прописав IP-адреса и маски.

В Debian и похожих это делается через файл /etc/network/interfaces. Полученный файл у меня выглядит примерно так:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo eth0 eth1 eth2 eth3
iface lo inet loopback

iface eth0 inet static
        address 192.168.250.1
        netmask 255.255.255.0

iface eth1 inet static
        address 192.168.249.2
        netmask 255.255.255.0

iface eth2 inet static
        address 192.168.6.1
        netmask 255.255.255.0

iface eth3 inet static
        address 10.0.0.3
        netmask 255.0.0.0

В результате получается аж 4 строки в таблице маршрутизации:

linux-router:/home/stasikos# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.6.0     *               255.255.255.0   U     0      0        0 eth2
192.168.249.0   *               255.255.255.0   U     0      0        0 eth1
192.168.250.0   *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 eth3

первая - это маршрут в нашу локалку, второе - это маршрут на другой маршрутизатор (ОпенБСД), третья - маршрут на еще один маршрутизатор (Цыцка) и 4-й - это маршрут на отдельную сеть для управления. В соответствии с указанной топологией, нам требуется указать еще маршруты - во все остальные сети. В основном, все они будут лежать через разные интерфейсы и разные маршрутизаторы, но если нам абсолютно ложить на все, мы можем прописать их как дефолтный маршрут в куда-нить "наружу". Мы так делать не будем. Мы же все таки умнее...

Итак, анализируя топологию, можно сделать вывод, что "there is a more than one way to reach any network". Действительно, практически любая "тупиковая" сеть доступна нам как через eth0, так и через eth1. Очевидно, что для лучшей отказоустойчивости, имеет смысл прописать помимо одного короткого и оптимального - один длинный маршрут через другой интерфейс.
Всего на рисунке показано 6 "тупиковых" сетей и 7 "транзитных", с помощью которых маршрутизаторы связаны между собой. Очевидно, что при наличии трех интерфейсов, из которых один - тупик, у нас осталось 5 сетей-тупиков и еще 4 транзитных сети. Так как эти 5+4 сетей доступны через два интерфейса, нам нужно будет прописать аж 18 маршрутов. Нет, вы конечно, уже подумали про простое решение (какой-нибудь протокол маршрутизации), но я сегодня мазохист и буду заниматься прописыванием маршрутов руками. Ибо мы статической маршрутизацией занимаемся. Вспомним еще, что у нас много маршрутизаторов. Целых 6, и на каждом примерно то же нужно будет выполнить, чтобы вся сеть работала.

Итак, смотрим еще раз на топологию и видим...
Stub1 доступна как через опенбсд, так и через циску, но через опенбсд - ближе
Stub2 доступна так же, но через бсд - ближе
Ближайший маршрут во все другие сети лежит через циску.

как это записать? например, командой route
После чтения route(8) нам становится ясен синтаксис этой команды. Поэтому, забиваем сразу 10 маршрутов

linux-router# route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.249.1 metric 10
linux-router# route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.249.1 metric 10
linux-router# route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.250.2 metric 20
linux-router# route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.250.2 metric 20
linux-router# route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.250.2 metric 10
linux-router# route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.249.1 metric 20
linux-router# route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.249.1 metric 20
linux-router# route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.249.1 metric 20
linux-router# route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.250.2 metric 10
linux-router# route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.250.2 metric 10

Запись команды route малость неудобна и громоздка. Поэтому если установлен iproute, проще пользоваться им:
(здесь я буду писать маршруты уже не для "тупиковых" сетей)

linux-router# ip ro add 192.168.255.0/24 via 192.168.249.1 m 10
linux-router# ip ro add 192.168.255.0/24 via 192.168.250.2 m 20
linux-router# ip ro add 192.168.254.0/24 via 192.168.250.2 m 10
linux-router# ip ro add 192.168.254.0/24 via 192.168.249.1 m 20
linux-router# ip ro add 192.168.253.0/24 via 192.168.250.2 m 10
linux-router# ip ro add 192.168.252.0/24 via 192.168.250.2 m 10
linux-router# ip ro add 192.168.251.0/24 via 192.168.250.2 m 10
linux-router# ip ro add 192.168.253.0/24 via 192.168.249.1 m 20
linux-router# ip ro add 192.168.252.0/24 via 192.168.249.1 m 20
linux-router# ip ro add 192.168.251.0/24 via 192.168.249.1 m 20

Посмотрим получившуюся таблицу маршрутизации командой "route"

linux-router:/home/stasikos# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.252.0   192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.252.0   192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.254.0   192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.254.0   192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.251.0   192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.251.0   192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.253.0   192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.253.0   192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.255.0   192.168.249.1   255.255.255.0   UG    10     0        0 eth1
192.168.255.0   192.168.250.2   255.255.255.0   UG    20     0        0 eth0
192.168.6.0     *               255.255.255.0   U     0      0        0 eth2
192.168.5.0     192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.5.0     192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.4.0     192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.4.0     192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.3.0     192.168.250.2   255.255.255.0   UG    10     0        0 eth0
192.168.3.0     192.168.249.1   255.255.255.0   UG    20     0        0 eth1
192.168.2.0     192.168.249.1   255.255.255.0   UG    10     0        0 eth1
192.168.2.0     192.168.250.2   255.255.255.0   UG    20     0        0 eth0
192.168.1.0     192.168.249.1   255.255.255.0   UG    10     0        0 eth1
192.168.1.0     192.168.250.2   255.255.255.0   UG    20     0        0 eth0
192.168.249.0   *               255.255.255.0   U     0      0        0 eth1
192.168.250.0   *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 eth3

Можно ласты склеить. "Нифига себе".

Или командой ip route show

linux-router:/home/stasikos# ip ro sh
192.168.6.0/24 dev eth2  proto kernel  scope link  src 192.168.6.1
192.168.5.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.5.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.4.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.4.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.3.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.3.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.2.0/24 via 192.168.249.1 dev eth1  metric 10
192.168.2.0/24 via 192.168.250.2 dev eth0  metric 20
192.168.1.0/24 via 192.168.249.1 dev eth1  metric 10
192.168.1.0/24 via 192.168.250.2 dev eth0  metric 20
192.168.249.0/24 dev eth1  proto kernel  scope link  src 192.168.249.2
192.168.250.0/24 dev eth0  proto kernel  scope link  src 192.168.250.1
192.168.251.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.251.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.252.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.252.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.253.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.253.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.254.0/24 via 192.168.250.2 dev eth0  metric 10
192.168.254.0/24 via 192.168.249.1 dev eth1  metric 20
192.168.255.0/24 via 192.168.249.1 dev eth1  metric 10
192.168.255.0/24 via 192.168.250.2 dev eth0  metric 20
10.0.0.0/8 dev eth3  proto kernel  scope link  src 10.0.0.3

Чтобы не забивать этой ерундой мозг каждый раз, когда включается маршрутизатор, запишем все команды в шелл-скрипт и положим его в /etc/network/if-up.d.
Честно говоря, он будет не очень простым, так как надо все-таки разбираться, поднятие какого интерфейса вызывает наш скрипт. Для этого ifupdown передает скрипту переменную $IFACE.

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

# ip ro sh dev eth0 | grep -v link | sed -e 's/^/ $ADDCMD /'
# ip ro sh dev eth1 | grep -v link | sed -e 's/^/ $ADDCMD /'

поэтому в результате у нас получится примерно такой скрипт:

#!/bin/sh

ADDCMD='/sbin/ip route add '
case "$IFACE" in
        eth0)
                # команды для маршрутов через eth0
                 $ADDCMD 192.168.5.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.4.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.3.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.2.0/24 via 192.168.250.2  metric 20
                 $ADDCMD 192.168.1.0/24 via 192.168.250.2  metric 20
                 $ADDCMD 192.168.251.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.252.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.253.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.254.0/24 via 192.168.250.2  metric 10
                 $ADDCMD 192.168.255.0/24 via 192.168.250.2  metric 20
        ;;
        eth1)
                # команды для маршрутов через eth1
                 $ADDCMD 192.168.5.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.4.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.3.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.2.0/24 via 192.168.249.1  metric 10
                 $ADDCMD 192.168.1.0/24 via 192.168.249.1  metric 10
                 $ADDCMD 192.168.251.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.252.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.253.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.254.0/24 via 192.168.249.1  metric 20
                 $ADDCMD 192.168.255.0/24 via 192.168.249.1  metric 10
        ;;
        *)
                # для всех остальных случаев ничего не делаем
                exit 0
        ;;
esac

Я сохранил его в /etc/network/if-up.d/routing и установил на нем бит "исполняемый".

После этого несмотря на перезагрузку, таблица маршрутизатора останется такой же как и была. Т.е. можно считать что таблица на нем настроена.
Остается только включить пересылку пакетов между интерфейсами. Это делается в /etc/sysctl.conf. Туда нужно дописать строку (или раскомментировать, если она там уже есть):

net.ipv4.all.forwarding=1

далее выполняем

linux-router:/# sysctl -p
net.ipv4.conf.all.forwarding = 1

Команда применяет изменения в /etc/sysctl.conf и показывает их на экран.
Вот и все готово. Неверующие набирают еще "reboot" и проверяют, все ли осталось на своих местах. Можно переходить к настройке соседней циски.