четверг, 28 февраля 2008 г.

Как включить и настроить 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 он почему-то не хочет делать ращепление горизонта, хотя в мануале написано - что он просто не умеет не делать этого.

суббота, 23 февраля 2008 г.

Настройка 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



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

пятница, 22 февраля 2008 г.

10 советов, на случай если вам в голову пришла идея пересобрать ядро linux

Я вообще никогда не рекомендовал собирать ядра самостоятельно, если это явно не требуется. Сам всегда пользуюсь дистрибутивным ядром и если когда его и собирал - так это ради накладывания патчей. Не понимаю, почему каждый новичок норовит сделать это, не зная совершенно, чем это грозит?
Поэтому у меня сложилось несколько мыслей относительно сборки ядра:
1. Если вы не знаете точно, зачем вы хотите собрать собственное ядро - не собирайте его.
2. Если ваше текущее ядро работает и поддерживает все необходимое оборудование и технологии, и не имеет критических уязвимостей - не собирайте свое ядро и не обновляйте старое.
3. Если вы не в состоянии решить проблемы с новой версией ядра (например, поправить часть исходного кода модуля от сторонних производителей для сборки на новом ядре) самостоятельно - не обновляйте ядро.
4. Если нужное ядро уже есть в виде пакета для вашего дистрибутива (особенно в репозитариях дистрибутива) - не собирайте свое ядро.
5. Если вы все-таки решились - прочитайте не только Kernel HOWTO, но руководство для сборки ядра именно для своего дистрибутива. Поищите в поисковике информацию о проблемах со сторонними модулями и программным обеспечением, которое использует свои собственные модули в ядре для работы.
6. Не трогайте конфиг ядра больше, чем нужно. Особенно, если не знаете, что делаете.
7. Если часть модулей для оборудования вы добавили как модули - не забудьте собрать и initrd для ядра перед тем, как делать reboot.
8. Не забудьте оставить и старое рабочее ядро в системе и в загрузчике, чтобы можно было откатиться, если что-то пойдет не так.
9. Если что-то не получилось - не паникуйте - поищите в google по полученному сообщению об ошибке - скорее всего ответ вы найдете сразу же (обычно обжигаются еще тысячи пользователей).
10. Простая пересборка ядра скорее всего не даст прироста производительности и не сильно освободит оперативную память. А установка недистрибутивных ядер вынудит вас собирать проприетарные драйверы самостоятельно и хранить все дерево исходных текстов ядра на винчестере. Подумайте об этом.

четверг, 21 февраля 2008 г.

Протокол динамической маршрутизации 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 - встроенная или нет - есть, что показывать в плане настроек.

вторник, 19 февраля 2008 г.

Лытдыбр натуральный

Так что если вы ходите сюда за записями с тегом "computer-academy-step", можете просто не читать то что под катом...

А началось все с фразы "если мы будем жить вместе"...

Я никогда не задумывался об этом. Но, может кому-то покажется бредом сумасшедшего, а мне так не кажется. Все это, имхо, грань между детством и чем-то более ответственным и осмысленным. Действительно, где-то там, за этой гранью - отношение к противоположному полу, как к сиськам, попе, поцелуйчикам, сексу, в конце концов. Но если только задуматься, насколько все на самом деле глубже, и что на самом деле значит это "быть вместе" - я сначала просто ужаснулся. Во-первых, это значит, что привычный уклад жизни может совершенно меняться, особенно для такого гика и одиночки как я - дома появится человек, который будет требовать к себе море внимания. О ней надо будет заботиться, ее нужно будет даже обеспечивать, кроме того - заботиться и о ее родителях тоже, не так ли? Нет, можно сразу отказаться от этих обязанностей, но это уже будет не "вместе", это будет только "вместе в постели". Да, придется терпеть выходки. Да, у нее будут ПМС и все последствия тоже будут отражаться на тебе - изволь заботиться о ней в эти дни. Да, еще тебе придется понимать, что с работы она может прийти усталой и грустной и дело не в тебе, и не стоит заострять на этом внимание, и скандалить по поводу того, что она сегодня не хочет тебя ублажать и вообще кажется неласковой. Угу, еще у нее есть свои тараканы и бзики - и либо ты к ним привыкнешь, либо перевоспитаешь ее, либо ты уйдешь. Или она уйдет. Да, от нее, конечно, тоже много зависит. Есть ли у нее терпение? А у тебя?
Решения принимать только для себя тоже уже не получится. Нет, может это я так демократичен сам по себе, но мне кажется, что учитывать и ее интересы придется тоже. Да, не стоит забывать и про финансовую сторону дела. Все кажется таким простым, но тоже придется делать выбор не в пользу себя. Забудь про новые гаджеты. )
А доверие?
Нет, только взвесив все "за" и "против", можно вообще думать о каком-то сверхромантичном "вместе до гроба". Все что лезет в голову до этого момента, не имеет даже права на жизнь, только самообман и бред - потому что на самом деле все намного серьезнее, если твоя цель - это не только секс и приятное времяпровождение. И выбор этот непростой.

