GCP HA VPN: BGP-session hænger på Waiting for peer, ombytningen af adresseparret

En BGP-session, der aldrig når Established på en Cloud VPN-tunnel, er som regel ikke et routingproblem. Det er et kablingsproblem: to adresser, der skal spejle hinanden, blev indtastet i den forkerte rækkefølge, eller den første tunnels par blev genbrugt på den anden. Selve tunnelen kan være helt sund, mens sessionen står på Waiting for peer, fordi IPsec og BGP er separate forhandlinger mellem de samme to endepunkter. Afgør, hvilken af de to der er i stykker, før du genopbygger noget.

Et spørgsmål afgør de fleste tilfælde: ser peer-enheden overhovedet Cloud Routers adresse?

Tunnelstatus og sessionsstatus er forskellige kontroller

IKE og ESP kommer først. Hvis tunnelen ikke er etableret, betyder intet indeni noget, og diskussionen om BGP-adressen er for tidlig. Læs tunnelens status og detaljerede status, og læs derefter routerens BGP-peerstatus for netop den tunnel.

En tunnel, der er oppe, mens dens BGP-peer er nede, indsnævrer fejlen til sessionen: peer-adresse, ASN eller TCP 179, der ankommer på den indre adresse. En tunnel, der er oppe, en session, der er oppe, og stadig ingen ruter i VPC'en er et tredje tilfælde. At ændre adresser hjælper ikke der, fordi sessionen allerede virker, og præfikset bliver ganske enkelt ikke annonceret eller ikke foretrukket. At holde de tre tilfælde adskilt er det meste af arbejdet.

Hver tunnel skal have sit eget /30 med begge ender udfyldt

Hver HA VPN-tunnel får et link-local /30 fra 169.254.0.0/16, med én adresse på Cloud Router-interfacet og den anden på din peer. Peer-feltet skal navngive den fjerne ende, aldrig routerens egen adresse.

To tunneler betyder to interfaces på Cloud Router, hver med et forskelligt /30. At genbruge tunnel 0's par på tunnel 1 er den fejl, der ser pæn ud i en oversigtstabel og dør i OPEN-pakken.

Læs parret fra router-ressourcen i stedet for fra konsoloversigten. Oversigten viser peer-adressen i en kolonne, der er let at læse forkert, og interfacets ipRange plus peer'ens peerIpAddress skal beskrive modsatte ender af ét /30.

Ombytningen sker som regel under en genopbygning

Det er, når en tunnel genopbygges, at par krydses. Den gamle tunnels peer-adresse kopieres ind i den nye tunnels interfacefelt, eller den nye session peger på den forrige sessions peer. Uanset hvad sender Cloud Router OPEN-pakker til en adresse, der nu er den selv, eller til en adresse uden tunnel bag.

Skriv parrene ned, før du åbner konsollen: tunnelnavn, interface, router-adresse, peer-adresse, peer-ASN. Opret derefter begge tunneler i ét gennemløb, så den anden ikke bliver udfyldt fra den førstes rester.

Tre andre grunde til at en session venter

Peer-ASN er den første: hver side skal konfigureres med den andens ASN, og en uoverensstemmelse når peeren men etablerer sig aldrig. Den anden er peer'ens egen firewall, som skal tillade TCP 179 på tunnelinterfacet; en IKE- eller ESP-regel dækker det ikke. Den tredje er en peer, der svarer fra en anden kildeadresse end den, der er konfigureret som dens nabo.

Peer'ens egen log er den afgørende. Hvis dens BGP-oversigt ikke viser nogen nabo for den adresse, ankommer pakkerne ikke, og parret eller stien er forkert. Hvis naboen står i Active eller Connect, ankommer pakkerne, og sessionens parametre er uenige.

Kontroller i den rækkefølge, pakkerne bevæger sig

Arbejd udad: tunnelstatus, derefter routerens BGP-peerstatus, derefter peer'ens BGP-oversigt, derefter ruterne. Hvis de to første er sunde, så stop med at redigere Cloud VPN-siden og arbejd på peer-enheden. Hvis routeren rapporterer peeren som nede, og din enhed ikke har nogen nabo, er parret forkert, eller BGP-porten filtreres. En pakkefangst på peer'ens tunnelinterface afgør det ved et blik, fordi OPEN-pakker enten ankommer der eller aldrig gør.

gcloud compute routers get-status ROUTER --region=REGION udskriver peer-status ved siden af den adresse, den bruger, og det er præcis det par, du skal sammenligne.

Når sessionen er etableret, skal du bekræfte, at det lærte præfiks vises i VPC'ens rutetabel, og at én vært på hver side svarer. Skriv derefter de endelige par ned ved siden af tunnelnavnene, så den næste genopbygning starter fra en velafprøvet tabel i stedet for konsoloversigten.