Три запобіжники, які не дають клієнтському BGP-шлюзу розливати маршрути

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

Чому шлюзи на кожного клієнта взагалі говорять BGP

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

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

Як насправді стаються витоки

У більшості опублікованих розборів інцидентів причиною витоку маршрутів з пристрою на межі рідко є екзотична помилка BGP. Це редистрибуція. Хтось вмикає «redistribute connected» або «redistribute static», щоб менше друкувати, і шлюз починає анонсувати власний WAN-лінк, свій пул VPN-тунелів, підмережу керування або маршрут, який він вивчив звідкись іще. На firewall з відкритим кодом з демоном маршрутизації ця опція часто за один прапорець від вас.

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

Запобіжник перший: анонсуйте явними операторами network

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

router bgp 64601
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 64600
 address-family ipv4 unicast
  network 198.51.100.0/27
  neighbor 10.0.0.1 prefix-list CUSTOMER-OUT out
 exit-address-family

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

Запобіжник другий: вихідний prefix list, який збігається

Пояс і підтяжки. Навіть з явними операторами network вихідний prefix list дозволяє лише власні префікси клієнта і забороняє все інше:

ip prefix-list CUSTOMER-OUT seq 10 permit 198.51.100.0/27
ip prefix-list CUSTOMER-OUT seq 100 deny any

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

Запобіжник третій: жодної редистрибуції, і перевірка, що вона лишається вимкненою

Редистрибуцію вимкнено, і це частина конфігурації, яку ви перевіряєте, а не припущення. У FRR ви можете перевірити одним рядком:

vtysh -c 'show running-config' | grep -i redistribute

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

Порівняйте з відомо справним шлюзом перед доставкою

Три запобіжники запобігають витокам. Вони не запобігають іншій поширеній відмові шлюзів на кожного клієнта: одному налаштуванню, яке відрізняється від шлюзів, що працюють, через що VPN «не з’єднується» або з’єднується, не досягаючи нічого. Відсутнє правило pass для порту VPN на інтерфейсі WAN, вихідний NAT, залишений в автоматичному режимі, правило на інтерфейсі, обмежувальніше, ніж задумано, ледь помітно інша опція автентифікації: кожне легко пропустити оком.

Ліки механічні. Налаштовуйте кожен шлюз через його API, ніколи вручну, потім витягніть ті самі налаштування з перевіреного еталонного шлюзу і з нового і порівняйте їх поле за полем:

• Налаштування інстансу VPN: протокол, порт, шифри, режим автентифікації, маршрути і DNS, що передаються клієнтам.
• Правила firewall на WAN для порту VPN і діагностики.
• Правила на самому інтерфейсі VPN.
• Режим і правила вихідного NAT.
• Конфігурація BGP, включно з полем редистрибуції.

Будь-яка відмінність, яка не є явно очікуваною для цього клієнта, блокує доставку. Жодні облікові дані не залишають будівлю, доки порівняння не чисте. Це займає секунди і замінює пообіддя віддаленого усунення несправностей з користувачем, який просто хоче працювати.

Доступ для кожної людини окремо, зроблений належно

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

Чекліст для ваших власних шлюзів

• Чи кожен префікс клієнта анонсується явним оператором network?
• Чи є вихідний prefix list на кожній клієнтській сесії і відповідний вхідний централізовано?
• Чи повертає grep за redistribute порожній результат на кожному шлюзі?
• Чи налаштовуються шлюзи через API, з порівнянням результату з відомо справним еталоном перед доставкою?
• Чи є віддалений доступ персональним, із сертифікатами, які ви можете відкликати по одному?

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

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

Related (rows[1])

Пов’язане: Приватне підключення: VPN-шлюзи та орендовані лінії · Managed периметрові firewall · Шифрований backbone між сайтами: DMVPN mesh