воскресенье, 17 февраля 2008 г.

USBMount

Сегодня понял, что совершенно надоевшим для меня стал процесс "фтыкнул сменный носитель, так пропиши...". В общем, задался мыслью, как без навороченного DE в своем fluxbox получить автоматическое монтирование любых съемных накопителей, втыкаемых в USB.

На #linux@Rusnet посоветовали попробовать usbmount.

С дефолтными настройками она вряд-ли кому подойдет, поэтому приведу то, что нужно поменять для получения счастливой улыбки на лице.

И сразу же испорчу настроение испытывающим радость. )


В общем, после установки пакета, в /etc/usbmount/usbmount.conf нужно немного поменять строчки в вот такой вид:


# vfat по-дефолту отключен - читайте, почему, в комментах выше строки
FILESYSTEMS="ext2 ext3 vfat"
# async тоже по-дефолту отключен, причины там же
MOUNTOPTIONS="async,noexec,nodev,noatime"
# а вот эта строка просто жизненно нужна для вменяемого поведения с vfat.
FS_MOUNTOPTIONS="-fstype=vfat,uid=stasikos,gid=floppy"


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

Недостатки -

1. При юзании vfat нужно не забывать руками делать команду sync перед вытыканием флешки (или, как некоторые джедаи, совать sync в crontab). Потому что монтирование с записью в sync приводит к редкостным тормозам в записи на накопитель (я так понял, что проблема в vfat - плохо работает в таком режиме).

2. При юзании vfat вряд-ли удастся настроить приемлемую работу с несколькими пользователями за компьютером - в силу того что монтирует накопитель сам usbmount, делает он это с правами root, и не использует записи в fstab, так что установить uid для владельца флешки можно только один, через тот же usbmount.conf. При попытке вывернуться с помощью fmask/dmask вы будете получать "Can't change permissions: operation is not permitted" при записи каждого файла на флешку.

суббота, 16 февраля 2008 г.

Wireshark - анализатор пакетов.

Утилитка, может быть, "крекерская", но ее использование упрощает понимание процессов, которые происходят в сети и может быть полезно при изучении сетевых протоколов и даже при простом обыденном поиске проблем.

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


Скачать ее, под *nix или под Windows, можно с сайта wireshark.org. Раньше она называлась Ethereal. ) Кроме того, она включена в большинство крупных дистрибутивов Linux и *BSD.


Для начала работы с Wireshark требуется хотя-бы захватить какие-либо пакеты. Удобнее всего это делать через "Capture options", расположенное на главной панели и
нструментов или в меню Capture.

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



После этого wireshark начинает, как правило, что-то захватывать...



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

Кроме того, в wireshark есть несколько удобных и полезных функций. Например, Analyse -> Expert Info Composite покажет список основных событий, которые произошли во время захвата - открытие новых сессий, не совсем хорошее поведение протоколов (повторные квитанции в TCP, повторные передачи сегментов и т.д.).



Там же - Follow (TCP|UDP|SSL) Stream - позволяет собрать сессию передачи воедино и посмотреть ее содержимое в целом - вплоть до восстановления переданной в течение сессии HTML-страницы. )



Statistics->Summary позволяет просмотреть некоторую статистику в целом по сессии захвата - в том числе, среднее количество пакетов в секунду и объем передава
емых данных.



Statistic -> Protocol Hierarhy - статистику по используемым протоколам, в том числе - в процентном соотношении.



Statistics -> Conversations показывает информацию об участниках связи, кто кому сколько передавал пакетов, данных и в какую сторону. )



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



Ну и для совсем уж ленивых людей, wireshark может автоматически генерировать правила для блокировки или разрешения траффика, похожего на выбранный пакет. Analyse - Firewall ACL Rules. При этом можно выбрать тип файрвола (Cisco acl, Netfilter, windows firewall и т.д.)



Кроме захвата пакетов непосредственно Wireshark, можно использовать tcpdump с опцией -w:
tcpdump -i ppp0 -w file.pcap

И затем открывать полученный файл в Wireshark для просмотра.

В общем, утилита удобная и должна быть Must Have у любого администратора. ) Единственное, чего в ней может не хватать - это генератора пакетов, но для этого есть другие, более подходящие средства.

среда, 13 февраля 2008 г.

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

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


(RFC 791)

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








VersionIHLType Of ServiceTotal Lenght
IdentificationFlagsFragment Offset
Time To LiveProtocolHeader CheckSum
Source Address
Destination Address
OptionsPadding


Поле 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).
Определены следующие номера опций:








КлассНомерДлинаОписание
00-Конец списка опций.
01-Поле-заполнитель, используемое для дополнения поля опций до кратной 32 бит границы заголовка
03varВключение мягкой маршрутизации от источника. Позволяет задавать маршрут пакета при его отправке.
09varСтрогая маршрутизация от источника.
07varЗапись маршрута. Включает запись адресов исходящих интерфейсов маршрутизаторов внутрь поля опций при пересылке пакетов.
24varТайм-стамп опция. Включает запись временной метки на каждом маршрутизаторе, через который проходит пакет, при его пересылке.


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

