GCP HA VPN: BGP sesija zaglavljena na Waiting for peer, zamena para adresa

BGP sesija koja nikada ne dostigne Established na Cloud VPN tunelu obično nije problem rutiranja. To je problem ožičenja: dve adrese koje moraju da se ogledaju jedna u drugoj unete su obrnutim redosledom, ili je par prvog tunela ponovo iskorišćen na drugom. Sam tunel može biti potpuno zdrav dok sesija stoji na Waiting for peer, jer su IPsec i BGP odvojena pregovaranja između istih dveju krajnjih tačaka. Odlučite koja je od te dve pokvarena pre nego što bilo šta ponovo izgradite.

Jedno pitanje rešava većinu slučajeva: da li peer uređaj uopšte vidi adresu Cloud Routera?

Stanje tunela i stanje sesije su različite provere

IKE i ESP dolaze prvi. Ako tunel nije uspostavljen, ništa unutar njega nije važno i rasprava o BGP adresi je prerana. Pročitajte status i detaljni status tunela, zatim status BGP peera rutera za taj isti tunel.

Tunel koji je podignut dok je njegov BGP peer pao sužava kvar na sesiju: adresa peera, ASN ili TCP 179 koji dolazi na unutrašnju adresu. Tunel podignut, sesija podignuta i još uvek nema ruta u VPC-u treći je slučaj. Promena adresa tu neće pomoći, jer sesija već radi a prefiks se jednostavno ne oglašava ili se ne preferira. Razdvajanje ta tri slučaja je veći deo posla.

Svaki HA VPN tunel dobija sopstvenu /30, sa popunjena oba kraja

Svaki HA VPN tunel dobija link-local /30 iz 169.254.0.0/16, sa jednom adresom na interfejsu Cloud Routera i drugom na vašem peeru. Polje peera mora da imenuje udaljeni kraj, nikada sopstvenu adresu rutera.

Dva tunela znače dva interfejsa na Cloud Routeru, svaki sa drugom /30. Ponovno korišćenje para tunela 0 na tunelu 1 je greška koja izgleda uredno u sažetoj tabeli i umire u OPEN paketu.

Pročitajte par iz resursa rutera, a ne iz sažetka u konzoli. Sažetak navodi adresu peera u koloni koju je lako pogrešno pročitati, a ipRange interfejsa plus peerIpAddress peera moraju da opisuju suprotne krajeve jedne /30.

Zamena se obično dogodi tokom ponovne izgradnje

Parovi se ukrštaju upravo kada se tunel ponovo gradi. Adresa peera starog tunela kopira se u polje interfejsa novog, ili se nova sesija usmerava na peera prethodne sesije. U oba slučaja Cloud Router šalje OPEN pakete na adresu koja je sada on sam ili na adresu iza koje nema tunela.

Zapišite parove pre otvaranja konzole: naziv tunela, interfejs, adresa rutera, adresa peera, ASN peera. Zatim napravite oba tunela u jednom prolazu, da se drugi ne popuni ostacima prvog.

Još tri razloga zašto sesija čeka

ASN peera je prvi: svaka strana mora biti konfigurisana sa ASN-om druge strane, a neslaganje stigne do peera ali se nikada ne uspostavi. Drugi je sopstveni firewall peera, koji mora da dozvoli TCP 179 na interfejsu tunela; IKE ili ESP pravilo to ne pokriva. Treći je peer koji odgovara sa druge izvorne adrese od one konfigurisane kao njegov sused.

Sopstveni log peera je odlučujući. Ako njegov BGP sažetak ne navodi suseda za tu adresu, paketi ne dolaze i par ili putanja su pogrešni. Ako sused stoji u Active ili Connect, paketi dolaze a parametri sesije se ne slažu.

Proveravajte redom kojim paketi putuju

Radite prema spolja: status tunela, zatim status BGP peera rutera, zatim BGP sažetak peera, zatim rute. Ako su prva dva zdrava, prestanite da menjate stranu Cloud VPN i radite na peer uređaju. Ako ruter prijavljuje peer kao pao a vaš uređaj nema suseda, par je pogrešan ili je BGP port filtriran. Snimanje paketa na interfejsu tunela peera rešava to jednim pogledom, jer OPEN paketi ili stignu tamo ili nikada ne stignu.

gcloud compute routers get-status ROUTER --region=REGION ispisuje stanje peera pored adrese koju koristi, a to je upravo par koji treba uporediti.

Kada se sesija uspostavi, potvrdite da se naučeni prefiks pojavljuje u VPC tabeli ruta i da po jedan host sa svake strane odgovara. Zatim zapišite konačne parove pored naziva tunela, da sledeća izgradnja počne od proverene tabele, a ne od sažetka u konzoli.