Динамическая маршрутизация по GRE over IPsec туннелям между Cisco и FreeBSD 8.1
Invite pending
Приветствую всех читателей Хабра!
Несколько месяцев назад компания, в которой я работаю начала снова расширяться, следствием чего было появление двух новых офисов. Руководством была поставлена задача обеспечить доступ новых сотрудников к серверам компании. Ниже представлено описание того, как я подошел к решению данной задачи, черпая информацию в Google, man-командах FreeBSD и встроенной помощи в Cisco IOS.
Смотрим, что из этого получилось.
Данные по подсетям:
Итак, между двумя филиалами уже есть прямой оптоволоконный канал, который находится в собственности организации. Таким образом, один канал уже присутствует и практически не нуждается в конфигурировании. Осталось организовать два туннеля: первого (А) с третьим (С) и второго (В) с третьим (С) филиалами — через общественные сети (Интернет). Для организации защиты данных туннелей предполагается использовать стандарт IPsec. Раз топология должна быть полносвязной, то встает вопрос правильной маршрутизации данных. Списки доступа для шифрования вместе со статическими маршрутами для этого плохо подходят. Поэтому было решено запустить внутри туннелей протокол динамической маршрутизации. В качестве последнего принято решение использовать OSPF, а для его запуска в туннелях — протокол GRE (Generic Routing Encapsulation). Таким образом, возникла задача построить два GRE-туннеля, защищенных протоколом IPsec.
В итоге получилась следующая схема:
Существовало еще одно замечание. Известно, что офисы В и С имеют гораздо более качественное соединение с внешним миром нежели офис А, поэтому эффективнее весь трафик во внешний мир и на офис С (Сisco 2811) пропускать через маршрутизатор на офисе В (Сisco 2821), а Интернет-соединение офиса А (FreeBSD-8.1) использовать как резервное, т.е. связь должна происходить по схеме, представленной ниже.
Оптика подключена. Для связи по оптике сделана подсеть с двумя адресами 192.168.21.0/30.
Cisco 2821 — 192.168.21.1/30
FreeBSD 8.1 — 192.168.21.2/30
В /etc/rc.conf вписывается:
Этими строками создается и настраивается интерфейс gre0, который и ответственнен за работу GRE туннеля. После добавления данных строк в файл, команда: ifconfig gre0 create — создаст интерфейс gre0 с нужными настройками. Подсеть 192.168.23.0/30, в пределах которой назначены адреса для интерфейса, является той виртуальной сетью, через которую будет проходить туннельный трафик, она же будет отображаться в таблице маршрутизации. Параметр link0 в команде говорит о том, что необходимо использовать инкапсуляцию GRE.
В /boot/loader.conf вписывается:
Эта настройка загружает драйвер gre при загрузке системы.
После этих настроек должны начать проходить пинги по туннелям.
Для включения поддержки IPsec во FreeBSD необходимо собрать ядро со следующими опциями:
Также необходимо установить порт ipsec-tools:
Для хранения конфигурационных файлов был создан каталог /usr/local/etc/racoon (racoon – утилита, управляющая IPsec соединениями). В этом каталоге создано три файла: ipsec.conf, key.txt (в примерах называется psk.txt) и racoon.conf (можно скопировать из /usr/local/share/examples/ipsec-tools). В файле ipsec.conf указывается политика IPsec (SPD – Security Policy Database), т.е. какой траффик подлежит шифрованию и передаче по туннелю; в файле racoon.conf — настройки удаленных клиентов и параметры для первой и второй фаз IPSec; в файле key.txt – разделяемый ключ (pre-shared key).
Содержание файлов.
ipsec.conf
Построчно:
racoon.conf
Здесь редактировались следующие опции/разделы:
key.txt
Содержит строку вида:
адрес_удаленного_сервера ключ
На данный файл устанавливается право на чтение только для root, остальные права запрещаются.
Для запуска при загрузке системы в /etc/rc.conf вписываются следующие строки:
После этого запустить соответствующие службы можно командами:
Действия аналогичны предыдущим. Только необходимо создать по два keyring, isakmp и ipsec профиля, одну политику isakmp и один ipsec transform-set.
Несколько команд show для демонстрации.
После успешного применения всех этих настроек, должна появится связь. Проверить можно естественно пропинговав адреса туннельных интерфейсов. А признаком защищенности канала будут установленные Security Association (SA), которые можно просмотреть:
Теперь необходимо обеспечить связь между подсетями офисов. Для этого настраиваем OSPF протокол для обмена маршрутами.
На FreeBSD для этого используется пакет quagga-0.99.17_3. Устанавливается из /usr/ports/net/quagga.
Для настройки необходимо изменение двух конфигурационных файлов: zebra.conf, ospfd.conf. Данные файлы были созданы в каталоге /usr/local/etc/quagga. Из настроек достаточно прописать в них параметры: hostname, password и enable password. Пример можно посмотреть в каталоге /usr/local/share/examples/quagga. Для запуска quagga при старте системы вписываем в /etc/rc.conf:
Стартуем quagga.
Настраиваем.
Соединяемся на демон quagga – ospfd. Процесс конфигурирования почти аналогичен Сisco'вскому:
Cisco 2821:
Cisco 2811:
После этого должно состояться согласование и построены таблицы маршрутизации. Вспомним об еще одной задаче. Как было оговорено ранее — ADSL канал является медленным и нестабильным. Лучше ходить через один маршрутизатор, чем отправлять пакеты напрямую по ADSL каналу. Для решения данной задачи необходимо подредактировать стоимости маршрутов OSPF. Подстраивать будем стоимости маршрутов во FreeBSD под Cisco. Тем более шлюз является виртуальной машиной под Vmware ESXi и когда настроили OSPF на шлюзе получилось явное несоответствие стоимостей на разных концах соединений. Маршрутизаторы Cisco установили cost на туннельных интерфейсах в 11111, гигабитные и стомегабитные интерфейсы в 1.
Соединяемся на ospfd демон.
Далее выполняются следующие команды (сетевые карты на шлюзе были определены как em0, т.к. использовалась виртуальная сетевая карта эмулирующая Intel E1000).
На последнем (туннельном gre) интерфейсе была установлена заведомо большая стоимость чем суммарная стоимость маршрута к сети офиса С через один маршрутизатор. Также была изменена стоимость туннельного соединения на маршрутизаторе Cisco 2811. Входим в режим конфигурирования интерфейса tunnel 1 и выполняем:
После этого картина распределния OSPF стоимостей интерфейсов примет следующий вид:
Таким образом, теперь маршрут к сети 192.168.18.0/24 будет лежать не через туннельный интерфейс напрямую на маршрутизатор Cisco 2811, а через маршрутизатор Cisco 2821 на офисе В, т.к. суммарная стоимость этого маршрута меньше стоимости маршрута, пролегающего через ADSL канал.
Еще одно замечание по настройке интерфейсов для ospf. Маршрутизаторы Сisco установили тип туннельных интерфейсов в point-to-point в то время как FreeBSD установила тип интерфейса gre0 в broadcast. По этой причине не происходило согласования между маршрутизаторами. Чтобы исправить ситуацию, необходимо изменить тип интерфейса gre0 на point-to-point.
Также стояла задача обеспечения прохождения траффика, идущего в Интернет от клиентов офиса А по аналогичному маршруту. Для решения этой задачи необходимо вспомнить о наличии у каждого протокола маршрутизации такой характеристики как административная дистанция. Для статических маршрутов она равна 1, для протокола OSPF – 110. Административная дистанция определяет какой из маршрутов, ведущих к одному назначению, будет инсталлирован в таблицу маршрутизации, если этот маршрут предоставлен разными протоколами маршрутизации. По правилам выбирается протокол, имеющий меньшую административную дистанцию. Таким образом, для того чтобы решить нашу задачу, необходимо:
На этом этапе появилась проблема, которая состояла в том, что провайдер при пересоединении ppp сессии любит менять шлюз по умолчанию. Как заставить quagga забирать выдаваемый шлюз при пересоединении решения не нашлось, а оставить эту задачу на попечение ppp демону нельзя, т.к. необходимо изменять административную дистанцию маршрута по умолчанию. Чтобы выйти из этой ситуации, в quagga было прописано много статических маршрутов по умолчанию (для настройки статических маршрутов необходимо соединиться на демон zebra командой – telnet localhost 2601) с нужной административной дистанцией, и шлюзами в том диапазоне, из которого их выдавал провайдер (на самом деле хоть было вбито около 10ти, адрес менялся в пределах 3х постоянных значений). Quagga в зависимости от активного адреса шлюза меняет маршрут по умолчанию и инсталлирует его в таблицу маршрутизации ядра.
Для настройки обмена маршрутами по умолчанию в настройках OSPF задается команда default-information originate. Например на Cisco:
Аналогичная команда задается в настройках OSPF в quagga. Затем в quagga прописываем статические маршруты по умолчанию с административной дистанцией большей чем 110, мы выбрали 120. Выглядело это следующим образом:
В конечном итоге, посмотрев на таблицу маршрутизации в quagga на FreeBSD, мы должны увидеть примерно следующее:
Как видим, маршрут по умолчанию и маршрут к сети офиса С (192.168.18.0/24) проходит через адрес 192.168.21.1, который является адресом маршрутизатора на офисе В (Cisco 2821).
Схема заработала.
На этом я хотел бы закончить пост. Пожелания, предложения, разумная критика, комментарии спецов в соответствующих областях будут только приветствоваться.
Несколько месяцев назад компания, в которой я работаю начала снова расширяться, следствием чего было появление двух новых офисов. Руководством была поставлена задача обеспечить доступ новых сотрудников к серверам компании. Ниже представлено описание того, как я подошел к решению данной задачи, черпая информацию в Google, man-командах FreeBSD и встроенной помощи в Cisco IOS.
Смотрим, что из этого получилось.
Исходные данные и постановка задачи
- Три офиса компании, между которыми необходимо настроить связь через общественные сети. Внутри туннелей запустить протокол динамической маршрутизации для обмена маршрутами к локальным сетям.
- Между двумя филиалами есть прямой оптоволоконный канал.
- Топология должна быть полносвязной, для наличия резервных маршрутов.
- Связь с внешним миром обеспечивают: маршрутизаторы Сisco 2821, Сisco 2811, и сервер на базе FreeBSD 8.1. Маршрутизаторы подключены к внешнему миру по Ethernet каналу, а FreeBSD 8.1 через ADSL. В маршрутизаторы вставлены модули Ethernet коммутации на 4ре порта, таким образом шлюзом по умолчанию для подсетей, за которые ответственны маршрутизаторы, является интерфейс Vlan1.
Данные по подсетям:
- офис A — подсеть 192.168.20.0/24, шлюз 192.168.20.254 (FreeBSD 8.1), внешний адрес A.A.A.A
- офис B — подсеть 192.168.19.0/24, шлюз 192.168.19.254 (Cisco 2821), внешний адрес B.B.B.B
- офис C — подсеть 192.168.18.0/24, шлюз 192.168.18.254 (Cisco 2811), внешний адрес C.C.C.C
Итак, между двумя филиалами уже есть прямой оптоволоконный канал, который находится в собственности организации. Таким образом, один канал уже присутствует и практически не нуждается в конфигурировании. Осталось организовать два туннеля: первого (А) с третьим (С) и второго (В) с третьим (С) филиалами — через общественные сети (Интернет). Для организации защиты данных туннелей предполагается использовать стандарт IPsec. Раз топология должна быть полносвязной, то встает вопрос правильной маршрутизации данных. Списки доступа для шифрования вместе со статическими маршрутами для этого плохо подходят. Поэтому было решено запустить внутри туннелей протокол динамической маршрутизации. В качестве последнего принято решение использовать OSPF, а для его запуска в туннелях — протокол GRE (Generic Routing Encapsulation). Таким образом, возникла задача построить два GRE-туннеля, защищенных протоколом IPsec.
В итоге получилась следующая схема:
Существовало еще одно замечание. Известно, что офисы В и С имеют гораздо более качественное соединение с внешним миром нежели офис А, поэтому эффективнее весь трафик во внешний мир и на офис С (Сisco 2811) пропускать через маршрутизатор на офисе В (Сisco 2821), а Интернет-соединение офиса А (FreeBSD-8.1) использовать как резервное, т.е. связь должна происходить по схеме, представленной ниже.
Непосредственно настройка
Оптика подключена. Для связи по оптике сделана подсеть с двумя адресами 192.168.21.0/30.
Cisco 2821 — 192.168.21.1/30
FreeBSD 8.1 — 192.168.21.2/30
Настройка GRE туннелей
Офис А — FreeBSD 8.1
В /etc/rc.conf вписывается:
cloned_interfaces="gre0" ifconfig_gre0="192.168.23.1 192.168.23.2 netmask 255.255.255.252 link0 tunnel A.A.A.A C.C.C.C"
Этими строками создается и настраивается интерфейс gre0, который и ответственнен за работу GRE туннеля. После добавления данных строк в файл, команда: ifconfig gre0 create — создаст интерфейс gre0 с нужными настройками. Подсеть 192.168.23.0/30, в пределах которой назначены адреса для интерфейса, является той виртуальной сетью, через которую будет проходить туннельный трафик, она же будет отображаться в таблице маршрутизации. Параметр link0 в команде говорит о том, что необходимо использовать инкапсуляцию GRE.
В /boot/loader.conf вписывается:
if_gre_load="YES"
Эта настройка загружает драйвер gre при загрузке системы.
Офис B — Cisco 2821
configure terminal #режим глобального конфигурирования interface tunnel0 #режим конфигурирования интерфейса ip address 192.168.22.1 255.255.255.252 #адрес внутри туннеля tunnel source gi0/0 #интерфейс источник tunnel destination C.C.C.C #IP назначения tunnel mode gre ip #режим работы туннеля
Офис C — Cisco 2811
configure terminal interface tunnel0 ip address 192.168.22.2 255.255.255.252 tunnel source fa0/0 tunnel destination B.B.B.B tunnel mode gre ip interface tun1 ip address 192.168.23.2 255.255.255.252 tunnel source fa0/0 tunnel destination A.A.A.A tunnel mode gre ip
После этих настроек должны начать проходить пинги по туннелям.
Настройка защиты туннелей с помощью IPsec
Офис А — FreeBSD 8.1
Для включения поддержки IPsec во FreeBSD необходимо собрать ядро со следующими опциями:
options IPSEC device crypto
Также необходимо установить порт ipsec-tools:
/usr/ports/security/ipsec-tools
Для хранения конфигурационных файлов был создан каталог /usr/local/etc/racoon (racoon – утилита, управляющая IPsec соединениями). В этом каталоге создано три файла: ipsec.conf, key.txt (в примерах называется psk.txt) и racoon.conf (можно скопировать из /usr/local/share/examples/ipsec-tools). В файле ipsec.conf указывается политика IPsec (SPD – Security Policy Database), т.е. какой траффик подлежит шифрованию и передаче по туннелю; в файле racoon.conf — настройки удаленных клиентов и параметры для первой и второй фаз IPSec; в файле key.txt – разделяемый ключ (pre-shared key).
Содержание файлов.
ipsec.conf
spdflush; spdadd A.A.A.A/32 C.C.C.C/32 gre -P out ipsec esp/tunnel/A.A.A.A-C.C.C.C/require; spdadd C.C.C.C/32 A.A.A.A/32 gre -P in ipsec esp/tunnel/C.C.C.C-A.A.A.A/require;
Построчно:
- очистка базы данных политик;
- добавление политики для исходящего GRE трафика с A.A.A.A на C.C.C.C. При обычной настройке IPSec между двумя точками сюда пишутся адреса частных подсетей, трафик между которыми должен быть передан по туннелю. В случае, рассматриваемом в статье, подобный траффик уже завернут в протокол GRE, поэтому подлежит шифрованию весь GRE траффик, идущий между внешними адресами. Здесь необходимо соблюдать осторожность. Если написать конструкцию вида: spdadd 0.0.0.0/0 0.0.0.0/0 gre … — (которая означает весь GRE траффик), то можно получить определенные проблемы. Например, если в сети найдется Windows PPTP клиент, использующий для работы GRE протокол, то работать он не будет, т.к. его пакеты будут добросовестно упаковываться шлюзом в наш IPsec туннель;
- добавление политики для входящего GRE трафика с C.C.C.C на A.A.A.A
racoon.conf
Здесь редактировались следующие опции/разделы:
path pre_shared_key "/usr/local/etc/racoon/key.txt"; #путь к файлу с разделяемыми ключами
#раздел:
remote C.C.C.C {
my_identifier address A.A.A.A;
peers_identifier address C.C.C.C;
lifetime time 86400 sec;
#при несовпадении значений соединение может не установиться, на Cisco текущее значение lifetime #можно посмотреть командой show crypto isakmp policy
proposal {
#в этом разделе параметры должны совпадать с таковыми на Cisco для isakmp политики, например #следующие
encryption_algorithm aes;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group 2;
}
}
#раздел:
sainfo anonymous
{
#следующие ниже опции должны совпадать в параметрами transform-set на Cisco
encryption_algorithm aes;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
# pfs_group 2; # как видно закомментировано
}key.txt
Содержит строку вида:
адрес_удаленного_сервера ключ
C.C.C.C password
На данный файл устанавливается право на чтение только для root, остальные права запрещаются.
Для запуска при загрузке системы в /etc/rc.conf вписываются следующие строки:
ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/ipsec.conf" racoon_enable="YES" racoon_flags="-f /usr/local/etc/racoon/racoon.conf"
После этого запустить соответствующие службы можно командами:
/etc/rc.d/ipsec start /usr/local/etc/rc.d/racoon start
Офис В — Cisco 2821
- Cоздается политика isakmp.
configure terminal crypto isakmp policy 10 # последняя цифра — ID encryption aes group 2 auth pre-share hash md5
- Cоздается keyring – связка хост-ключ, к которой можно обращаться по имени.
crypto keyring Ckey pre-shared-key address C.C.C.C key 6 password в дальнейшем можно обращаться к этой связке по имени Ckey
- Создается isakmp профиль.
crypto isakmp profile BCisakmp keyring Ckey # имя созданного keyring match identity address C.C.C.C 255.255.255.255
- Cоздается ipsec transform-set – параметры шифрования в туннеле.
crypto ipsec transform-set EXAMPLE esp-aes esp-md5-hmac
- Cоздается профиль ipsec
crypto ipsec profile BCipsec set isakmp BCisakmp set transform-set EXAMPLE
- Последнее — защищается GRE туннель
interface tunnel0 tun protection ipsec profile BCipsec
Офис С — Cisco 2811
Действия аналогичны предыдущим. Только необходимо создать по два keyring, isakmp и ipsec профиля, одну политику isakmp и один ipsec transform-set.
crypto isakmp policy 10 encryption aes group 2 auth pre-share hash md5
crypto keyring Bkey pre-shared-key address B.B.B.B key 6 password crypto keyring Akey pre-shared-key address A.A.A.A key 6 password
crypto isakmp profile CBisakmp keyring Bkey match identity address B.B.B.B 255.255.255.255 crypto isakmp profile CAisakmp keyring Akey match identity address A.A.A.A 255.255.255.255
crypto ipsec transform-set EXAMPLE esp-aes esp-md5-hmac
crypto ipsec profile CBipsec set isakmp CBisakmp set transform-set EXAMPLE crypto ipsec profile CAipsec set isakmp CAisakmp set transform-set EXAMPLE
interface tun0 tun protection ipsec profile CBipsec interface tun1 tun protection ipsec profile CAipsec
Несколько команд show для демонстрации.
После успешного применения всех этих настроек, должна появится связь. Проверить можно естественно пропинговав адреса туннельных интерфейсов. А признаком защищенности канала будут установленные Security Association (SA), которые можно просмотреть:
- на Cisco:
show crypto ipsec sa
- на FreeBSD:
setkey -D
Настройка динамической маршрутизации OSPF
Теперь необходимо обеспечить связь между подсетями офисов. Для этого настраиваем OSPF протокол для обмена маршрутами.
Настройка на FreeBSD 8.1
На FreeBSD для этого используется пакет quagga-0.99.17_3. Устанавливается из /usr/ports/net/quagga.
Для настройки необходимо изменение двух конфигурационных файлов: zebra.conf, ospfd.conf. Данные файлы были созданы в каталоге /usr/local/etc/quagga. Из настроек достаточно прописать в них параметры: hostname, password и enable password. Пример можно посмотреть в каталоге /usr/local/share/examples/quagga. Для запуска quagga при старте системы вписываем в /etc/rc.conf:
quagga_enable="YES" quagga_daemons="zebra ospfd"
Стартуем quagga.
/usr/local/etc/rc.d/quagga start
Настраиваем.
Соединяемся на демон quagga – ospfd. Процесс конфигурирования почти аналогичен Сisco'вскому:
telnet localhost 2604 enable conf t router ospf network 192.168.20.0/24 area 0 network 192.168.21.0/30 area 0 network 192.168.23.0/30 area 0 Ctrl+z write memory
Настройка на Сisco
Cisco 2821:
configure terminal router ospf 10 network 192.168.19.0 0.0.0.255 area 0 network 192.168.21.0 0.0.0.3 area 0 network 192.168.22.0 0.0.0.3 area 0
Cisco 2811:
configure terminal router ospf 10 network 192.168.18.0 0.0.0.255 area 0 network 192.168.22.0 0.0.0.3 area 0 network 192.168.23.0 0.0.0.3 area 0
После этого должно состояться согласование и построены таблицы маршрутизации. Вспомним об еще одной задаче. Как было оговорено ранее — ADSL канал является медленным и нестабильным. Лучше ходить через один маршрутизатор, чем отправлять пакеты напрямую по ADSL каналу. Для решения данной задачи необходимо подредактировать стоимости маршрутов OSPF. Подстраивать будем стоимости маршрутов во FreeBSD под Cisco. Тем более шлюз является виртуальной машиной под Vmware ESXi и когда настроили OSPF на шлюзе получилось явное несоответствие стоимостей на разных концах соединений. Маршрутизаторы Cisco установили cost на туннельных интерфейсах в 11111, гигабитные и стомегабитные интерфейсы в 1.
Соединяемся на ospfd демон.
telnet localhost 2604
Далее выполняются следующие команды (сетевые карты на шлюзе были определены как em0, т.к. использовалась виртуальная сетевая карта эмулирующая Intel E1000).
interface em0 ip ospf cost 1 interface em2 ip ospf cost 1 interface gre0 ip ospf cost 11115
На последнем (туннельном gre) интерфейсе была установлена заведомо большая стоимость чем суммарная стоимость маршрута к сети офиса С через один маршрутизатор. Также была изменена стоимость туннельного соединения на маршрутизаторе Cisco 2811. Входим в режим конфигурирования интерфейса tunnel 1 и выполняем:
ip ospf cost 11115
После этого картина распределния OSPF стоимостей интерфейсов примет следующий вид:
Таким образом, теперь маршрут к сети 192.168.18.0/24 будет лежать не через туннельный интерфейс напрямую на маршрутизатор Cisco 2811, а через маршрутизатор Cisco 2821 на офисе В, т.к. суммарная стоимость этого маршрута меньше стоимости маршрута, пролегающего через ADSL канал.
Еще одно замечание по настройке интерфейсов для ospf. Маршрутизаторы Сisco установили тип туннельных интерфейсов в point-to-point в то время как FreeBSD установила тип интерфейса gre0 в broadcast. По этой причине не происходило согласования между маршрутизаторами. Чтобы исправить ситуацию, необходимо изменить тип интерфейса gre0 на point-to-point.
telnet localhost 2604 enable conf t interface gre0 ip ospf network point-to-point
Также стояла задача обеспечения прохождения траффика, идущего в Интернет от клиентов офиса А по аналогичному маршруту. Для решения этой задачи необходимо вспомнить о наличии у каждого протокола маршрутизации такой характеристики как административная дистанция. Для статических маршрутов она равна 1, для протокола OSPF – 110. Административная дистанция определяет какой из маршрутов, ведущих к одному назначению, будет инсталлирован в таблицу маршрутизации, если этот маршрут предоставлен разными протоколами маршрутизации. По правилам выбирается протокол, имеющий меньшую административную дистанцию. Таким образом, для того чтобы решить нашу задачу, необходимо:
- Настроить OSPF на обмен маршрутами по умолчанию, между маршрутизаторами офисов А и В.
- Увеличить административную дистацию статического маршрута по умолчанию на FreeBSD так, чтобы она посчитала маршрут, пришедший от маршрутизатора Cisco 2821, лучше своего собственного.
На этом этапе появилась проблема, которая состояла в том, что провайдер при пересоединении ppp сессии любит менять шлюз по умолчанию. Как заставить quagga забирать выдаваемый шлюз при пересоединении решения не нашлось, а оставить эту задачу на попечение ppp демону нельзя, т.к. необходимо изменять административную дистанцию маршрута по умолчанию. Чтобы выйти из этой ситуации, в quagga было прописано много статических маршрутов по умолчанию (для настройки статических маршрутов необходимо соединиться на демон zebra командой – telnet localhost 2601) с нужной административной дистанцией, и шлюзами в том диапазоне, из которого их выдавал провайдер (на самом деле хоть было вбито около 10ти, адрес менялся в пределах 3х постоянных значений). Quagga в зависимости от активного адреса шлюза меняет маршрут по умолчанию и инсталлирует его в таблицу маршрутизации ядра.
Для настройки обмена маршрутами по умолчанию в настройках OSPF задается команда default-information originate. Например на Cisco:
configure terminal router ospf 10 default-information originate
Аналогичная команда задается в настройках OSPF в quagga. Затем в quagga прописываем статические маршруты по умолчанию с административной дистанцией большей чем 110, мы выбрали 120. Выглядело это следующим образом:
В конечном итоге, посмотрев на таблицу маршрутизации в quagga на FreeBSD, мы должны увидеть примерно следующее:
Как видим, маршрут по умолчанию и маршрут к сети офиса С (192.168.18.0/24) проходит через адрес 192.168.21.1, который является адресом маршрутизатора на офисе В (Cisco 2821).
Схема заработала.
На этом я хотел бы закончить пост. Пожелания, предложения, разумная критика, комментарии спецов в соответствующих областях будут только приветствоваться.