GCP HA VPN: seja BGP obstane na Waiting for peer, zamenjava para naslovov

Seja BGP, ki na tunelu Cloud VPN nikoli ne doseže Established, običajno ni težava usmerjanja. To je težava ožičenja: dva naslova, ki se morata zrcaliti, sta bila vnesena v napačnem vrstnem redu, ali je bil par prvega tunela znova uporabljen na drugem. Sam tunel je lahko popolnoma zdrav, medtem ko seja stoji na Waiting for peer, ker sta IPsec in BGP ločena pogajanja med istima dvema končnima točkama. Odločite, kateri od obeh je pokvarjen, preden karkoli znova zgradite.

Eno vprašanje reši večino primerov: ali naprava partnerja sploh vidi naslov Cloud Routerja?

Stanje tunela in stanje seje sta različna preverjanja

Najprej prideta IKE in ESP. Če tunel ni vzpostavljen, nič v njem ni pomembno in razprava o naslovu BGP je preuranjena. Preberite stanje in podrobno stanje tunela, nato stanje partnerja BGP usmerjevalnika za isti tunel.

Tunel, ki je gor, medtem ko je njegov partner BGP dol, zoži napako na sejo: naslov partnerja, ASN ali TCP 179, ki prihaja na notranji naslov. Tunel gor, seja gor in še vedno ni poti v VPC je tretji primer. Spreminjanje naslovov tam ne pomaga, ker seja že deluje in se predpona preprosto ne oglašuje ali ne preferira. Ločevanje teh treh primerov je večina dela.

Vsak tunel potrebuje svoj /30 z izpolnjenima obema koncema

Vsak tunel HA VPN dobi link-local /30 iz 169.254.0.0/16, en naslov na vmesniku Cloud Routerja in drugega pri vašem partnerju. Polje partnerja mora navesti oddaljeni konec, nikoli lastnega naslova usmerjevalnika.

Dva tunela pomenita dva vmesnika na Cloud Routerju, vsak z drugim /30. Ponovna uporaba para tunela 0 na tunelu 1 je napaka, ki je v povzetni tabeli videti urejena in umre v paketu OPEN.

Par preberite iz vira usmerjevalnika, ne iz povzetka v konzoli. Povzetek navaja naslov partnerja v stolpcu, ki ga je lahko napačno prebrati, ipRange vmesnika in peerIpAddress partnerja pa morata opisovati nasprotna konca enega /30.

Zamenjava se običajno zgodi med ponovno gradnjo

Prav pri ponovni gradnji tunela se pari križajo. Naslov partnerja starega tunela se kopira v polje vmesnika novega, ali nova seja kaže na partnerja prejšnje seje. V vsakem primeru Cloud Router pošilja pakete OPEN na naslov, ki je zdaj on sam, ali na naslov brez tunela za seboj.

Zapišite pare pred odpiranjem konzole: ime tunela, vmesnik, naslov usmerjevalnika, naslov partnerja, ASN partnerja. Nato ustvarite oba tunela v enem prehodu, da se drugi ne napolni z ostanki prvega.

Še trije razlogi, zakaj seja čaka

ASN partnerja je prvi: vsaka stran mora biti konfigurirana z ASN druge, in neskladje doseže partnerja, a se nikoli ne vzpostavi. Drugi je lastni požarni zid partnerja, ki mora dovoliti TCP 179 na vmesniku tunela; pravilo IKE ali ESP tega ne pokriva. Tretji je partner, ki odgovarja z drugega izvornega naslova, kot je tisti, konfiguriran kot njegov sosed.

Odločilen je lastni dnevnik partnerja. Če njegov povzetek BGP ne navaja soseda za ta naslov, paketi ne prihajajo in par ali pot sta napačna. Če je sosed v stanju Active ali Connect, paketi prihajajo in parametri seje se ne ujemajo.

Preverjajte v vrstnem redu, v katerem potujejo paketi

Delajte navzven: stanje tunela, nato stanje partnerja BGP usmerjevalnika, nato povzetek BGP partnerja, nato poti. Če sta prva dva zdrava, prenehajte urejati stran Cloud VPN in delajte na napravi partnerja. Če usmerjevalnik poroča partnerja kot dol in vaša naprava nima nobenega soseda, je par napačen ali je vrata BGP filtrirana. Zajem paketov na vmesniku tunela partnerja to razreši na prvi pogled, ker paketi OPEN tja bodisi pridejo bodisi nikoli ne pridejo.

gcloud compute routers get-status ROUTER --region=REGION izpiše stanje partnerja ob naslovu, ki ga uporablja, in to je natanko par, ki ga morate primerjati.

Ko se seja vzpostavi, potrdite, da se naučena predpona pojavi v tabeli poti VPC in da po en gostitelj na vsaki strani odgovori. Nato zapišite končne pare ob imena tunelov, da se naslednja ponovna gradnja začne s preverjene tabele in ne s povzetka v konzoli.