GCP HA VPN: sesiunea BGP rămâne în Waiting for peer, inversarea perechii de adrese

O sesiune BGP care nu ajunge niciodată la Established pe un tunel Cloud VPN nu este de obicei o problemă de rutare. Este o problemă de cablare: două adrese care trebuie să se oglindească au fost introduse în ordinea greșită, sau perechea primului tunel a fost refolosită pe al doilea. Tunelul în sine poate fi perfect sănătos în timp ce sesiunea stă în Waiting for peer, pentru că IPsec și BGP sunt negocieri separate între aceleași două puncte terminale. Decideți care dintre cele două este defect înainte de a reconstrui ceva.

O singură întrebare rezolvă majoritatea cazurilor: vede dispozitivul partener adresa Cloud Router deloc?

Starea tunelului și starea sesiunii sunt verificări diferite

IKE și ESP vin primele. Dacă tunelul nu este stabilit, nimic din interiorul lui nu contează, iar discuția despre adresa BGP este prematură. Citiți starea și starea detaliată a tunelului, apoi starea partenerului BGP al routerului pentru același tunel.

Un tunel care funcționează în timp ce partenerul său BGP este oprit restrânge defecțiunea la sesiune: adresa partenerului, ASN sau TCP 179 care ajunge la adresa internă. Un tunel funcțional, o sesiune funcțională și încă nicio rută în VPC este un al treilea caz. Schimbarea adreselor nu ajută acolo, pentru că sesiunea funcționează deja și prefixul pur și simplu nu este anunțat sau nu este preferat. Separarea acestor trei cazuri este cea mai mare parte a muncii.

Fiecare tunel are nevoie de propriul /30, cu ambele capete completate

Fiecare tunel HA VPN primește un /30 link-local din 169.254.0.0/16, cu o adresă pe interfața Cloud Router și cealaltă pe partenerul dumneavoastră. Câmpul partenerului trebuie să numească capătul îndepărtat, niciodată adresa routerului însuși.

Două tuneluri înseamnă două interfețe pe Cloud Router, fiecare cu un /30 diferit. Refolosirea perechii tunelului 0 pe tunelul 1 este greșeala care arată îngrijit într-un tabel sumar și moare în pachetul OPEN.

Citiți perechea din resursa routerului, nu din sumarul consolei. Sumarul listează adresa partenerului într-o coloană ușor de citit greșit, iar ipRange al interfeței plus peerIpAddress al partenerului trebuie să descrie capete opuse ale aceluiași /30.

Inversarea are loc de obicei în timpul unei reconstrucții

Exact la reconstruirea unui tunel perechile se încrucișează. Adresa partenerului din tunelul vechi este copiată în câmpul de interfață al celui nou, sau sesiunea nouă este îndreptată spre partenerul sesiunii anterioare. În orice caz, Cloud Router trimite pachete OPEN către o adresă care este acum el însuși sau către o adresă fără tunel în spate.

Notați perechile înainte de a deschide consola: numele tunelului, interfața, adresa routerului, adresa partenerului, ASN-ul partenerului. Apoi creați ambele tuneluri dintr-o singură trecere, ca al doilea să nu fie completat cu resturile primului.

Alte trei motive pentru care o sesiune așteaptă

ASN-ul partenerului este primul: fiecare parte trebuie configurată cu ASN-ul celeilalte, iar o nepotrivire ajunge la partener dar nu se stabilește niciodată. Al doilea este firewall-ul partenerului însuși, care trebuie să permită TCP 179 pe interfața tunelului; o regulă IKE sau ESP nu acoperă asta. Al treilea este un partener care răspunde de la o adresă sursă diferită de cea configurată ca vecin al său.

Jurnalul partenerului însuși este discriminatorul. Dacă sumarul său BGP nu listează niciun vecin pentru acea adresă, pachetele nu ajung și perechea sau calea sunt greșite. Dacă vecinul stă în Active sau Connect, pachetele ajung și parametrii sesiunii nu coincid.

Verificați în ordinea în care călătoresc pachetele

Lucrați spre exterior: starea tunelului, apoi starea partenerului BGP al routerului, apoi sumarul BGP al partenerului, apoi rutele. Dacă primele două sunt sănătoase, opriți editarea părții Cloud VPN și lucrați pe dispozitivul partener. Dacă routerul raportează partenerul ca oprit și dispozitivul dumneavoastră nu are niciun vecin, perechea este greșită sau portul BGP este filtrat. O captură de pachete pe interfața tunelului partenerului rezolvă asta dintr-o privire, pentru că pachetele OPEN fie ajung acolo, fie nu ajung niciodată.

gcloud compute routers get-status ROUTER --region=REGION afișează starea partenerului lângă adresa pe care o folosește, iar aceasta este exact perechea pe care trebuie să o comparați.

După ce sesiunea se stabilește, confirmați că prefixul învățat apare în tabelul de rute al VPC și că un host din fiecare parte răspunde. Apoi notați perechile finale lângă numele tunelurilor, ca următoarea reconstrucție să pornească de la un tabel verificat, nu de la sumarul consolei.