Связность сети и целевая маршрутизация
Задачи (повторение):
- Глобальная идентификация (адресация)
- Структура адреса
Механизм раздачи
- Алгоритм доставки (маршрутизация)
- Известный маршрут и маршрут по умолчанию внутри крупной сети
- Связность крупных сетей (карта достижимости / стоимость)
Автоматическая настройка «выхода в интернет» (быстрый старт)
dhcpcd eth0 — автоматическая настройка IP, маршрута по умолчанию и DNS по протоколу DHCP
sysctl net.ipv4.ip_forward=1 — включение маршрутизации пакетов
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE — трансляция сетевых адресов всех выходящих пакетов в адрес интерфейса eth0
Можно посмотреть /etc/resolv.conf и ip route show (оно же ip r).
Динамическое распространение таблиц маршрутизации
- Большая сеть в едином администрировании
- Непростая и/или динамическая топология
- …
⇒ Сложно каждый раз руками делать ip route add
- отслеживание общего статуса всей сети
- расчёт кратчайшего взвешенного пути по Дейкстре
- удаление петель
- …
Настройка OSPF в BIRD
Площадка:
base (маршрутизатор)
eth0 — выход в интернет (см. выше)
eth1 — в сети intnet
bird.conf:
router id 10.1.1.2; protocol kernel { learn; # Learn all alien routes from the kernel scan time 20; # Scan kernel routing table every 20 seconds export all; # Default is export none } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol ospf SIMPLE { export all; area 0.0.0.0 { interface "eth1" { }; }; }
router (маршрутизатор)
eth1 — в сети intnet
eth2 — в сети deepnet
bird.conf:
router id 10.1.1.1; protocol kernel { scan time 20; export all; } protocol device { scan time 10; } protocol ospf SIMPLE { export all; area 0.0.0.0 { interface "eth1" { }; interface "eth2" { }; }; }
client
eth1 — в сети deepnet
bird.conf:
router id 10.2.2.2; protocol kernel { scan time 20; export all; } protocol device { scan time 10; } protocol ospf SIMPLE { area 0.0.0.0 { interface "eth1" { }; }; }
Настроить, запустить, посмотреть как приезжают маршруты!
Обеспечение глобальной связности
Проблема глобальной связности: табличная эскалация и дескалация, а что между?
- Весь интернет в full view не запихаешь
⇒ укрупнение до «системы под единым администрированием» (внутри таких систем OSPF и ему подобные решают проблемы) — т. н. автономных систем
Выдаются IANA / локальными регистраторами
Сложный протокол BGP
- Анонс собственной доступности
- Вычисление доступности и стоимости других AS
- Вот из AS-ок можно соорудить Full View, но
940 000+ маршрутов
- Имеет смысл только если у вас несколько AS в доступе
и вы хотите пропускать транзитный трафик либо выгадывать на стоимости перенаправления трафиков
Так делать большинство крупных операторов
- Иначе — т. н. «Last resort» (он же default route)
Т. е. очередная дихотомия: задачу связности решать надо, анонсировать доступность надо, но вычислять топологию нужно только если от этого есть польза.
(ещё раз упомяну Сети для самых маленьких с замечанием, что по этой теме они точно не про Linux)
Целевая маршрутизация
Destination-based принцип табличной маршрутизации: «сеть получателя ⇒ маршрут».
Задача source-based маршрутизации: «свойства пакета отправителя ⇒ маршрут».
Linux: просто заведём несколько таблиц маршрутизации (разных), и будем обрабатывать пакет по правилам одной из них сообразно его свойствам:
- Адрес отправителя
- Порт получателя (или отправителя)
- Интерфейс, протокол и т. п. …
Команда ip rule (немного документации)
Заготовка:
Два компьютера с выходом в интернет у каждого
- Маршрутизатор, подключённый к этим двум машинам по отдельным интерфейсам и третьей сетью для внутренних клиентов
Пример 1: подключаем два клиента ко внутренней сети, настраиваем source routing: с одного адреса пакеты в одну сторону, с другого — в другую
# ip route add default второй_сервер table какой-то-номер # ip rule add from «IP_B» table какой-то-номер
Пример 2: подключаем один клиент, перекидываем трафик по 80/443 портам в другую сторону
# ip route add default второй_сервер table какой-то-номер # ip rule add dport 80 table какой-то-номер
Получаем такую настройку:
1 [root@router ~]# ip rule list
2 0: from all lookup local
3 32765: from all dport 80 lookup какой-то-номер
4 32766: from all lookup main
5 32767: from all lookup default
6 [root@router ~]# ip route list
7 default via Сервер1 dev eth1
8 …
9 [root@router ~]# ip route list table какой-то-номер
10 default via Сервер2 dev eth2
11
Правила в ip rule
- Просматриваются в порядке увеличения номера (приоритет 0 — наивысший)
Правило lookup приводит к поиску в соответствующей таблице
- Если этот поиск удачен, происходит маршрутизация
Например, правило с наивысшим приоритетом «0: from all lookup local» приводит к поиску в таблице local (посмотрите на неё), отражающей подключённые локальные сети. Если адрес не из локальной сети, lookup local ничего не находит,
Если правило lookup не нашло маршрута, поиск продолжается дальше
Приоритет правила можно задавать вручную, добавив в конце priority номер
Основная таблица — main, именно её показывает ip route (т. е. ip route list table main)
Разумеется, в обоих примерах на серверах надо дополнительно настраивать маршрут в клиентскую сеть через центральный маршрутизатор.
Кстати! BIRD умеет записывать результаты не в основную, а в целевую таблицу маршрутизации (параметр kernel table №; в секции protocol kernel).
Д/З
Новое в образе: обновление системы и bird.
Задание 5
- Суть: объединить policy routing и OSPF в следующей топологии
Верхний сервер srv: «выход в интернет» + доступность машины client
Нижний сервер web: «выход в интернет» + доступность машины client
Маршрутизатор router:
TCP-соединения на 80-й и 443-й порты идут через web; весь остальной трафик (например, ping или traceroute) — через srv
Клиент client — «просто работает»
Дополнительное условие: никаких заранее заданных статических маршрутов (в т. ч. по умолчанию) в основной таблице маршрутизации, используйте OSPF (в srv и web они приедут по DHCP).
Допустимо использовать статические маршруты в целевых таблицах маршрутизации (в идеале они тоже должны заполняться OSPF, но я сам пока не пробовал)
Подсказка. Есть три варианта настройки web;
- Я делал так:
на srv вписал в 0.0.0.0 зону export all; (чтобы пропихивать маршрут по умолчанию), а на web — нет;
этот маршрут приехал на web (а зря, у него свой) поэтому я в протокол kernel вписал priority 200 (записи в таблице ядра стали более приоритетны, чем в таблице OSPF; по умолчанию — наоборот).
Можно использовать на web в зоне 0.0.0.0 фильтр:
import filter { if (net = 10.3.3.0/24 ) then accept; reject; };
(не рекомендуется: это абъюз условия, хотя формально всё верно) Поскольку статические маршруты в целевых таблицах маршрутизации разрешены, можно на web вообще не запускать bird, а создать целевую таблицу маршрутизации на client и соответствующее правило.
- Я делал так:
ВНИМАНИЕ! Предварительная настройка в отчёт не входит! Отчёт делается по уже работоспособной сети.
Отчёт (конфигурацию bird надо показывать, даже если вы его на данном хосте не использовали):
report 5 srv и report 5 web (они, по идее, идентичны?):
ip addr
ip route
grep "^[^#]" /etc/bird.conf
birdc show route
ping -c3 <client>
<client> — это IP-адрес клиента
tcpdump -i eth0 -c 2 tcp
report 5 router
ip addr
ip route
ip rule
ip route list table <номер>
<номер> — это номер целевой таблицы маршрутизации для web
- Если в вашем решении используется несколько целевых таблиц, команда выполняется для каждой
grep "^[^#]" /etc/bird.conf
birdc show route
client
ip addr
ip route
grep "^[^#]" /etc/bird.conf
birdc show route
dig +tcp @1.1.1.1 ya.ru
echo -e "GET / HTTP/1.1\nHOST: ya.ru\n" | netcat 77.88.55.242 80
Четыре отчёта сназваниями report.05.router, report.05.srv, report.05.web, report.05.client переслать одним письмом в качестве приложений на uneexlectures@cs.msu.ru
В теме письма должно встречаться слово LinuxNetwork2023
TODO вставить это в основное задание Некоторые провайдеры, например, «Акадо», блокируют DNS-запросы на сторонние сервера. Если вам не повезло с таким провайдером, посмотрите в файл /etc/resolv.conf на машине srv после настройки по DHCP. Там будет IP-адрес «ближайшего» DNS-сервера, который надо использовать вместо 1.1.1.1