GCP HA VPN: BGP сесията застава на Waiting for peer, разменени двойки адреси

BGP сесия, която никога не достига до Established на тунел Cloud VPN, обикновено не е проблем с маршрутизирането. Това е проблем с окабеляването: два адреса, които трябва да си съответстват огледално, са въведени в грешен ред, или двойката на първия тунел е използвана отново за втория. Самият тунел може да е напълно изправен, докато сесията стои на Waiting for peer, защото IPsec и BGP са отделни преговори между същите две крайни точки. Решете кое от двете е повредено, преди да престроите каквото и да е.

Един въпрос решава повечето случаи: вижда ли устройството партньор адреса на Cloud Router изобщо?

Състоянието на тунела и състоянието на сесията са различни проверки

IKE и ESP са първи. Ако тунелът не е установен, нищо вътре в него няма значение и разговорът за BGP адреса е преждевременен. Прочетете статуса и подробния статус на тунела, после статуса на BGP партньора на рутера за същия този тунел.

Тунел, който е вдигнат, докато BGP партньорът му е свален, стеснява неизправността до сесията: адрес на партньора, ASN или TCP 179, пристигащ на вътрешния адрес. Тунел, който е вдигнат, сесия, която е вдигната, и все още никакви маршрути във VPC е трети случай. Смяната на адреси няма да помогне там, защото сесията вече работи и префиксът просто не се обявява или не се предпочита. Разграничаването на тези три случая е по-голямата част от работата.

Всеки тунел се нуждае от собствена /30 с попълнени два края

Всеки тунел HA VPN получава link-local /30 от 169.254.0.0/16, с един адрес на интерфейса на Cloud Router и другия на вашия партньор. Полето за партньор трябва да посочва далечния край, никога собствения адрес на рутера.

Два тунела означават два интерфейса на Cloud Router, всеки с различна /30. Повторното използване на двойката на тунел 0 за тунел 1 е грешката, която изглежда подредена в обобщена таблица и умира в пакета OPEN.

Четете двойката от ресурса на рутера, а не от обобщението в конзолата. Обобщението показва адреса на партньора в колона, която лесно се чете погрешно, а ipRange на интерфейса плюс peerIpAddress на партньора трябва да описват противоположните краища на една /30.

Размяната обикновено се случва при преустройство

Двойките се кръстосват точно когато тунелът се преустройва. Адресът на партньора на стария тунел се копира в полето за интерфейс на новия, или новата сесия се насочва към партньора на предишната. И в двата случая Cloud Router изпраща пакети OPEN към адрес, който сега е самият той, или към адрес без тунел зад него.

Запишете двойките, преди да отворите конзолата: име на тунела, интерфейс, адрес на рутера, адрес на партньора, ASN на партньора. След това създайте двата тунела на един ход, за да не се попълва вторият от остатъците на първия.

Още три причини една сесия да чака

ASN на партньора е първата: всяка страна трябва да е конфигурирана с ASN на другата, а несъответствие стига до партньора, но никога не се установява. Втората е собствената защитна стена на партньора, която трябва да допуска TCP 179 на интерфейса на тунела; правило за IKE или ESP не го покрива. Третата е партньор, който отговаря от различен адрес на източника от този, конфигуриран като негов съсед.

Собственият журнал на партньора е решаващият признак. Ако обобщението му за BGP не изброява съсед за този адрес, пакетите не пристигат и двойката или пътят са грешни. Ако съседът стои в Active или Connect, пакетите пристигат и параметрите на сесията не съвпадат.

Проверявайте в реда, в който пътуват пакетите

Работете навън: статус на тунела, после статус на BGP партньора на рутера, после обобщението за BGP на партньора, после маршрутите. Ако първите две са изправни, спрете да редактирате страната Cloud VPN и работете по устройството партньор. Ако рутерът отчита партньора като свален, а вашето устройство няма съсед, двойката е грешна или портът BGP е филтриран. Прихващане на пакети на интерфейса на тунела на партньора го решава с един поглед, защото пакетите OPEN или пристигат там, или никога не пристигат.

gcloud compute routers get-status ROUTER --region=REGION отпечатва състоянието на партньора до адреса, който използва, и това е точно двойката, която трябва да сравните.

След като сесията се установи, потвърдете, че наученият префикс се появява в таблицата с маршрути на VPC и че по един хост от всяка страна отговаря. След това запишете крайните двойки до имената на тунелите, така че следващото преустройство да започва от проверена таблица, а не от обобщението в конзолата.