December 28, 2019

Border Gateway Protocol. Изучаем хитрости и обходим подводные камни

Источник: t.me/Bureau121

Содержание статьи

  • Автономная система с несвязанными частями
  • AS path prepend и контроль над входящим трафиком
  • Community strings
  • Стандартные ограничения и пути их обхода
  • Смотрим на себя извне
  • Заключение

Для примеров настроек мы будем использовать свободную реализацию стека протоколов FreeRangeRouting, которая работает на Unix-подобных системах и используется в специализированных сетевых дистрибутивах Linux, например Cumulus Linux и VyOS.

Автономная система с несвязанными частями

Считается, что все части автономной системы напрямую связаны между собой. Однако в ряде случаев приходится отступать от этого правила. При поэтапной миграции в другой датацентр это неизбежно. Точки присутствия в разных датацентрах с одним номером AS — нежелательная, но допустимая ситуация.

Казалось бы, достаточно разбить сеть на части — к примеру, 192.0.2.0/24 на 192.0.2.0/25 и 192.0.2.128/25, — настроить новый маршрутизатор на дополнительной точке присутствия и начать анонсировать оттуда 192.0.2.128/25. Но не все так просто: с параметрами по умолчанию все в интернете будут видеть обе части AS, но твои собственные маршрутизаторы потеряют связь друг с другом.

Почему это происходит? Предположим, ты используешь номер автономной системы 64500. Пусть между ее частями находится провайдер с номером 64501. Тогда AS path будет выглядеть так: 64500 64501 64500.

AS path в BGP — не только критерий выбора путей, но и механизм предотвращения петель. Если вспомнить про заложенное в протокол предположение, что все части AS связаны напрямую, наш путь выглядит именно как петля.

Реализации BGP считают закольцованным и отбрасывают любой маршрут, где один и тот же номер AS встречается в пути более одного раза. Но также они часто предоставляют возможность отказаться от заданного по умолчанию заведомо безопасного поведения. Этот случай — один из них. Опция обычно называется allowas-in. В качестве параметра она принимает максимально допустимое число дублированных номеров AS. Настроим ее, чтобы две одинаковые AS в пути не считались петлей:

router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 allowas-in 2
 exit-address-family

Конечно, с такими настройками твой маршрутизатор может начать пропускать и настоящие закольцованные маршруты. К счастью, на практике они в большом интернете не встречаются: транзитные провайдеры подобные опции не включают и правильно делают. Во внутренней же сети тебе ничто не мешает присвоить каждой независимой части отдельный номер AS из частного диапазона (64512–65534).

AS path prepend и контроль над входящим трафиком

Механизмы контроля над исходящим трафиком в BGP многочисленны и разнообразны. Входящий трафик — совсем другая история. В публичном интернете у тебя нет никаких способов прямого контроля над ним. Автономные системы на то и автономные, что не могут диктовать друг другу политики маршрутизации.

У любой автономной системы, однако, есть контроль над длиной AS path в исходящих анонсах, и это можно использовать как косвенный механизм контроля.

Как мы уже видели, один и тот же номер AS не может появляться в пути дважды в разных местах (то есть когда между экземплярами одного номера есть третий), иначе такой путь считается закольцованным. Однако несколько экземпляров одного номера подряд петлей не считаются. Путь вроде 64500 64500 64555 64501 не вызовет у реализаций BGP никаких возражений. При этом две одинаковые AS не считаются за одну, так что этот путь будет длиннее, чем 64500 64555 64501.

Искусственное удлинение пути называется AS path prepend и часто используется для влияния на выбор пути другими сетями. Если у тебя два провайдера и одному ты анонсируешь с путем 64500, а второму с 64500 64500, маршрут через первого будет выглядеть для других сетей более привлекательным. По крайней мере, в теории.

Вот так в FRR можно сделать путь на три номера AS длиннее, чем он есть:

!
route-map Transit-Out permit 10
 set as-path prepend 64496 64496 64496
!
router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map Transit-Out out
 exit-address-family

Теперь в show ip bgp мы увидим на выходе путь из трех копий нашей AS вместо обычного для локальных анонсов пустого пути:

## show ip bgp neighbors 192.0.2.1 advertised-routes
   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   0.0.0.0                  0         32768 64496 64496 64496 i

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

Так что более разумно использовать т. н. community strings, если твой транзитный провайдер их поддерживает.

Community strings

В отличие от всех остальных протоколов, в BGP есть механизм, который позволяет влиять на политику маршрутизации соседа, если сосед на это согласен.

Community strings — это произвольные значения вида AS:NUMBER (вроде 64500:111), которые можно присвоить анонсам на выходе и использовать в качестве критерия в политике на входе. В общем случае смысл конкретных значений определяется настройками, хотя и существует несколько стандартных значений, к примеру no-advertise, которое говорит маршрутизатору не распространять анонс остальным.

