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

BGP sesija koja nikada ne dostigne Established na Cloud VPN tunelu obično nije problem rutiranja. To je problem ožičenja: dvije adrese koje se moraju zrcaliti unesene su obrnutim redoslijedom, ili je par prvog tunela ponovo iskorišten na drugom. Sam tunel može biti potpuno zdrav dok sesija stoji na Waiting for peer, jer su IPsec i BGP odvojene pregovore između istih dvaju krajnjih točaka. Odlučite koja je od te dvije pokvarena prije nego što bilo šta ponovo izgradite.

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

Stanje tunela i stanje sesije su različite provjere

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š uvijek nema ruta u VPC-u treći je slučaj. Promjena 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 dio posla.

Svaki tunel treba vlastitu /30, s popunjena oba kraja

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

Dva tunela znače dva interfejsa na Cloud Routeru, svaki s drugom /30. Ponovno korištenje 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 opisivati suprotne krajeve jedne /30.

Zamjena 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 usmjerava 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 prije 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 s ASN-om druge strane, a neslaganje stigne do peera ali se nikada ne uspostavi. Drugi je vlastiti firewall peera, koji mora dopustiti TCP 179 na interfejsu tunela; IKE ili ESP pravilo to ne pokriva. Treći je peer koji odgovara s druge izvorne adrese od one konfigurisane kao njegov susjed.

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

Provjeravajte redom kojim paketi putuju

Radite prema van: status tunela, zatim status BGP peera rutera, zatim BGP sažetak peera, zatim rute. Ako su prva dva zdrava, prestanite mijenjati stranu Cloud VPN i radite na peer uređaju. Ako ruter prijavljuje peer kao pao a vaš uređaj nema susjeda, par je pogrešan ili je BGP port filtriran. Snimanje paketa na interfejsu tunela peera rješ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 trebate 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 sljedeća izgradnja počne od provjerene tabele, a ne od sažetka u konzoli.