Linux две таблицы маршрутизации

Настройка сетевых маршрутов в Linux (CentOS)

В этой статье мы рассмотрим особенности настройки маршрутизации и управления маршрутами в Linux (просмотр таблицы маршрутизации, добавление/удаление статических маршрутов и т.д.) на примере CentOS с помощью утилиты ip. Статья применима и для любого другого дистрибутива Linux с утилитой ip (Red Hat, Fedora и т.д.).

Просмотр таблицы маршрутизации в Linux

Чтобы вывести текущую таблицу маршрутизации в Linux выполните команду:

• default via 192.168.1.1 dev enp0s3 – шлюз по умолчанию, в данном примере работающий через интерфейс enp0s3. Если для target адреса в таблице маршрутизации отсутствует маршрут, то такой пакет отправляется через данный шлюз (маршрут по умолчанию)
• 192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.201 — статический маршрут для сети 192.168.1.0/24 через адрес 192.168.1.201, который прописан на интерфейсе
• proto kernel – маршрут создан ядром ( proto static – маршрут добавлен администратором)
• metric – приоритет маршрута (чем меньше значение metric, тем выше приоритет). При наличии двух маршрутов с одинаковой метрикой (не стоит так делать!), ядро начинает выбирать маршруты случайным образом.

Чтобы узнать через какой интерфейс (шлюз) должен маршрутизироваться трафик к определенному IP адресу используется команда:

# ip route get 192.168.2.45

Как добавить или удалить статический маршрут?

Чтобы добавить новый маршрут к определенной IP подсети в таблицу маршрутизации Linux, нужно выполнить следующую команду:

# ip route add 192.168.0.0/24 via 192.168.1.1

Таким образом, мы добавим маршрут для IP сети 192.168.0.0/24 через шлюз 192.168.1.1.

Также можно добавить отдельный маршрут для одного IP адреса (хоста):

# ip route add 192.168.1.0 via 192.168.1.1

Можно сделать аналог null route маршрута в Cisco (ip route null0), пакеты в такую сеть удаляются по причине No route to host:

# ip route add blackhole 10.1.20.0/24

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

Чтобы удалить созданный вручную маршрут, выполните:

# ip route del 192.168.0.0/24

Как видите, маршрут удален из таблицы маршрутизации.

Чтобы добавить постоянный маршрут, нужно создать файл для этого маршрута, либо добавить правило в файл rc.local (выполняется при загрузке сервера).

Чтобы добавить постоянный (статический) маршрут, нужно знать имя сетевого интерфейса, который будет использоваться для маршрутизации. Узнать имя сетевого интерфейса можно командой:

В моем случае, интерфейс enp0s3.

Далее открываем следующий файл:

И добавляем туда строку с маршрутом:

После добавления маршрута в файл нужно перезапустить сервис network:

# service network restart

После перещаауска сетевого сервиса, в таблице маршрутизации появился статический маршрут.

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

И укажите команду добавления маршрута:

# ip route add 192.168.0.0/24 via 192.168.1.1

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

Изменить маршрут в Linux

Чтобы изменить уже существующий маршрут, можно использовать команду ip route replace:

# ip route replace 192.168.0.0/24 via 192.168.1.1

Чтобы сбросить все временные маршруты в таблице маршрутизации, просто перезапустите сетевой сервис:

]# service network restart

Изменить маршрут по умолчанию

Вы можете удалить маршрут по-умолчаню с помощью команды ip route del:

# ip route del default via 192.168.1.1 dev enp0s3

Чтобы указать новый маршрут по-умолчанию в CentOS используется команда:

# ip route add default via 192.168.1.2 (маршрут через IP адрес шлюза)

# ip route add default via enp0s3 (маршрут через имя устройства)

Чтобы изменить параметры маршрута по умолчанию, используется команда:

Источник

Маршрутизация на основе политик. Часть четвертая

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

Настройка сети

На компьютере gateway установлена ОС Ubuntu Server, настройка сети выполнена с использованием Netplan:

После загрузки системы смотрим маршруты таблицы main :

Здесь два маршрута по умолчанию, но с разными значениями метрики — один маршрут основной (метрика 100), другой резервный (метрика 200).

