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

BGP sesija koja nikad ne dosegne Established na Cloud VPN tunelu obično nije problem usmjeravanja. To je problem ožičenja: dvije adrese koje se moraju zrcaliti unesene su obrnutim redoslijedom ili je par prvog tunela ponovno iskorišten na drugom. Sam tunel može biti posve zdrav dok sesija stoji na Waiting for peer, jer su IPsec i BGP odvojena pregovaranja između istih dviju krajnjih točaka. Odlučite koja je od tih dviju pokvarena prije nego što bilo što ponovno izgradite.

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

Stanje tunela i stanje sesije dvije 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 stanje i detaljno stanje tunela, zatim stanje BGP peera usmjerivača 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 unutarnju 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 tih triju slučajeva veći je dio posla.

Svaki tunel treba vlastitu /30, s popunjena oba kraja

Svaki HA VPN tunel dobiva link-local /30 iz 169.254.0.0/16, s jednom adresom na sučelju Cloud Routera i drugom na vašem peeru. Polje peera mora imenovati udaljeni kraj, nikada vlastitu adresu usmjerivača.

Dva tunela znače dva sučelja na Cloud Routeru, svaki s drugom /30. Ponovno korištenje para tunela 0 na tunelu 1 pogreška je koja izgleda uredno u sažetoj tablici i umire u OPEN paketu.

Pročitajte par iz resursa usmjerivača, a ne iz sažetka u konzoli. Sažetak navodi adresu peera u stupcu koji je lako pogrešno pročitati, a ipRange sučelja plus peerIpAddress peera moraju opisivati suprotne krajeve jedne /30.

Zamjena se obično dogodi tijekom ponovne izgradnje

Parovi se ukrštaju upravo kad se tunel ponovno gradi. Adresa peera starog tunela kopira se u polje sučelja 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, sučelje, adresa usmjerivača, adresa peera, ASN peera. Zatim stvorite oba tunela u jednom prolazu da se drugi ne popuni ostacima prvoga.

Još tri razloga zašto sesija čeka

ASN peera je prvi: svaka strana mora biti konfigurirana s ASN-om druge strane, a neslaganje stigne do peera ali se nikad ne uspostavi. Drugi je vlastiti vatrozid peera, koji mora dopustiti TCP 179 na sučelju tunela; pravilo IKE ili ESP to ne pokriva. Treći je peer koji odgovara s druge izvorne adrese od one konfigurirane 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: stanje tunela, zatim stanje BGP peera usmjerivača, zatim BGP sažetak peera, zatim rute. Ako su prva dva zdrava, prestanite mijenjati stranu Cloud VPN i radite na peer uređaju. Ako usmjerivač prijavljuje peer kao pao, a vaš uređaj nema susjeda, par je pogrešan ili je BGP port filtriran. Snimanje paketa na sučelju tunela peera rješava to jednim pogledom jer OPEN paketi ili stignu tamo ili nikad ne stignu.

gcloud compute routers get-status ROUTER --region=REGION ispisuje stanje peera uz adresu koju koristi, a to je upravo par koji trebate usporediti.

Kad se sesija uspostavi, potvrdite da se naučeni prefiks pojavljuje u VPC tablici ruta i da po jedan host sa svake strane odgovara. Zatim zapišite konačne parove uz nazive tunela da sljedeća izgradnja počne od provjerene tablice, a ne od sažetka u konzoli.