Транзитные провайдеры часто предоставляют клиентам такую возможность. В разделе BGP Services/Features в Cogent User Guide (двадцатая страница) можно увидеть целый набор опций для установки local preference и контроля над тем, кому Cogent будет анонсировать твой маршрут (никому, всем, отдельным регионам мира). У других провайдеров тоже обычно есть подобные документы — вот, к примеру, для российского RETN.

Предположим, ты хочешь дать своим соседям возможность выставить local preference на твоей стороне для их анонсов. Пусть твоя автономная система — 64500, а у клиента — 64496.

Сначала рассмотрим, как со стороны клиента отправить провайдеру строку. Отправим условному провайдеру анонс с community 64500:50. Вот как это можно сделать в FRR:

route-map Transit-Out permit 10
 set community 64500:50
!
router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map Transit-Out out
 exit-address-family

Теперь рассмотрим, как ее использовать для определения политик на стороне провайдера. Установим local preference для анонсов с такой строкой в 50 (меньше значения по умолчанию):

bgp community-list expanded Customer-Policy permit 64500:50
!
route-map Customer-Import permit 10
 match community Customer-Policy
 set local-preference 50
!

router bgp 64500
 neighbor 192.0.2.10 remote-as 64496
 !
 address-family ipv4 unicast
  neighbor 192.0.2.10 route-map Customer-Import in
 exit-address-family
!

Убедиться, что на провайдерской стороне все работает, можно все той же командой show ip bgp:

## show ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   192.0.2.10               0     50      0 64496 i

Стандартные ограничения и пути их обхода

В динамической ��аршрутизации есть множество способов наделать ошибок, поэтому реализации протоколов включают стандартные ограничения для предотвращения типичных проблем. В то же время граница между ошибкой и необычной, но осмысленной настройкой бывает тонкой.

В качестве примера рассмотрим опцию ebgp-multihop. По умолчанию BGP откажется устанавливать соединение с соседом, если он не находится в одном сегменте канального уровня (то есть между соседями есть промежуточные маршрутизаторы). Обычно это вполне логичная политика: маршрутизировать трафик через кого-то, кто с тобой не в одной сети, очевидно невозможно.

Однако BGP достаточно абстрактный протокол по сравнению со всеми остальными и позволяет установить для маршрутов свой шлюз. Из-за этого BGP нередко используют как метод автоматической передачи списков сетей, а что с этими сетями делать, каждый уже решает сам.

Компания Team Cymru таким способом предоставляет всем желающим актуальные списки сетей, которые еще не выделены ни одной компании и поэтому не должны появляться в интернете, — если к тебе приходит трафик из них, это явный признак IP spoofing.

Поскольку их сервер маршрутов находится где-то далеко в интернете и маршрутизировать трафик через него самого не предполагается, ограничение на нахождение соседей в одной сети к нему неприменимо. В этом случае нам и поможет опция ebgp-multihop, которая устанавливает максимально допустимое число промежуточных маршрутизаторов:

router bgp 64496
 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 ebgp-multihop 255

Смотрим на себя извне

Многие наверняка видели инструменты типа looking glass. Провайдеры нередко предоставляют интерфейс, с которого можно запустить ping и traceroute к указанному адресу из их сети. Обычно ничего другого и не нужно, но для отладки политик маршрутизации бывает полезно увидеть AS path. К счастью, транзитные провайдеры обычно дают и такую возможность. К примеру: Level3, Telia, Hurricane Electric.

Hurricane Electric поныне предоставляет доступ к своему looking glass еще и через telnet. Когда-то это был стандартный способ, реализации вроде Cisco IOS и Quagga или FRR предоставляют достаточно гибкое управление правами на выполнение команд, чтобы сделать такую конфигурацию безопасной и разрешить только просмотр данных. Глянем, через кого трафик из их сети пойдет в сеть Qrator (AS197068), за которой находится сайт «Хакера». Отрезолвим xakep.ru (178.248.232.27) и выполним команду:

$ telnet route-server.he.net
...
route-server> show ip bgp 178.248.232.27 bestpath
BGP routing table entry for 178.248.232.0/23
Paths: (23 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
    3491 197068 197068 197068
    216.218.252.151 from 216.218.252.151 (216.218.252.151)
      Origin IGP, metric 1, localpref 100, valid, internal, best
      Last update: Mon Sep 23 04:07:39 2019

Узнать, кому принадлежит номер автономной системы, можно через whois: whois AS3491 скажет нам, что на момент написания статьи этот провайдер — PCCW Global. Маршрутизация в интернете нередко меняется, так что не удивляйся, если повторишь и увидишь другой результат.

Заключение

Управлять автономной системой бывает непросто, но если внимательно читать документацию, это по силам каждому админу.

Если ты не работаешь в компании со своей AS, но тебе хочется поэкспериментировать с маршрутизацией в похожих на реальные условиях, можно присоединиться к DN42 — виртуальной сети, которая моделирует интернет с BGP, DNS, whois и прочими атрибутами.

ПОДПИСАТЬСЯ - Бюро121