GCP HA VPN: BGP сесија заглављена на Waiting for peer, замена пара адреса

BGP сесија која никада не достигне Established на Cloud VPN тунелу обично није проблем рутирања. То је проблем ожичења: две адресе које морају да се огледају једна у другој унете су обрнутим редоследом, или је пар првог тунела поново искоришћен на другом. Сам тунел може бити потпуно здрав док сесија стоји на Waiting for peer, јер су IPsec и BGP одвојена преговарања између истих двеју крајњих тачака. Одлучите која је од те две покварена пре него што било шта поново изградите.

Једно питање решава већину случајева: да ли peer уређај уопште види адресу Cloud Router-а?

Стање тунела и стање сесије су различите провере

IKE и ESP долазе први. Ако тунел није успостављен, ништа унутар њега није важно и расправа о BGP адреси је прерана. Прочитајте статус и детаљни статус тунела, затим статус BGP партнера рутера за тај исти тунел.

Тунел који је подигнут док је његов BGP партнер пао сужава квар на сесију: адреса партнера, ASN или TCP 179 који долази на унутрашњу адресу. Тунел подигнут, сесија подигнута и још увек нема рута у VPC-у трећи је случај. Промена адреса ту неће помоћи, јер сесија већ ради а префикс се једноставно не оглашава или се не преферира. Раздвајање та три случаја је већи део посла.

Сваки тунел треба сопствени /30, са попуњена оба краја

Сваки HA VPN тунел добија link-local /30 из 169.254.0.0/16, са једном адресом на интерфејсу Cloud Router-а и другом на вашем peer-у. Поље партнера мора да именује удаљени крај, никада сопствену адресу рутера.

Два тунела значе два интерфејса на 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 и радите на peer уређају. Ако рутер пријављује партнера као пао а ваш уређај нема ниједног суседа, пар је погрешан или је BGP порт филтриран. Снимање пакета на интерфејсу тунела партнера решава то једним погледом, јер OPEN пакети или стигну тамо или никада не стигну.

gcloud compute routers get-status ROUTER --region=REGION исписује стање партнера поред адресе коју користи, а то је управо пар који треба упоредити.

Када се сесија успостави, потврдите да се научени префикс појављује у VPC табели рута и да по један хост са сваке стране одговара. Затим запишите коначне парове поред назива тунела, да следећа изградња почне од проверене табеле, а не од сажетка у конзоли.