BGP-адреси Cloud VPN належать усередині тунелю, а не на мережевій карті

Відкрийте сторінку Cloud Router для VPN, і на вас дивиться BGP-сесія з адресою в 169.254.0.0/16. Природна реакція — розмістити цю адресу десь на VM і чекати, поки сесія підніметься. Ця реакція хибна в конкретний спосіб: пара належить логічному каналу, який створює тунель IPsec, а не звичайному мережевому інтерфейсу машини. Ніщо з доданого на NIC не змусить тунель нести BGP.

Прослідкуйте парою вниз стеком замість того, щоб додавати її на хост.

Почніть там, де консоль показує пару

Сторінка сесії перелічує BGP-адресу Cloud Router і адресу партнера, обидві link-local для HA VPN IPv4. Поруч — зовнішні адреси шлюзів, які термінують тунелі. Це різні об'єкти: пара link-local живе всередині, а адреси шлюзів живуть зовні й мають бути маршрутизованими, перш ніж запрацює щось інше.

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

Спустіться до тунелю, який її несе

Пара link-local набуває сенсу лише тоді, коли між двома шлюзами існує асоціація безпеки IPsec. На боці Google тунелі HA VPN створюють її на двох інтерфейсах; на вашому боці це те, що погодив партнер. Спершу перевірте асоціацію даних за допомогою swanctl --list-sas і позначте, який тунель піднятий на якому інтерфейсі, бо здорова сесія BGP поверх мертвого тунелю неможлива, а мертвий тунель зі сповненою надії конфігурацією — звична річ.

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

Тепер налаштуйте партнера Linux відповідно

Виберіть підтримуваний дизайн тунелю й дозвольте йому визначити внутрішні адреси. За маршрутного інтерфейсу запис маршрутизації та узгоджені селектори трафіку мають збігатися, бо сама лише назва інтерфейсу нічого не дозволяє. Спрямуйте BIRD на внутрішню локальну адресу та внутрішню адресу Cloud Router, задайте номери AS зі сторінки сесії й дозвольте TCP 179 усередині захищеного шляху. Тримайте маршрут до далекої зовнішньої адреси на фізичному uplink, щоб тунель не захоплював власний транспорт.

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

Перевіряйте кожен етап по черзі, а не все одразу

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

Встановлений сусід не гарантує, що обидві сторони оголосили потрібні вам префікси або що ці маршрути встановлені як пріоритетні.

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

Зупиніться, перш ніж застосовувати це до Router Appliance

Network Connectivity Center Router Appliance — це інша модель підключення. Його партнери Cloud Router використовують внутрішні адреси з розкладки VPC і підмережі, а не пару link-local HA VPN. Якщо справжня мета — BGP з маршрутизувальною VM, дотримуйтесь вимог до інтерфейсу цього продукту, а не копіюйте сесію link-local.

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