понедельник, 11 февраля 2008 г.

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

Естественно, вручную поддерживать таблицы маршрутизации в актуальном состоянии в крупной и часто изменяющейся сети очень сложно. Для автоматизации этого процесса еще начиная с 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. Когда сеть небольшая и в ней очень редко происходят изменения топологии.

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

воскресенье, 10 февраля 2008 г.

Каким должен быть Linux, чтобы он был похож на Windows?

Исходя из общения с довольно-таки утомленным за свою жизнь человеком, который имел несчастье познакомиться с Debian (и установить его уже, кажется, на 4-х машинах самостоятельно), сделал вот такие вот выводы:
1. Ядро не должно меняться годами.
Why: они не понимают, что такое ядро. Они не знают, где его взять. В гугле они находят kernel.org и спрашивают, как собирать ядра...
Why-not: От версии ядра слишком сильно зависит поддержка железа компьютера.

2. Ядро должно понимать минимально 99% всех железок, необходимых для установки и загрузки системы.
Why: Это нужно для выполнения (1)
Why-not: Если бы это было реально сделать, это было бы сделано. Но железки придумывают быстрее дистрибутивов, факт.
3. Драйвера нужно качать и устанавливать в систему двойным кликом мышки. Никаких пакетных менеджеров!
Why: ну тут все просто - это старая привычка - драйвер нужно найти и установить руками.
4. Точно так же должны устанавливаться приложения.
Why: аналогично (3)
5. Формат пакетов должен быть един и напоминать msi. Никаких зависимостей!
Why: опять аналогично (3)
6. Для любого существующего принтера/плоттера/сканера должен быть драйвер. Желательно на диске к принтеру. Как у гнусмасов. Или в системе - как у ХП. Эпсоны сосут, но к ним есть СМПЧ, поэтому сосет Cups без ppd к последним моделям.
Why: Купили Epson Stylus Photo R290...
7. Должна быть гуевая понятная штука, максимально повторяющая "Диспетчер устройств" в винде. Я знаю, что она есть, ее тупо не находят.
Why: а хз. )
8. Менеджера пакетов в системе быть не должно. Точка. Пользователи Windows не понимают, что это и зачем, и даже не понимают, чем это лучше, чем без него.
Why: "Я ведь совершенно не понимаю, что значат эти двадцать тысяч наименований пакетов. Что ставить? Даже если я ищу, оно мне предлагает 5-10 штук на выбор. Раньше было просто - записал тот же фотошоп на болванку - и, вот он..."
9. Должна быть дока, где "написаны все эти интересные команды в консоли..."
Why: с первого тыка я такое не нашел. Ну хоть Debian FAQ есть. А вменяемой доки по консоли на русском, где разжевано про получение информации про железо хотя-бы - нет.
10. Да, система не должна спрашивать, какие компоненты устанавливать при установке системы. Как Ubuntu. Или Windows.
Why: ну это тоже не просто. Откуда пользователю знать, что из 20k+ пакетов ему реально надо, а что - не надо ставить?

В общем, в целом ситуация сложная. Тяжело ломать старые стереотипы. =)

суббота, 9 февраля 2008 г.

Статическая маршрутизация в 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-подобная контекстная справка (но кривая до безобразия) по клавише "?".

четверг, 7 февраля 2008 г.

Вменяемая конфигурация в vim

Устанавливая vim в BSD-системах можно заметить, что чаще всего он ведет себя "совместимо" с vi. Сначала я открыл для себя "set nocompatible", но сегодня ramok открыл для меня vimrc_example. Так что теперь, приходя в новую систему, я буду скорее всего делать так:
locate vimrc_example
cp $PATH_TO_EXAMPLE_VIMRC ~/.vimrc

Шпаргалка для тех, кто хочет подарить своей женщине белье...

Картинка, 850х566

via #linux@RusNet

среда, 6 февраля 2008 г.

Поднимаем маршрутизатор на 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", пропинговав все интерфейсы уже работающих маршрутизаторов, и можем считать свою работу законченной, если все работает.

понедельник, 4 февраля 2008 г.

Wildcard-маски в IOS

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

Вычисление шаблона для маски подсети в Cisco IOS

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

Шаблон = 255 - Подсеть

Шаблонная маска, соответствующая маске подсети 255.255.255.224 (30 узлов в подсети), равна 0.0.0.31 (255-224=31).

И вспомнил недавний разговор про эти "инверсные маски". Вот тут написано все, что нужно знать. Даже добавить нечего. )

Поднимаем маршрутизатор на 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...

воскресенье, 3 февраля 2008 г.

В продолжение темы предыдущего поста - статическая маршрутизация на 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 сейчас активно два, это довольно-таки наглядно показано.

суббота, 2 февраля 2008 г.

Дальше про статическую маршрутизацию (или настройка 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" и проверяют, все ли осталось на своих местах. Можно переходить к настройке соседней циски.