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.