Таблицы маршрутизации

И есть два правила, которые предписывают просматривать таблицы primary и secondary , если пакеты отправляются с ip-адресов 192.168.50.2 и 192.168.150.2 соответственно.

Таблицы маршрутизации primary и secondary определены в файле /etc/iproute2/rt_tables :

Каждая из таблиц маршрутизации содержит маршрут по умолчанию:

Переключение каналов

За переключение каналов отвечает скрипт /root/swicth-channel/swicth-channel.sh :

Этот скрипт будем запускать каждую минуту:

Форвардинг пакетов

По умолчанию транзитный трафик отключен, так что редактируем файл /etc/sysctl.conf :

После этого настраиваем netfilter с помощью утилиты iptables :

И смотрим, что получилось:

Мы разрешили ходить транзитным пакетам для нашего диапазона ip адресов, а всё остальное запретили.

Сохранение правил

Созданные с помощью утилиты iptables правила пропадут при перезагрузке. Так что их нужно сохранить и восстанавливать при перезагрузке. В этом нам поможет пакет iptables-persistent :

При установке пакета будет предложено сохранить текущие правила iptables :

• в файл /etc/iptables/rules.v4 для протокола IPv4
• в файл /etc/iptables/rules.v6 для протокола IPv6

После установки пакета будет добавлена новая служба netfilter-persistent.service , которая при загрузке системы будет восстанавливать созданные нами правила:

Поднимаем web-сервер

Установим на машине web-server пакет apache2 :

С компьютера pc-1 проверим, что сервер работает:

Чтобы обеспечить доступ к web-серверу из интернета, выполняем на gateway1 команду (подробности здесь):

И сохраняем правила, чтобы они восстановилось после перезагрузки:

Проверяем, что web-сервер теперь доступен, набирая в адресной строке http://111.111.111.111/ :

Настройка pc-1 и pc-2

Настройка сети одинаковая для pc-1 и pc-2 , выполнена с использованием Netplan, им назначены ip-адреса 192.168.250.2 и 192.168.250.3 :

Служба NetworkManager отключена, вместо нее за сеть отвечает служба systemd-networkd :

Еще одна таблица маршрутизации

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

Теперь добавляем новое правило — какие таблицы просматривать при отправке пакета:

Смотрим список правил — какие таблицы будут просмотрены при отправке пакета:

Для таблицы pc2-via-gw2 зададим маршрут по умолчанию:

Убедимся, что маршрут по умолчанию для pc2-via-gw2 добавлен:

Проверка маршрута для pc-2

Проверим, что компьютер pc-2 выходит в интернет через резервный канал связи:

Удостоверимся, что компьютер pc-1 выходит в интернет через основной канал связи:

Файл конфигурации сети

Созданные нами правило и маршрут по умолчанию для таблицы pc2-via-gw2 пропадут при перезагрузке gateway , поэтому надо изменить файл конфигурации сети:

Источник

Маршрутизация в Linux: VRF Lite

Типы маршрутов, таблицы маршрутизации и PBR в Linux

Прежде чем понять суть происходящего, познакомимся с некоторыми отличительными чертами сетевого стека Linux.

Первый отличительный момент — это специальные типы маршрутов. Когда ip-пакет приходит с какого-нибудь интерфейса, надо определить, адресован ли он этому хосту, или другому. Определяется это довольно элегантно — просто для адреса назначения ищется нужный маршрут в таблицах маршрутизации. Если пакет попадает на маршрут типа «local», значит он адресован непосредственно хосту, если нет, то значит его надо маршрутизировать дальше (при этом дальнейший маршрут уже известен) или сделать что-то ещё, в зависимости от типа маршрутов.

На данный момент поддерживается несколько типов маршрутов (подробнее о них можно посмотреть в мане ip-route, если пишет, что такого мана нет, то обновите пакет iproute на более свежий). Нас в данный момент интересуют только маршруты следующих типов:

