GCP HA VPN: BGP sesija įstringa ties Waiting for peer, adresų poros sukeitimas
Cloud VPN BGP sesija, įstrigusi ties Waiting for peer, dažniausiai turi sukeistas tunelio ir kito galo adresus. Patikrinkite porą prieš ką nors perstatydami.
BGP sesija, kuri Cloud VPN tunelyje niekada nepasiekia Established, dažniausiai nėra maršrutizavimo problema. Tai laidų problema: du adresai, kurie turi atspindėti vienas kitą, buvo įvesti neteisinga tvarka, arba pirmojo tunelio pora buvo panaudota antrajame. Pats tunelis gali būti visiškai sveikas, kol sesija stovi ties Waiting for peer, nes IPsec ir BGP yra atskiros derybos tarp tų pačių dviejų galinių taškų. Nuspręskite, kuri iš šių dviejų sulaužyta, prieš ką nors perstatydami.
Vienas klausimas išsprendžia daugumą atvejų: ar kito galo įrenginys apskritai mato Cloud Router adresą?
Tunelio būsena ir sesijos būsena yra skirtingi patikrinimai
Pirmiausia IKE ir ESP. Jei tunelis nesukurtas, niekas jo viduje neturi reikšmės ir kalbos apie BGP adresą yra per ankstyvos. Perskaitykite tunelio būseną ir išsamią būseną, tada to paties tunelio maršrutizatoriaus BGP kito galo būseną.
Tunelis, kuris veikia, o jo BGP kitas galas neveikia, susiaurina gedimą iki sesijos: kito galo adresas, ASN arba TCP 179, patenkantis į vidinį adresą. Tunelis veikia, sesija veikia ir vis dar nėra maršrutų VPC tai trečias atvejis. Adresų keitimas ten nepadės, nes sesija jau veikia, o priešdėlis tiesiog nėra skelbiamas arba jam neteikiama pirmenybė. Šių trijų atvejų atskyrimas yra didžioji darbo dalis.
Kiekvienas tunelis turi turėti savo /30 su užpildytais abiem galais
Kiekvienas HA VPN tunelis gauna link-local /30 iš 169.254.0.0/16, vienas adresas Cloud Router sąsajoje, kitas jūsų kitame gale. Kito galo laukas turi įvardyti tolimąjį galą, niekada paties maršrutizatoriaus adreso.
Du tuneliai reiškia dvi sąsajas Cloud Router, kiekviena su skirtingu /30. Tunelio 0 poros naudojimas tunelyje 1 yra klaida, kuri atrodo tvarkingai suvestinėje lentelėje ir žūna OPEN pakete.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Porą skaitykite iš maršrutizatoriaus ištekliaus, o ne iš konsolės suvestinės. Suvestinė nurodo kito galo adresą stulpelyje, kurį lengva perskaityti neteisingai, o sąsajos ipRange kartu su kito galo peerIpAddress turi apibūdinti priešingus vieno /30 galus.
Sukeitimas dažniausiai įvyksta perstatant
Būtent perstatant tunelį poros susikerta. Senojo tunelio kito galo adresas nukopijuojamas į naujojo tunelio sąsajos lauką, arba nauja sesija nukreipiama į ankstesnės sesijos kitą galą. Bet kuriuo atveju Cloud Router siunčia OPEN paketus adresui, kuris dabar yra jis pats, arba adresui, už kurio nėra tunelio.
Užsirašykite poras prieš atidarydami konsolę: tunelio pavadinimas, sąsaja, maršrutizatoriaus adresas, kito galo adresas, kito galo ASN. Tada sukurkite abu tunelius vienu kartu, kad antrasis nebūtų užpildytas pirmojo likučiais.
Dar trys priežastys, kodėl sesija laukia
Kito galo ASN yra pirmoji: kiekviena pusė turi būti sukonfigūruota su kitos pusės ASN, o neatitikimas pasiekia kitą galą, bet niekada neužmezgamas. Antroji yra paties kito galo užkarda, kuri turi leisti TCP 179 tunelio sąsajoje; IKE arba ESP taisyklė to neapima. Trečioji yra kitas galas, kuris atsako iš kito šaltinio adreso nei tas, kuris sukonfigūruotas kaip jo kaimynas.
Paties kito galo žurnalas yra skiriamasis požymis. Jei jo BGP suvestinėje nėra kaimyno tam adresui, paketai neatvyksta ir pora arba kelias yra neteisingi. Jei kaimynas yra Active arba Connect būsenoje, paketai atvyksta, o sesijos parametrai nesutampa.
Tikrinkite ta tvarka, kuria keliauja paketai
Dirbkite į išorę: tunelio būsena, tada maršrutizatoriaus BGP kito galo būsena, tada kito galo BGP suvestinė, tada maršrutai. Jei pirmieji du sveiki, nustokite redaguoti Cloud VPN pusę ir dirbkite su kito galo įrenginiu. Jei maršrutizatorius praneša, kad kitas galas neveikia, o jūsų įrenginyje nėra kaimyno, pora neteisinga arba BGP prievadas filtruojamas. Paketų fiksavimas kito galo tunelio sąsajoje tai išsprendžia vienu žvilgsniu, nes OPEN paketai arba ten atvyksta, arba niekada neatvyksta.
gcloud compute routers get-status ROUTER --region=REGION išspausdina kito galo būseną šalia adreso, kurį jis naudoja, ir tai yra būtent ta pora, kurią reikia palyginti.
Kai sesija užmezgama, patvirtinkite, kad išmoktas priešdėlis atsiranda VPC maršrutų lentelėje ir kad po vieną hostą kiekvienoje pusėje atsako. Tada užsirašykite galutines poras prie tunelių pavadinimų, kad kitas perstatymas prasidėtų nuo patikrintos lentelės, o ne nuo konsolės suvestinės.