Чому BGP поверх VPN не керує шляхом нижнього рівня

Два майданчики встановлюють BGP через тунель IPsec, вивчають префікси одне одного, і схема перейменовується на керування шляхом. Саме ця етикетка й починає плутанину. Сесія справді обмінюється доступністю і справді застосовує політику, але вона не має голосу в тому, який провайдер, кабель чи маршрутизатор несе зашифровані пакети. Я бачив команду, яка перебудовувала робочий тунель, бо очікувала, що зміна маршруту BGP переведе трафік на інший оптоволоконний шлях, на який сесія ніколи не могла вплинути.

Що люди думають, що купує сесія

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

BGP — протокол доступності. Він повідомляє партнеру, що ви можете доставити пакети для префікса, і дозволяє кожній стороні ранжувати отримані пропозиції. Через тунель це справді корисно: префікси з'являються й зникають разом із майданчиками, і ви можете відмовити в діапазоні, не записуючи статичний маршрут на кожному граничному пристрої. Чого він не робить — не ставить маршрутизатори провайдера під ваш контроль.

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

Що насправді несе сесія

Спікер BGP відкриває TCP-з'єднання до порту 179 свого партнера, використовуючи формати повідомлень і атрибути шляху, визначені в RFC 4271. Коли адреса партнера лежить усередині тунелю, тунель має бути піднятий, а адреса доступною до того, як сесія взагалі почнеться. Завершений обмін IKE — це не сусід BGP. Реалізації IPsec на основі маршрутів пропускають трафік лише тоді, коли існує відповідний маршрут тунелю, а реалізація на основі політики потребує адреси партнера всередині захищеного селектора. Зворотний порядок дає класичний стан, коли тунель зелений, а сесія простоює.

Щойно сесія піднята, політика вирішує, що її перетинає. Списки префіксів, фільтри AS-path, стеля максимальної кількості префіксів і явне рішення про маршрути за замовчуванням — це мінімум, і вони діють в обох напрямках. Партнер, який приймає все, що отримує, може дати вам маршрут за замовчуванням, який тихо замінює локальний доступ до інтернету. Обидва напрямки потребують окремих списків, бо те, що ви приймаєте від партнера, і те, що ви йому анонсуєте, — різні рішення.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Далі кусає MTU. Інкапсуляція зменшує корисне навантаження, тому велике оновлення може зупинити сесію, яка виглядає цілком усталеною: партнер залишається піднятим, префікси так і не приходять, і нічого очевидного не потрапляє до журналу. Обмежте TCP MSS на інтерфейсі тунелю або задайте MTU тунелю із запасом на накладні витрати, перш ніж звинувачувати фільтри.

Куди все ще йдуть зовнішні пакети

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

Вибір маршруту й установлення пересилання — теж окремі події. Префікс може стояти в таблиці BGP як найкращий і все одно бути відсутнім у таблиці пересилання, бо наступний хоп не розв'язується або перемагає конкретніший маршрут. Коли хтось повідомляє, що BGP вивчив префікс, але трафік не тече, корисне питання — чи встановлено його і на який наступний хоп він указує.

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

Три рішення, які варто розділити

Коли дизайн змішує це, кожна розмова про збій іде по колу. Спершу розділіть їх на папері, потім прив'яжіть кожне до пристрою, який справді його виконує.

Кожен рядок має іншого власника. Перший — переговори, другий — конфігурація на ваших пристроях, третій — переважно чужа мережа. Запит на зміну, який називає рядок, якого він торкається, набагато легше затвердити, ніж той, що каже проблема BGP.

Режими відмови, які варто планувати

Прийняття зведеного маршруту партнера — найпоширеніша самозавдана рана. Хтось анонсує короткий агрегат, щоб спростити обмін, віддалена сторона його приймає, і трафік для діапазонів, яких немає за тунелем, іде за тунелем і гине. Фільтруйте за точно очікуваними префіксами або використовуйте список префіксів із правильними межами й ніколи не приймайте голий агрегат, бо він робить сесію охайною на вигляд.

Час відкликання — другий. Виявлення залежить від таймерів утримання, від BFD, якщо ви його ввімкнули, від виявлення мертвого партнера тунелю і від того, як швидко віддалена сторона перестає анонсувати. Наявні сесії — окрема проблема: новий маршрут може відновити нові з'єднання, поки встановлені сесії TCP продовжують використовувати застарілі адреси, а міжмережеві екрани зі станом або NAT на шляху можуть тримати записи, які вже не збігаються. Помістіть відновлення застосунку в критерії приймання замість припущення, що зміна маршруту вирішує все.

Третє — асиметрія зворотного шляху. Трафік може приходити через тунель і повертатися каналом провайдера, який ніколи не призначався для його перенесення, що проявляється як односторонній звук, невдалі рукостискання або міжмережевий екран, що відкидає відповіді. Перевіряйте обидва напрямки окремо.

Що записати в контракт і як це перевірити

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

Потім перевіряйте з пристрою, а не зі схеми. Корисні команди на маршрутизаторах у стилі FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Додайте два спостереження, яких таблиця маршрутів дати не може. Захопіть на зовнішньому інтерфейсі, щоб підтвердити, на яку адресу насправді націлені інкапсульовані пакети, наприклад tcpdump -ni eth0 udp port 51820 для тунелю WireGuard або фільтр ESP для IPsec. Потім простежте до публічної адреси партнера і порівняйте хопи з трасуванням усередині тунелю; якщо обидва йдуть одним ланцюгом провайдера, ваша надлишковість живе в політиці маршрутів, а не в мережі.

Насамкінець навмисно перевірте відкликання. Опустіть тунель у вікно обслуговування, зафіксуйте, як довго префікс залишається встановленим, що відбувається з наявними сесіями і чи повертається віддалена сторона до маршруту, який ви справді прийняли б. Ця вправа каже про дизайн більше, ніж будь-яка схема.

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

• Назвіть префікси, які кожна сторона може створювати, і ті, які вона ніколи не повинна приймати.
• Обмежте MSS на тунелі й підтвердьте, що великі оновлення справді приходять.
• Перелічіть спільні залежності нижнього рівня, а не кількість тунелів.
• Виміряйте реальне відкликання й занотуйте, що робить застосунок.