• unicast — обычный маршрут. Ничего интересного.
• local — адрес назначения находится на данном хосте. После того, как выяснится, что пакет попадает на этот маршрут, будет производиться поиск подходящего сокета для него.
• broadcast — широковещательный маршрут. Для входящих пакетов, попадающих на этот маршрут, практически нет отличий от маршрута local, за исключением дополнительных проверок на игнорирование широковещательных пакетов. Для исходящих же есть небольшое отличие: в заголовке канального уровня так же выставляется широковещательный адрес назначения при использовании широковещательных сетей.
• unreachable — запрещающий маршрут. Для пакетов, попадающий на этот маршрут будет отослан отправителю icmp-пакет с сообщением о недоступности.
• prohibit — подобен типу unreachable, только сообщение другое будет отправлено.
• blackhole — пакет на этом маршруте будет молча отброшен

Таким образом, для маршрутизации транзитных пакетов нам достаточно наличия маршрута типа unicast, а для того, чтобы хост мог отвечать на пакеты, нужны ещё маршруты типов local и, опционально, broadcast. Ещё следует учесть то, что нам также нужны маршруты direct-connected сетей для того, чтобы обеспечить связность с соседними маршрутизаторами.

Маршруты сгруппированы в таблицы маршрутизации. По-умолчанию изначально в системе присутствуют три таблицы:

• local (255) — в этой таблице находятся локальные и широковещательные маршруты. Эта таблица обслуживается автоматически и генерируется на основе адресов, назначенных интерфейсам.
• main (254) — основная таблица маршрутизации. Автоматически в неё добавляются direct-connected маршруты. Так же если в параметрах утилиты ip не указана таблица маршрутизации, то подразумевается таблица main.
• default (253) — таблица для маршрутов по-умолчанию. Её использование не прижилось и поэтому она, как правило, пустует всё время.

Имена таблиц хранятся в файле /etc/iproute2/rt_tables. Под номер таблицы отдано 32 бита, но максимальное количество таблиц в данный момент жёстко ограничено числом 256. Как добавлять/удалять/редактировать маршруты можно почитать в мане к ip-route.

Таблица, в которой надо искать маршруты, определяется политиками маршрутизации. Эта технология называется Policy Based Routing — маршрутизация на основе политик. Суть её в том, что основываясь на каких-либо критериях сетевого пакета мы либо выбираем таблицу, в которой надо искать маршрут, либо определяем действие, которое надо выполнить над пакетом. Каждая политика имеет номер (он может быть даже не уникальным), он же определяем приоритет. Просмотр политик осуществляется в порядке возрастания их приоритетов. Новые политики добавляются перед существующими.

На данный момент «критериями» политики являются

• адреса источника и/или назначения
• значение поля tos
• интерфейс, с которого получен пакет
• интерфейс, к которому привязан сокет
• метка файерволла

Каждая политика имеет тип, который определяет действие над пакетом, если он под неё попадает:

• unicast — используется по-умолчанию, при этом будет производиться поиск маршрута в заданной таблице маршрутизации.
• blackhole/prohibit/unreachable — по действиям аналогичны соответствующим типам маршрутов.
• nat — трансляция адресов без учёта состояний, практически не используется.

Запираем маршруты в таблицу

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

Допустим, у нас есть вот такая схема:

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

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

Сначала назначаем интерфейсам адреса. При этом подключенные маршруты будут попадать в таблицу main, а локальные и широковещательные — в таблицу local.

Добавляем для удобства имена таблиц маршрутизации.

Добавляем прямые маршруты в соответствующие таблицы. Нужны это для того, чтобы нам были доступны соседние маршрутизаторы.

Добавляем остальные маршруты.

Есть один нюанс: что будет, если пакет одного цвета не находит маршрута в своей таблице? Значит, будет продолжен поиск маршрута в других таблицах, что для нас не очень хорошо. Чтобы «запереть» пакет в пределах своего цвета, мы можем в каждую изолированную таблицу добавить маршрут по-умолчанию (либо юникастовый, либо запрещающий), либо после каждой политики поиска маршрута в пределах цвета добавить запрещающую политику. Сделаем для одного цвета первый вариант, а для другого — второй.

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

В итоге, наши таблицы маршрутизации и политики будут выглядеть примерно так:

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

На этом пока всё, но продолжение следует. В нём постараюсь рассказать про динамическую маршрутизацию применительно к vrf с помощью демона маршрутизации bird, и обмен маршрутами между таблицами (vrf leaking).

Источник