Bgp туннель linux настройка
Обновлено: 05.07.2024
Настройка BGP для обхода блокировок, версия 3, без VPS
После их публикации я получил несколько вопросов от людей, которые пользуются VPN с не принадлежащих им ресурсов (например, приобретающих коммерческую услугу VPN). Этим людям раньше я советовал завести VPS для развертывания BGP-сервиса или каким-то еще образом получить доступ к серверу на Linux.
Но с сегодняшнего дня для них (и для всех остальных) есть более удобный вариант — на бесплатном сервисе antifilter.download появилась возможность автоматически настраивать BGP-сессию с вашим маршрутизатором.
Для его использования вам необходимо иметь всего лишь:
- фиксированный маршрутизируемый IP-адрес (т.н. "белый". Он может выделяться динамически, но должен быть всегда одним и тем же); UPD. Уже не важно, см. ниже по тексту.
- маршрутизатор с поддержкой протокола BGP (в статье, традиционно, пример построен на базе RouterOS маршрутизаторов Mikrotik);
- уже настроенный туннель VPN с этого маршрутизатора.
Умолчания в тексте статьи
- имя интерфейса туннеля на маршрутизаторе — gre-tunnel1
- номер автономной системы с вашей стороны — 64512 (выбираете сами в соответствии с RFC6996 — из диапазона 64512-65534 включительно).
- внешний IP-адрес вашего маршрутизатора — 81.117.103.94
Последовательность действий, если вы хотите управлять сервисом и у вас есть фиксированный маршрутизируемый IP-адрес
Делаем раз
заходим из вашей сети (это важно) на сайт antifilter.download, проматываем до раздела BGP, нажимаем "Активировать управление BGP".
Делаем два
проверяем, что сайт показывает именно наш IP, вводим выбранный номер своей автономной системы, помечаем чекбоксы, какие именно маршруты отдавать, подтверждаем капчу, нажимаем "Создать пиринг". После этого сайт покажет, что для вашего адреса настройки существуют. Время применения настроек в сервисе — не более 5 минут.
Делаем три
заходим на свой маршрутизатор Mikrotik и настраиваем на нем BGP-пиринг с сервисом:
Не забываем поменять умолчательные AS, IP и имя интерфейса на ваши. В вышеприведенных командах должно быть сделано четыре замены — не больше и не меньше.
… и всё работает
Если с момента нажатия кнопки "Создать пиринг" прошло более 5 минут и вы всё правильно настроили — у вас уже всё работает.
Если вы захотели поменять список выгружаемых в вашу сторону префиксов — это делается через удаление настроек на веб-странице и создание их вновь, благо — из настроек там одно число и три галочки.
Префиксы от сервиса маркируются соответствующими комьюнити, поэтому если захочется строить более сложные правила обработки — всё в ваших руках.
Настоятельно не рекомендую подключать список одиночных IP — даже топовым SOHO-маршрутизаторам Mikrotik от него не очень хорошо, а средние, например hAP lite, ведут себя крайне непредсказуемо.
UPD. Последовательность действий, если у вас нет фиксированного IP или вас устраивают настройки по умолчанию
Делаем раз
заходим на свой маршрутизатор Mikrotik и настраиваем на нем BGP-пиринг с сервисом:
Не забываем поменять умолчательные router-id и имя интерфейса на ваши. В вышеприведенных командах должно быть сделано три замены — не больше и не меньше. В качестве router-id можете написать в принципе любое тридцатидвухбитное число в формате IP-адреса, но чтобы не вызвать спецэффектов при совпадении, я бы рекомендовал использовать ваш текущий внешний IP-адрес. При его изменениях менять его необходимости не будет.
Номер AS в этом случае фиксированный, 64999, как и набор анонсируемых префиксов (ipsum+subnet), если кому-то этого чересчур много — всегда можно при приеме фильтровать по комьюнити или другими способами манипулировать анонсами.
… и всё работает
Если после активации настроек на вашем роутере прошло более 5 минут и вы всё правильно настроили — у вас уже всё работает.
При смене IP-адреса сессия будет восстанавливаться ориентировочно в течение 5 минут.
Заключение
Да, я понимаю, что уже "горшочек, не вари", и надеюсь, что на этом для меня тема обхода блокировок закрыта.
В статье детально рассмотрены механизмы функционирования протокола динамической маршрутизации BGP. Приведены инструкции по настройке маршрутизаторов Cisco и пакета Quagga на базе Gentoo Linux. Собран работающий стенд, в котором связность между сетями осуществляется благодаря маршрутам, анонсированным по протоколу BGP. На базе этого стенда проведены испытания переключения на резервный канал при падении основного. Так же приведены настройки фильтрации маршрутной информации при обмене с соседними BGP маршрутизаторами.
Во, тема :) Пошел рюхать .
Вместо Gentoo должна быть SuSE
порюхал. всё грамотно, зачет ! :)
Ожидал conformance теста, а не факта кнстантации, что мол на простейшем конфиге все пашет.
Что атрибут Weight реализовали тоже, молодцы, конечно.
Для простенькой сетки, в качестве CE, где не требуется поддержка QoS, SRST, RSVP, NAC и т.п. вполне себе решение. Хотя стенд не даёт в полной мере понять на что оно вообще способно, уж больно примитивная схема.
Не понял только, при чём тут Генту или, вообще, Линукс. Куагга Генту-специфик уже ? :-)
Гы! А кто анонсы на резервный канал препендить будет? Косячники :)
> Для простенькой сетки, в качестве CE, где не требуется поддержка QoS,
А при чём тут Куагга ?
>Для простенькой сетки, в качестве CE, где не требуется поддержка QoS, SRST, RSVP, NAC и т.п. вполне себе решение.
У кошководов точно мания величия.
Нахватаются умных слов, начитаются про великий маретинговый пук cisco и начинают городить огороды.
Только вот почему-то у почти всех супер-пупер поставщиков сервиса, где супер-пупер атестированные специалисты и супер сиськи с наибессмысленейшим протоколом комутации (mpls), качество сервиса ниже чем у задохленького провайдера с vlan сетями и linux роутерами. Почему, не знаю.
> где супер-пупер атестированные специалисты и супер сиськи с
> наибессмысленейшим протоколом комутации (mpls),
Вот только про mpls не надо.
>Нахватаются умных слов, начитаются про великий маретинговый пук cisco и начинают городить огороды.
А то, что эти умные слова описаны в различных RFC ничего? Или они тоже пук? :)
Да вобщем-то понтовость оборудования никак не коговорит о качестве сервиса. У нас (Республика Беларусь) крупнейший провайдер-монополист терминирует ppoe исключительно на Linux Debian, и качество у него надо сказать повыше остальных, хоть и дороже немного.
Опять реклама на лоре (
> ровайдер-монополист терминирует ppoe исключительно на Linux
терминирует - от слова "терминатор"?
>А то, что эти умные слова описаны в различных RFC ничего?
Для Вас эти заветные буквы "RFC" гарантия того, что это типа ТруЪ. Мне жаль вас. Туда все кому не лень пытаются засунуть любой продукт жизнедеятельности своего мозга!
Я на хочу сказать, что комитеты по стандартизации это зло. Как раз наоборот. Но востребованность и качество какой-либо технологии увы не гаратируется упоминанием в RFC.
> Вот только про mpls не надо.
Надо, Сергей, надо. Cisco придумали mpls так-как не смогли обеспечить приемлимую скорость ip маршрутизации. Всё остальное про mpls - маркетинговый бред. Какой телеком зарабатывает на mpls хоть какую-нибудь значимую сумму? Кроме cisco никто на mpls не зарабатывает. Да ещё mpls запатентована по самое нихачу.
> Cisco придумали mpls так-как не смогли обеспечить приемлимую скорость ip маршрутизации.
Несовсем IP, несовсем маршрутизации и несовсем Cisco.
> несовсем маршрутизации
>Тяжёлый случай
В каждой шутке есть только доля шутки, всё остальное правда.
>Cisco придумали mpls так-как не смогли обеспечить приемлимую скорость ip маршрутизации
не одни они не смогли, а вобще с IP коммутацией до cisco игралась ipsilon, ныне nokia, все было на базе ATM (аминь), их ATM-коммутаторы могли выполнять некоторые функции IP-маршрутизации, а сиско отошло от IP-коммутации к коммутации по меткам и опиралось _не_только_ на ATM
>Какой телеком зарабатывает на mpls хоть какую-нибудь значимую сумму? Кроме cisco никто на mpls не зарабатывает
ты имеешь ввиду операторов связи или производителей телекомовского железа?
А эта самая любимая всеми квагга(экс. зебра) до сих пор падает каждые двадцать минут? Ни одна из версий мной протещеных к боевым условиям непригодна была. Они даже прям в комплекте спешиал утилиту кваггавотч давали - которая смотрит наличие пида нужных демонов кваггиных и перезапускает если что не так. под лялихом ни бгп, ни оспф завести полноценно не получилось =(( нежуто оно стало более живучим?
тема тестирования не очень раскрыта.
думаю в качестве "шустрого старта по BGP" сгодится, а для серьёзных извращений маловато. Хотя откуда статья взялась тоже понятно - netup выступает в качестве регистратора AS -нарегистрировали всем желающим, а теперь пытаются объяснить как с этим счастьем бороться :)
>А эта самая любимая всеми квагга(экс. зебра) до сих пор падает каждые двадцать минут? . нежуто оно стало более живучим?
Стало. РИП, БГП, ОСПФ работают вполне сносно.
Клева. weight допилили как раз к началу конца bgp4 :-)
во во. типа quagga на других дистрах работает по-другому
> А эта самая любимая всеми квагга(экс. зебра) до сих пор падает каждые двадцать минут?
А как ты этого добился ? Ни Зебра не падала каждые 20 мин, ни Куагга. ospfd.
>Вместо Gentoo должна быть SuSE
А какже ВинИксПи ? :))
+1
Наблюдаю аналогичную картину.
Ну чтож, очерк как очерк.. ;-)
уж не корбину ли имеете ввиду?:)
> уж не корбину ли имеете ввиду?:)
Не корбину, не знаю как там у них всё устроено.
> А эта самая любимая всеми квагга(экс. зебра) до сих пор падает каждые двадцать минут? Ни одна из версий мной протещеных к боевым условиям непригодна была. Они даже прям в комплекте спешиал утилиту кваггавотч давали - которая смотрит наличие пида нужных демонов кваггиных и перезапускает если что не так. под лялихом ни бгп, ни оспф завести полноценно не получилось =(( нежуто оно стало более живучим?
идем BSDun ★ ( 09.01.07 20:57:47 )
Когда я ее щупал (
2003) ripd там был явно лучше - сучье поделие из зебры периодически клонировало себя(каждые
7 минут), или же делало кольца если время на соседних маршрутизаторах различается.
Хотя и в квагге не все гладко было - таймеры окособочивало - ntpdate скорректировал время секунд на 20, таймеры апдейтов уезжают секунд на 200к(set timers 60 90 120 до сих пор помню, уродское поделие).
Ospf оттуда вообще заводился только в двух режимах - или тупо молчит, или сегфолтится. Ковыряние в мейл-листе показало лишь наличие тем sigsegv* в огромном количестве -_-
Не показатель, мы тоже в свое время много косяков там прикрывали :)
люди, вы чего на ночь глядя ? :)
> До кучи, заголовок не рулит, а так статья средней не нужности. > НЕ зачет.
так и скажи, что ниасилил. нИзачет.
ну как чего? те у кого циска длиннее пытаются доказать свою исключительность. те, кого жизнь ещё не научила пытаются доказать, что они самые умные. А те которые умные, те читают и посмеиваются, потому, что знают: и в циске и кваге столько глюков, что на всех хватит.
а вообще достала эта байда от циски про разные технологии, которые реально или подпорки для слабого железа или просто пшик. достала квагга, которая падает каждые 20 минут (а то и чаще) если на _циске_ неправильно конфиг набит. у меня разнородная сеть, если начала падать квагга - ищи ошибки.
PS. Не по теме конечно, но может кто подскажет куда копать, чтобы сделать аналог openvpn (tcp) под циской (12.2). а то знаний не хватает :(
А мне кажется уважаемый Dimetrio весьма тонко пошутил, не упомянув прямо небезизвестный зюзероутер.
> Зачем на их максимум 155 мбит каналах mpls - убей, непойму.
Чувак, окстись, ты тут за лажу mpls лечишь а сам не в теме. Тот-же транстелеком давно работает на 10G.
> Да, быстрый level 2 vpn, но это на**й никому не нужно. Кому нужен vpn - сделают через ip по дешевке, а не по бешенным тарифам mpls.
Вот когда тебе понадобится просунуть Q-in-Q vlan с поддержкой CoS по которому вместе с ip трафиком ходит пачка какого-нть TDMoE из Питера в Москау (далеко ходить не будем чтобы не выпендриваться), то я специально приеду посмотреть на этот цирк, как ты c "ip по дешевке" будешь кружлять. Это будет просто незабываемое зрелище.
> И третье - РТК и ТТК - это самые настоящие выродки, выблевки традиционных телефонистов.
Наличие картельного сговора не говорит о том что все магистральщики - выблевки телефонистов. Бегом учить матчасть.
mpls там есть точно ;)
Эх, зачем его удалили! Я прямо в мемориз хотел забить этот крик души бедняги, который не дорос, судя по всему, даже до клиента тех же РТК и ТТК (потому что иначе понимал хотя бы суть предоставляемых услуг).
Кстати, меня с собой возьми, коллега, смотреть на то, как он ставит конфигурацию с "ip подешевке".
anonymous (*) (10.01.2007 6:17:11)
(Вот когда тебе понадобится просунуть Q-in-Q vlan с поддержкой CoS по которому вместе с ip трафиком ходит пачка какого-нть TDMoE)
Не путайте способ реализации задачи с самой задачей. Ваш способ убог, так как требует много излишеств, обусловленных цисками. Все намного проще, такое не понадобится. Учить не буду, так как бесполезно: "у того цисковода длиннее, кто больше денег циско отдал" (
C не помню кого).
Про корбину ничего не скажу.
Была история с одним оператором, заказали выделенный канал точка-точка.
Дают маршрутизируемое (два шлюза оператора, которые мы должны прописывать у себя) соединение. Звоним оператору:
- Нужна была точка-точка.
- Так и есть.
- Как же так и есть, если логика соединения не прозрачна?
- А иначе нельзя.
- Почему?
- Потому что MPLS.
Тьфу.
Не знаю как щас в, а в 99 году, полосатая лошадь аки зебра, (мелкой полосатой лошади аки куага еще просто не было) породила своеобразный протокол - BGPoVoice. У меня стояла мурка на другой стороне зебра. С зелено-полосатой по SNMP снимались данные о BGP сессиях, как то только сессия слошадью рушилась, а происходило это где то пару раз в сутки, дежурный звонил в конюшню где, с матюками полосатой коняге били HUP-ом по сусалам. Такая вот история. Не так давно ставил куагу, работала без проблем и работает без проблем, запустилась пинком под пушистый зад, с одним НО, конфигурация была дюже простой, с одним аплинком, просто приспичило людям АС иметь, а что ее родную им как провайдер алокешен впарили этот нюанс им донесли слишком поздно.
Ой да таки пусть они строят свои l2- и l3-vpn на линуксах (а что, ведь освоили же PPPoE на сотне-другой "домашних" клиентов). И пусть включаются в конкурентную борьбу на рынке магистральных операторов. Все равно ведь те зажравшиеся буржуи, которые правят там бал сейчас, обречены со своей самоубийственной ориентацией на таких же зажравшихся вендоров навроде Cisco. А уж инвестиции в опорную сеть размером во всю страну - это мелочи. Вот циски - это затраты, да!
..Хотя, пожалуй, нет. Какую еще конкурентную борьбу! "Отнять всё, да и поделить! Поровну." (с)
> под лялихом ни бгп, ни оспф завести полноценно не получилос
у меня получилось правда не под zebra/quagga - а под bird и всего 2 пути (но full-view) - ксттаи памяти сожрало меньше чем на киске.:)
> Не путайте способ реализации задачи с самой задачей. Ваш способ убог, так как требует много излишеств, обусловленных цисками. Все намного проще, такое не понадобится. Учить не буду, так как бесполезно: "у того цисковода длиннее, кто больше денег циско отдал" (
C не помню кого).
Коллега, если вам необходимо прокинуть l2 vlan trunk из одного города в другой (допустим новосиб-москва), c заданным QoS в каждом vlan, даже без поддержки на mstp в этом транке, допустим для транзита netbios трафика (клиент так хочет) и TDM трафика в интересах пары-тройки других клиентов, то как магистральный оператор без mpls выкручиваться будет ? Мне просто интересно. Не в разрезе "такое не понадобится". Мне надобится. А то может я своему оператору зря деньги плачу, а он меня разводит как лоха ?
Только про вещи типа L2TP и TDMoIP мне рассказывать не надо, потому-что первое суть "клятые технологии cisco", а второе при приемлимой задержке и приемлимом antijitter buffer дает почти полуторакратный оверхед. А этот полуторакратный оверхед стоит очень приличных бабок.
Понадобилось на работе настроить динамическую маршрутизацию по протоколу BGP, чтобы сэкономить время на настройке статических маршрутов. Поэкспериментировал для начала на виртуальных машинах на домашнем компьютере, подготовил для себя шпаргалку. На работе настраивал свои серверы в паре с сетевым администратором, который со своей стороны настраивал аппаратные маршрутизаторы. (Данила, если ты это читаешь, то передаю тебе привет!) Когда работа была выполнена, дополнил шпаргалку несколькими полезными разделами.
Через пару месяцев понадобилось вернуться к настройке BGP по ещё двум поводам. Во-первых, на одной из виртуальных машин в целях резервирования анонсы нужно было принимать сразу от двух соседних маршрутизаторов. Во-вторых, понадобилось настроить сервер, который сам в целях резервирования должен быть доступен через два соседних маршрутизатора. Конфигурацию этого сервера проверил и дополнил другой сетевой администратор. (Андрей, тебе тоже привет!) В результате добавил в шпаргалку ещё несколько пунктов.
По обыкновению выбрасываю отработанный материал в мусоркублог.
Установка пакетов
Для установки демона маршрутизации Quagga с поддержкой одного лишь протокола BGP достаточно установить только один пакет:Вместе с этим пакетом будет установлен также пакет quagga-core, в котором находится демон zebra. Демон zebra отвечает за добавление маршрутов, полученных от демонов динамической маршрутизации, в системную таблицу маршрутизации.
Настройка демона zebra
Демон zebra выполняет роль прослойки между операционной системой и демонами динамической маршрутизации. Демоны динамической маршрутизации выступают в роли клиентов демона zebra и пользуются его API.
Первоначальная настройка демона zebra проста, нужно создать файл конфигурации /etc/quagga/zebra.conf с содержимым следующего вида:
После этого можно включать автозапуск демона при загрузке системы и запустить сам демон маршрутизации:
Дальнейшее управление демоном, в том числе его конфигурирование, можно осуществлять при помощи команды telnet:
Через telent доступен интерфейс командной строки, похожий на интерфейс командной строки устройств Cisco. После изменения настроек не забывайте сохранять их при помощи команды write.
Я настраивал демона на двух тестовых виртуальных машинах с именами bgp1 и bgp2.
Настройка демона bgpd
Демон bgpd реализует поддержку протокола динамической маршрутизации BGP.
Для первоначальной настройки демона bgpd нужно создать файл /etc/quagga/bgpd.conf.
На первой виртуальной машине содержимое файла конфигурации было примерно таким:
Эта виртуальная машина лишь анонсирует две сети на вторую виртуальную машину. Номера автономных систем на обеих виртуальных машинах одинаковы и взяты из диапазона 64496-64511 для примеров и документации. Поскольку используются одинаковые номера автономных систем, то в нашем случае будет использоваться вариант протокола iBGP - внутренний протокол пограничных шлюзов.
На второй виртуальной машине содержимое файла конфигурации было примерно следующим:
Эта виртуальная машина не анонсировала своих сетей, зато принимала анонсы от первой.
После первоначальной настройки можно на обеих виртуальных машинах включить автозапуск демонов bgpd при загрузке системы и запустить их:
Подобно демону zebra, управление и настройку демона bgpd можно осуществлять при помощи команды telnet:
Точно так же через telent доступен интерфейс командной строки, похожий на интерфейс командной строки устройств Cisco. После изменения настроек не забывайте сохранять их при помощи команды write.
Белый список маршрутов
Рассмотрим конфигурирование демона bgpd через telnet. Для примера настроим фильтрацию маршрутов на второй виртуальной машине. Для начала подключаемся через telnet:
Вводим пароль, который был указан в опции password.
Далее повышаем собственные привилегии при помощи команды enable. В ответ на запрос команды enable вводим пароль, который был указан в опции enable password.
Далее переходим в режим настройки при помощи команды configure terminal:
Настроим сначала список префиксов, который назовём PREFIX-LIST-FROM-BGP1:
Теперь создадим на основе этого списка префиксов маршрутную карту с именем MAP-FROM-BGP1:
Добавим в маршрутную карту список префиксов PREFIX-LIST-FROM-BGP1:
И покинем диалог настройки маршрутной карты:
Осталось немного. Переходим в режим настройки протокола динамической маршрутизации bgp:
Добавим созданную маршрутную карту для фильтрации маршрутов, получаемых от соседа:
Покидаем режим настройки bgp:
Сохраняем изменения конфигурации на диск:
Осталось выйти из режима конфигурирования:
В процессе настройки из любого режима можно проверять правильность каждой введённой команды, просматривая текущий файл конфигурации при помощи команды show running-config:
Чтобы посмотреть текущую таблицу маршрутов, можно воспользоваться командой show ip bgp:
Если нужно применить новый или изменённый фильтр к уже принятым маршрутам, можно воспользоваться командой clear ip bgp такого вида:
После этого все маршруты, не разрешённые маршрутной картой явным образом, должны пропасть из списка текущих маршрутов.
Чёрный список маршрутов
Цель настройки динамической маршрутизации заключается в том, чтобы перестать добавлять статические маршруты в систему вручную. Однако, если вместо этого придётся добавлять те же самые маршруты в белый список, то ручной работы не станет меньше. В большинстве случаев достаточно просто принимать все маршруты безо всякой фильтрации, но иногда может понадобиться не принимать маршруты до отдельных сетей. В таком случае поможет чёрный список маршрутов.
Не буду повторять предыдущий раздел, а расскажу кратко. Поскольку логика фильтрации обратная - нужно отбрасывать маршруты из списка, а не принимать их, то в маршрутной карте действие permit заменяется на deny:
В списке префиксов действия permit не меняется. Чтобы отбросить анонсы сети 169.254.254.0/24, нужно поместить в список одну запись:
Также может потребоваться не принимать анонсы маршрутов не только с точно совпадающим префиксом, но и анонсы маршрутов ко всем сетям, находящимся внутри указанной. Сделать это можно следующим образом:
Выражение "le 32" означает, что условию удовлетворяют не только сети с префиксом 169.254.253.0/24, но и со всеми префиксами с длиной меньше 32 или равными 32. Например, если маршрутизатор BGP1 будет анонсировать маршруты к сетям 169.254.253.0/25 и 169.254.253.128/26, то оба анонса будут отброшены маршрутной картой.
Фильтрация исходящих анонсов
Сетевые администраторы рекомендуют создавать маршрутную карту не только для принимаемых маршрутов, но и для анонсируемых. Двойная защита позволяет застраховаться от непредусмотренных ошибок, допущенных при конфигурации одного из узлов.
Делается это аналогично фильтрации принимаемых маршрутов, с той лишь разницей, что ключевое слово in нужно заменить на out и прописать имя соответствующей маршрутной карты:
Если маршрутизатор должен только принимать анонсы, то такая маршрутная карта будет выглядеть следующим образом:
Применение политик без разрыва сеансов BGP
При изменении маршрутных карт и списков префиксов, чтобы новые политики фильтрации вступали в силу, нужно выполнять команду следующего вида:
Эта команда разрывает сеанс BGP с соседним маршрутизатором и устанавливает его заново. При этом соседний маршрутизатор вновь анонсирует весь список маршрутов, который и подвергается фильтрации.
Чтобы не разрывать сеансы BGP только лишь для того, чтобы применить новые политики фильтрации маршрутов, сетевые администраторы рекомендуют включить для соседа режим мягкой переконфигурации:
В этом режиме сеанс BGP с соседним маршрутизатором не разрывается, а фильтрация применяется к уже принятому ранее списку маршрутов.
Описание соседей
Даже если в конфигурации BGP описан только один соседний маршрутизатор, лучше снабдить его описанием, чтобы в дальнейшем не приходилось ориентироваться только на IP-адреса и номера автономных систем. Сделать это можно следующим образом:Группировка настроек соседей
Первое, что приходит в голову - это объединить списки префиксов и маршрутные карты:
Конфигурация стала короче, замысел стал более понятным, но всё ещё есть возможность поменять настройки одного маршрутизатора, не меняя настройки второго. Настройки соседей можно сгруппировать:
Теперь оба соседа состоят в одной группе и их настройки объединены, так что будут меняться только одновременно, если специально не отделить их друг от друга. Получившийся файл конфигурации стал короче и нагляднее.
Ограничение доступа к терминалу
Анонсирование адреса Loopback-интерфейса
Если BGP настраивается на сервере для того, чтобы сервер был доступен через два маршрутизатора, то IP-адрес сервера, анонсируемый соседям по протоколу BGP, настраивается не на физическом интерфейсе, а на так называемом Loopback-интерфейсе.
Для примеров настроек мы будем использовать свободную реализацию стека протоколов 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 в пути не считались петлей:
Конечно, с такими настройками твой маршрутизатор может начать пропускать и настоящие закольцованные маршруты. К счастью, на практике они в большом интернете не встречаются: транзитные провайдеры подобные опции не включают и правильно делают. Во внутренней же сети тебе ничто не мешает присвоить каждой независимой части отдельный номер AS из частного диапазона (64512–65534).
AS path prepend и контроль над входящим трафиком
У любой автономной системы, однако, есть контроль над длиной AS path в исходящих анонсах, и это можно использовать как косвенный механизм контроля.
Как мы уже видели, один и тот же номер AS не может появляться в пути дважды в разных местах (то есть когда между экземплярами одного номера есть третий), иначе такой путь считается закольцованным. Однако несколько экземпляров одного номера подряд петлей не считаются. Путь вроде 64500 64500 64555 64501 не вызовет у реализаций BGP никаких возражений. При этом две одинаковые AS не считаются за одну, так что этот путь будет длиннее, чем 64500 64555 64501 .
Искусственное удлинение пути называется AS path prepend и часто используется для влияния на выбор пути другими сетями. Если у тебя два провайдера и одному ты анонсируешь с путем 64500 , а второму с 64500 64500 , маршрут через первого будет выглядеть для других сетей более привлекательным. По крайней мере, в теории.
Продолжение доступно только участникам
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Читайте также: