BGP адресите на Cloud VPN принадлежат вътре в тунела, а не на мрежовата карта

Отворете страницата Cloud Router за VPN и срещу вас гледа BGP сесия с адрес в 169.254.0.0/16. Естествената реакция е да сложите този адрес някъде на VM и да чакате сесията да вдигне. Тази реакция е грешна по конкретен начин: двойката принадлежи на логическата връзка, която създава IPsec тунелът, а не на обичайния мрежов интерфейс на машината. Нищо, което добавите към NIC, не кара тунела да носи BGP.

Следвайте двойката надолу по стека, вместо да я добавяте към хоста.

Започнете там, където конзолата показва двойката

Страницата на сесията изброява BGP адрес на Cloud Router и адрес на партньор, и двата link-local за IPv4 HA VPN. До тях са външните адреси на шлюза, които терминират тунелите. Това са различни обекти: двойката 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.