Обычно VRF (Virtual Routing and Forwarding, VPN Routing and Forwarding) используется совместно с MPLS, но без него в терминологии Cisco он называется VRF-Lite. Суть этой технологии заключается в том, что маршрутная информация, принадлежащая разным классам (например, маршруты одного клиента), изолируется друг от друга.
Считается, что такими возможностями обладают только «взрослые» аппаратные решения, но это не совсем так.
Благодаря наличию нескольких таблиц маршрутизации и гибкой политике маршрутизации все это можно сделать в Linux. Кому интересно, добро пожаловать под кат.
Типы маршрутов, таблицы маршрутизации и PBR в Linux
Прежде чем мы перейдем к сути происходящего, давайте взглянем на некоторые отличительные особенности сетевого стека Linux. Первый отличительный момент – это особые типы маршрутов.Когда с какого-то интерфейса приходит IP-пакет, необходимо определить, адресован ли он этому хосту или другому.
Определяется это довольно элегантно — просто ищется в таблицах маршрутизации нужный маршрут по адресу назначения.
Если пакет попадает на маршрут типа «локальный», то он адресуется непосредственно хосту; если нет, то его надо проложить дальше (а дальнейший маршрут уже известен) или что-то еще сделать, в зависимости от типа маршрутов.
На данный момент поддерживается несколько типов маршрутов (подробнее о них можно прочитать в мане ip-route; если там написано, что такой маны нет, то обновите пакет iproute до более свежего).
В настоящее время нас интересуют только следующие типы маршрутов:
- unicast - обычный маршрут. Ничего интересного.
- local — адрес назначения находится на этом хосте.
Как только будет определено, что пакет находится на этом маршруте, он будет искать для него подходящий сокет.
- Broadcast — маршрут трансляции.
Входящие пакеты, поступающие по этому маршруту, практически ничем не отличаются от локального маршрута, за исключением дополнительных проверок на игнорирование широковещательных пакетов.
Для исходящих есть небольшая разница: широковещательный адрес назначения также задается в заголовке канального уровня при использовании широковещательных сетей.
- недоступен - запрещающий маршрут. Для пакетов, попадающих на этот маршрут, отправителю будет отправлен icmp-пакет с сообщением о недостижимости.
- запретить — аналогично типу «недоступен», только будет отправлено другое сообщение.
- blackhole — пакет на этом маршруте будет тихо отброшен
Еще одна вещь, которую следует учитывать, это то, что нам также нужны сетевые маршруты с прямым подключением, чтобы обеспечить соединение с соседними маршрутизаторами.
Маршруты сгруппированы в таблицы маршрутизации.
По умолчанию система изначально содержит три таблицы:
- local (255) — эта таблица содержит локальные и широковещательные маршруты.
Эта таблица автоматически поддерживается и генерируется на основе адресов, назначенных интерфейсам.
- main (254) — основная таблица маршрутизации.
В него автоматически добавляются маршруты с прямым подключением.
Также, если в параметрах ip-утилиты не указана таблица маршрутизации, то предполагается основная таблица.
- default (253) — таблица маршрутов по умолчанию.
Его использование не прижилось и поэтому оно, как правило, все время пустует.
Эта технология называется Policy Based Routing — маршрутизация на основе политик.
Суть его в том, что на основе некоторых критериев сетевого пакета мы либо выбираем таблицу, в которой будем искать маршрут, либо определяем действие, которое необходимо выполнить над пакетом.
У каждой политики есть номер (он может быть даже не уникальный), который также определяет приоритет. Политики рассматриваются в порядке возрастания приоритета.
Новые политики добавляются раньше существующих.
В настоящее время «критериями» политики являются
- адреса источника и/или назначения
- значение поля tos
- интерфейс, с которого был получен пакет
- интерфейс, к которому привязан сокет
- метка брандмауэра
- unicast — используется по умолчанию, при этом будет осуществляться поиск маршрута в указанной таблице маршрутизации.
- blackhole/prohibit/unreachable — действия аналогичны соответствующим типам маршрутов.
- nat — трансляция адресов без сохранения состояния, практически не используется.
Закрепление маршрутов в таблице
Теперь небольшой практический пример после скучного вступления.Для начала реализуем схему vrf-lite вручную, а затем усложним пример динамической маршрутизацией.
Допустим, у нас есть такая диаграмма: 
Цель — изолировать трафик разных «цветов» друг от друга.
При этом адресные пространства цветов могут пересекаться, что делает задачу еще более интересной.
Сформулируем цель неформально: сделать так, чтобы пакеты каждого цвета не выходили за пределы своей таблицы маршрутизации и передавались только через интерфейсы своего цвета.
Для этого мы создадим для каждого цвета свою таблицу маршрутизации и для удобства дадим им имя.
Затем добавьте в таблицы прямой связи маршруты интерфейсов, принадлежащих цвету.
И, наконец, добавим политики маршрутизации, чтобы пакеты использовали только собственную таблицу.
Сначала мы назначаем адреса интерфейсам.
В этом случае подключенные маршруты будут идти в основную таблицу, а локальные и широковещательные маршруты — в локальную таблицу.
Для удобства добавим названия таблиц маршрутизации.ip address add 192.168.0.1/24 dev eth0 ip address add 192.168.1.1/24 dev eth1 ip address add 192.168.2.1/24 dev eth2 ip address add 192.168.3.1/24 dev eth3
echo "10 RED" >> /etc/iproute2/rt_tables
echo "20 GREEN" >> /etc/iproute2/rt_tables
Добавляем прямые маршруты в соответствующие таблицы.
Нам это нужно для того, чтобы нам были доступны соседние роутеры.
ip route add 192.168.0.0/24 dev eth0 proto static scope link table RED
ip route add 192.168.1.0/24 dev eth1 proto static scope link table GREEN
ip route add 192.168.2.0/24 dev eth2 proto static scope link table GREEN
ip route add 192.168.3.0/24 dev eth3 proto static scope link table RED
Добавление других маршрутов.
ip route add 10.0.0.0/24 via 192.168.2.10 dev eth2 proto static table GREEN
Добавление политик.
ip rule add iif eth0 pref 10 lookup RED
ip rule add iif eth3 pref 10 lookup RED
ip rule add iif eth1 pref 20 lookup GREEN
ip rule add iif eth2 pref 20 lookup GREEN
Есть один нюанс: что произойдет, если пакет того же цвета не найдет маршрут в своей таблице? Это значит, что поиск маршрута в других таблицах продолжится, что для нас не очень хорошо.
Чтобы «заблокировать» пакет в пределах его цвета, мы можем добавить маршрут по умолчанию (одноадресный или запретный) в каждую изолированную таблицу или добавить политику запрета после каждой политики поиска маршрута внутри цвета.
Сделаем первый вариант для одного цвета, а второй для другого.
ip route add unreachable default proto static table RED
ip rule add unreachable iif eth1 pref 21
ip rule add unreachable iif eth2 pref 21
Также желательно перенести все локальные и широковещательные маршруты из локальной таблицы в таблицы соответствующих цветов, чтобы невозможно было получить доступ к локальным интерфейсам роутера из «чужого» цвета.
Для этого лучше всего написать какой-нибудь скрипт, чтобы не было так утомительно.
В результате наши таблицы маршрутизации и политики будут выглядеть примерно так: ip route list table RED
unreachable default proto static
broadcast 192.168.0.0 dev eth0 proto static scope link
192.168.0.0/24 dev eth0 proto static scope link
local 192.168.0.1 dev eth0 proto static scope host src 192.168.0.1
broadcast 192.168.0.255 dev eth0 proto static scope link
broadcast 192.168.3.0 dev eth3 proto static scope link
192.168.3.0/24 dev eth3 proto static scope link
local 192.168.3.1 dev eth3 proto static scope host src 192.168.3.1
broadcast 192.168.3.255 dev eth3 proto static scope link
ip route list table GREEN
10.0.0.0/8 via 192.168.2.10 dev eth2 proto static
broadcast 192.168.1.0 dev eth1 proto static scope link
192.168.1.0/24 dev eth1 proto static scope link
local 192.168.1.1 dev eth1 proto static scope host src 192.168.1.1
broadcast 192.168.1.255 dev eth1 proto static scope link
broadcast 192.168.2.0 dev eth2 proto static scope link
192.168.2.0/24 dev eth2 proto static scope link
local 192.168.2.1 dev eth2 proto static scope host src 192.168.2.1
broadcast 192.168.2.255 dev eth2 proto static scope link
ip rule list
0: from all lookup local
10: from all iif eth0 lookup 10
10: from all iif eth3 lookup 10
20: from all iif eth1 lookup 20
20: from all iif eth2 lookup 20
21: from all iif eth1 unreachable
21: from all iif eth2 unreachable
32766: from all lookup main
32767: from all lookup default
Стенд, собранный в GNS3, показал корректную работу схемы.
При обращении к чужому цвету отправитель получает сообщение о том, что пункт назначения недоступен, как и предполагалось.
На этом пока все, продолжение следует. В ней я попробую рассказать о динамической маршрутизации применительно к vrf с использованием демона маршрутизации птиц, и об обмене маршрутами между таблицами (утечка vrf).
Теги: #linux #Сетевые технологии #Системное администрирование #сети #настройка Linux #iproute2 #VRF-lite
-
Прототипирование Asic На Fpga
19 Oct, 24 -
Macbook Pro С Retina: Первый Анализ
19 Oct, 24 -
Ctrl Или Альт
19 Oct, 24
