Спершу фільтруйте, потім обирайте: політика BGP edge, яка відмовляє безпечно

Бути multi-homed не те саме, що бути стійким. Два оператори transit і порт на точці обміну дають вам варіанти; політика маршрутизації вирішує, чи роблять ці варіанти вас швидшими й безпечнішими, чи просто дають поганому маршруту більше шляхів усередину. Ось як ми думаємо про політику edge, у тому порядку, в якому маршрут її насправді зустрічає.

Проблема, яку має кожна multi-homed мережа

Тієї миті, коли ви берете повні таблиці від більш ніж одного оператора, ваш router обирає між шляхами цілий день, кожен день, і обирає за правилами, які написали ви. Якщо ви не написали жодного, він повертається до типових tie breakers BGP: найкоротший AS path, потім каскад деталей, які не мають нічого спільного із затримкою, вартістю чи вашими клієнтами.

Звичний короткий шлях: спершу прикрутити перевагу до сесій («віддавати перевагу оператору A, він дешевший») і додати фільтрацію пізніше, якщо взагалі. Цей порядок перевернутий. Перевага є рішенням про хороші маршрути. Якщо сміття не прибрали до того, як це рішення ухвалюється, ви ретельно ранжуєте сміття.

Етап перший: гігієна, до будь-якого рішення

Кожна вхідна сесія, transit чи peer, проходить через ту саму політику гігієни до того, як будь-що інше торкнеться маршруту. Список короткий і нудний, у чому й суть:

Bogons. Приватний, зарезервований, документаційний і нерозподілений простір не має чого робити, прибуваючи з інтернету.

Ваші власні префікси. Маршрут до вашого власного простору, вивчений ззовні, є або петлею, або перехопленням. Відкиньте його.

Маршрут за замовчуванням. Якщо ви не просили оператора про default, ви не хочете, щоб він з’являвся через те, що хтось вище помилився.

Занадто специфічні. Будь-що довше за /24 для IPv4 (і /48 для IPv6) за домовленістю не маршрутизується глобально. Приймаючи це, ви запрошуєте перехоплення через більш специфічні префікси.

Абсурдні AS path. Шляхи з приватними ASN у них або шляхи, набагато довші, ніж потребує будь-який справжній маршрут.

У загальних термінах route-policy Cisco IOS-XR скелет виглядає так:

route-policy TRANSIT-IN
  if destination in BOGONS-V4 or destination in OUR-PREFIXES then
    drop
  endif
  if destination in (0.0.0.0/0) then
    drop
  endif
  if destination in (0.0.0.0/0 ge 25) then
    drop
  endif
  if as-path in PRIVATE-ASNS then
    drop
  endif
  apply SET-PREFERENCE
end-policy

Зверніть увагу, що логіка переваги застосовується в самому кінці, як окрема політика. Гігієна однакова на кожній сесії; перевага відрізняється від сесії до сесії. Тримаючи їх окремо, ви гарантуєте, що зміна керування трафіком ніколи не послабить фільтрацію випадково.

Етап другий: перевага ярусами

Щойно лишилися тільки осудні маршрути, вирішіть, який шлях перемагає. Ми використовуємо яруси local preference замість одного числа на оператора, бо яруси описують намір:

Прямий peering перемагає. Маршрут, вивчений від самої мережі, на точці обміну або через двосторонню сесію, є найкоротшим шляхом, який ви можете отримати.

Власні клієнти оператора йдуть наступними. Якщо оператор transit позначає маршрути, вивчені від власних клієнтів, community, ці маршрути лишаються в мережі цього оператора з кінця в кінець.

Усе інше йде через той transit, який вимірюється найкращим для основної маси трафіку.

Другий оператор тримається «гарячим» як резерв: повна таблиця прийнята, нижча перевага, готовий тієї миті, коли перший відкликається.

Ще одне правило тихо відпрацьовує своє: ніколи не використовуйте одного оператора transit, щоб дістатися клієнтів іншого оператора, коли другий оператор підключений до вас напряму. Зіставлення сусіднього AS у шляху і зниження переваги зупиняє трафік від дорогого об’їзду через третю сторону.

Етап третій: вихідна дисципліна

Вихідна сторона простіша й важливіша. Анонсуйте рівно ті префікси, які ви породжуєте, і нічого більше:

prefix-set OUR-PREFIXES-V4
  192.0.2.0/24,
  198.51.100.0/24
end-set

route-policy TRANSIT-OUT
  if destination in OUR-PREFIXES-V4 then
    pass
  else
    drop
  endif
end-policy

Явний вихідний список дозволених означає, що помилка деінде у вашій мережі (перерозподілений static, клієнтський маршрут, який мав лишитися внутрішнім) не може зробити вас transit-шляхом для чужого трафіку. Формування зворотного шляху, таке як AS-path prepending у бік оператора, якого ви хочете менше використовувати на вході, відбувається всередині цієї політики, ніколи замість неї.

Етап четвертий: не породжуйте підроблений трафік

Політика маршрутизації контролює те, у що ви вірите; anti-spoofing контролює те, що ви надсилаєте. BCP38 каже, що мережа не повинна пересилати пакети, чия адреса джерела не могла легітимно прийти з-за інтерфейсу, на який вони прибули. На інтерфейсах у бік інтернету і клієнтів це означає unicast reverse path forwarding у strict mode там, де дозволяє топологія, або явні фільтри адреси джерела там, де не дозволяє. Це один з небагатьох контролів, які захищають решту інтернету від вас, і це різниця між тим, що скомпрометований сервер у вашій мережі є вашою проблемою, і тим, що він є проблемою всіх.

Перевірка власного edge

Якщо ви експлуатуєте власний edge або хочете поставити провайдеру правильні питання, ось короткий чекліст:

• Чи застосовується гігієна однаково на кожній вхідній сесії, включно з route servers точок обміну і «довіреними» peers?
• Чи можете ви показати, що /25 або ваш власний префікс, надісланий вам сусідом, відкидається? Перевірте в лабораторії або прочитайте політику рядок за рядком.
• Чи є ваша вихідна політика явним списком дозволених, чи «все, крім»?
• Чи знаєте ви, через якого оператора виходить ваш трафік до десяти найбільших призначень, і чому? Traceroute з edge плюс show bgp <prefix> відповідає на це за хвилини.
• Чи прив’язана фільтрація BCP38 до кожного інтерфейсу в бік інтернету і чи маєте ви тест, який це доводить?
• Чи вимірюєте ви свою мережу ззовні? Незалежна платформа, така як RIPE Atlas, показує, як інтернет насправді до вас доходить, що часто не збігається з тим, як думає ваш router.

Навіщо ми цим перейматися

Кожен із цих кроків невидимий доброго дня. Того дня, коли оператор витікає таблицю, виводить канал на обслуговування або сусід анонсує щось, чого не повинен, вони вирішують, чи помітить це ваш трафік. Ми експлуатуємо наші власні автономні системи з цією структурою на routers Cisco ASR 9000 і Juniper MX, безперервно вимірюючи ззовні, бо це єдиний відомий нам спосіб змусити multi-homed мережу поводитися передбачувано.

Якщо ви хочете другу пару очей на власній політиці edge, або платформу, яка стоїть за побудованою так, ми радо поговоримо.

Поговоріть з інженером

Related

Пов’язане: Власна мережа: дві ASN, багато операторів, peering · Моніторинг мережі та докази · IPv6, нативний і dual-stack