Различия между версиями 9 и 10
Версия 9 от 2023-03-27 02:13:03
Размер: 13850
Редактор: ArsenyMaslennikov
Комментарий: /etc/resolv/conf
Версия 10 от 2023-03-30 19:06:54
Размер: 15032
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 38: Строка 38:
router id 10.1.1.2;
Строка 59: Строка 60:
router id 10.1.1.1;
Строка 80: Строка 82:
router id 10.2.2.2;
Строка 181: Строка 184:
  * Дополнительное условие: никаких заранее заданных статических маршрутов (в т. ч. по умолчанию) ''в основной таблице маршрутизации'', используйте OSPF (в `srv` и `web` они приедут по DHCP)
   * Единственная загвоздка: как не принимать от `web` маршрут по умолчанию ''в основную таблицу маршрутизации'' на `router`
   * ''Допустимо'' использовать статические маршруты в целевых таблицах маршрутизации (в идеале они тоже должны заполняться OSPF, но я сам пока не пробовал)
  * Дополнительное условие: никаких заранее заданных статических маршрутов (в т. ч. по умолчанию) ''в основной таблице маршрутизации'', используйте OSPF (в `srv` и `web` они приедут по DHCP).
  * ''Допустимо'' использовать статические маршруты в целевых таблицах маршрутизации (в идеале они тоже должны заполняться OSPF, но я сам пока не пробовал)
  * <<Anchor(Hint)>>Подсказка. Есть три варианта настройки `web`;
   1. Я делал так:
    * на `srv` вписал в 0.0.0.0 зону `export all;` (чтобы пропихивать маршрут по умолчанию), а на `web` — нет;
    * этот маршрут приехал на `web` (а зря, у него свой) поэтому я в протокол `kernel` вписал `priority 200` (записи в таблице ядра стали более приоритетны, чем в таблице OSPF; по умолчанию — наоборот).
   1. Можно использовать на `web` в зоне 0.0.0.0 [[https://bird.network.cz/?get_doc&v=16&f=bird-5.html|фильтр]]:
   {{{
import filter { if (net = 10.3.3.0/24 ) then accept; reject; };
   }}}
   1. (''не рекомендуется: это абъюз условия, хотя формально всё верно'') Поскольку статические маршруты в целевых таблицах маршрутизации разрешены, можно на `web` вообще не запускать `bird`, а создать ''целевую'' таблицу маршрутизации на `client` и соответствующее правило.

Связность сети и целевая маршрутизация

Задачи (повторение):

  1. Глобальная идентификация (адресация)
    1. Структура адреса
    2. Механизм раздачи

  2. Алгоритм доставки (маршрутизация)
    1. Известный маршрут и маршрут по умолчанию внутри крупной сети
    2. Связность крупных сетей (карта достижимости / стоимость)

Автоматическая настройка «выхода в интернет» (быстрый старт)

  • 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

  • отслеживание общего статуса всей сети
  • расчёт кратчайшего взвешенного пути по Дейкстре
  • удаление петель

ПО: zebra, quagga, bird, frr

Настройка OSPF в BIRD

Площадка:

  • Routing.svg

  • 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 и ему подобные решают проблемы) — т. н. автономных систем

https://img-fotki.yandex.ru/get/5637/83739833.27/0_b9007_9151d107_XL.png

  • Выдаются IANA / локальными регистраторами

  • Сложный протокол BGP

    • Анонс собственной доступности
    • Вычисление доступности и стоимости других AS
  • Вот из AS-ок можно соорудить Full View, но
    • 940 000+ маршрутов

    • Имеет смысл только если у вас несколько AS в доступе
      • и вы хотите пропускать транзитный трафик либо выгадывать на стоимости перенаправления трафиков

    • Так делать большинство крупных операторов

  • Иначе — т. н. «Last resort» (он же default route)

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

(ещё раз упомяну Сети для самых маленьких с замечанием, что по этой теме они точно не про Linux)

Целевая маршрутизация

Destination-based принцип табличной маршрутизации: «сеть получателя ⇒ маршрут».

Задача source-based маршрутизации: «свойства пакета отправителя ⇒ маршрут».

Linux: просто заведём несколько таблиц маршрутизации (разных), и будем обрабатывать пакет по правилам одной из них сообразно его свойствам:

  • Адрес отправителя
  • Порт получателя (или отправителя)
  • Интерфейс, протокол и т. п. …

Команда ip rule (немного документации)

Заготовка:

  1. Два компьютера с выходом в интернет у каждого

  2. Маршрутизатор, подключённый к этим двум машинам по отдельным интерфейсам и третьей сетью для внутренних клиентов

Пример 1: подключаем два клиента ко внутренней сети, настраиваем source routing: с одного адреса пакеты в одну сторону, с другого — в другую

  • ../../LinuxNetwork2022/05_IProuteRule/SourceRouting.svg

# ip route add default второй_сервер table какой-то-номер
# ip rule add from «IP_B» table какой-то-номер

Пример 2: подключаем один клиент, перекидываем трафик по 80/443 портам в другую сторону

  • ../../LinuxNetwork2022/05_IProuteRule/PortRouting.svg

# 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

  1. Суть: объединить policy routing и OSPF в следующей топологии
    • ../../LinuxNetwork2022/05_IProuteRule/PortRouting.svg

    • Верхний сервер srv: «выход в интернет» + доступность машины client

    • Нижний сервер web: «выход в интернет» + доступность машины client

    • Маршрутизатор router:

      • TCP-соединения на 80-й и 443-й порты идут через web; весь остальной трафик (например, ping или traceroute) — через srv

    • Клиент client — «просто работает»

    • Дополнительное условие: никаких заранее заданных статических маршрутов (в т. ч. по умолчанию) в основной таблице маршрутизации, используйте OSPF (в srv и web они приедут по DHCP).

    • Допустимо использовать статические маршруты в целевых таблицах маршрутизации (в идеале они тоже должны заполняться OSPF, но я сам пока не пробовал)

    • Подсказка. Есть три варианта настройки web;

      1. Я делал так:
        • на srv вписал в 0.0.0.0 зону export all; (чтобы пропихивать маршрут по умолчанию), а на web — нет;

        • этот маршрут приехал на web (а зря, у него свой) поэтому я в протокол kernel вписал priority 200 (записи в таблице ядра стали более приоритетны, чем в таблице OSPF; по умолчанию — наоборот).

      2. Можно использовать на web в зоне 0.0.0.0 фильтр:

        import filter { if (net = 10.3.3.0/24 ) then accept; reject; };
      3. (не рекомендуется: это абъюз условия, хотя формально всё верно) Поскольку статические маршруты в целевых таблицах маршрутизации разрешены, можно на web вообще не запускать bird, а создать целевую таблицу маршрутизации на client и соответствующее правило.

  2. <!> ВНИМАНИЕ! Предварительная настройка в отчёт не входит! Отчёт делается по уже работоспособной сети.

  3. Отчёт (конфигурацию bird надо показывать, даже если вы его на данном хосте не использовали):

    1. 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

    2. report 5 router

      • ip addr

      • ip route

      • ip rule

      • ip route list table <номер>

        • <номер> — это номер целевой таблицы маршрутизации для web

        • Если в вашем решении используется несколько целевых таблиц, команда выполняется для каждой
      • grep "^[^#]" /etc/bird.conf

      • birdc show route

    3. 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

  4. Четыре отчёта сназваниями 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

LecturesCMC/LinuxNetwork2023/05_OSPFRule (последним исправлял пользователь FrBrGeorge 2023-03-30 19:06:54)