GCP HA VPN: BGP-istunto jää jumiin tilaan Waiting for peer, osoiteparin vaihtuminen
Cloud VPN BGP -istunto, joka jää jumiin tilaan Waiting for peer, on yleensä vaihtanut tunnelin ja peerin osoitteet. Tarkista pari ennen kuin rakennat mitään uudelleen.
BGP-istunto, joka ei koskaan saavuta Established-tilaa Cloud VPN -tunnelissa, ei yleensä ole reititysongelma. Se on kytkentäongelma: kaksi osoitetta, joiden pitää peilata toisiaan, syötettiin väärässä järjestyksessä, tai ensimmäisen tunnelin paria käytettiin uudelleen toisessa. Itse tunneli voi olla täysin kunnossa samalla kun istunto seisoo tilassa Waiting for peer, koska IPsec ja BGP ovat erillisiä neuvotteluja samojen kahden päätepisteen välillä. Päätä, kumpi näistä kahdesta on rikki, ennen kuin rakennat mitään uudelleen.
Yksi kysymys ratkaisee useimmat tapaukset: näkeekö peer-laite Cloud Routerin osoitteen lainkaan?
Tunnelin tila ja istunnon tila ovat eri tarkistuksia
IKE ja ESP tulevat ensin. Jos tunneli ei ole pystyssä, mikään sen sisällä ei merkitse mitään ja BGP-osoitteesta keskustelu on ennenaikaista. Lue tunnelin tila ja yksityiskohtainen tila ja sen jälkeen reitittimen BGP-peer-tila samalle tunnelille.
Tunneli, joka on ylhäällä samalla kun sen BGP-peer on alhaalla, rajaa vian istuntoon: peer-osoite, ASN tai sisäosoitteeseen saapuva TCP 179. Tunneli ylhäällä, istunto ylhäällä ja yhä ei reittejä VPC:ssä on kolmas tapaus. Osoitteiden vaihtaminen ei auta siinä, koska istunto toimii jo eikä etuliitettä yksinkertaisesti mainosteta tai suosita. Näiden kolmen tapauksen erottaminen toisistaan on suurin osa työtä.
Jokainen tunneli tarvitsee oman /30-verkkonsa molemmat päät täytettyinä
Jokainen HA VPN -tunneli saa link-local /30-verkon alueesta 169.254.0.0/16, yhden osoitteen Cloud Routerin liitännälle ja toisen peerillesi. Peer-kentän pitää nimetä kaukokanta, ei koskaan reitittimen omaa osoitetta.
Kaksi tunnelia tarkoittaa kahta liitäntää Cloud Routerissa, kummallakin eri /30. Tunnelista 0 otetun parin käyttäminen uudelleen tunnelissa 1 on virhe, joka näyttää siistiltä yhteenvetotaulukossa ja kuolee OPEN-paketissa.
| 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 |
Lue pari reitittimen resurssista, älä konsolin yhteenvedosta. Yhteenveto listaa peer-osoitteen sarakkeessa, joka on helppo lukea väärin, ja liitännän ipRange sekä peerin peerIpAddress kuvaavat saman /30-verkon vastakkaisia päitä.
Vaihtuminen tapahtuu yleensä uudelleenrakennuksen aikana
Juuri tunnelia uudelleenrakennettaessa parit menevät ristiin. Vanhan tunnelin peer-osoite kopioidaan uuden tunnelin liitäntäkenttään, tai uusi istunto osoitetaan edellisen istunnon peeriin. Kummassakin tapauksessa Cloud Router lähettää OPEN-paketteja osoitteeseen, joka on nyt se itse, tai osoitteeseen, jonka takana ei ole tunnelia.
Kirjoita parit ylös ennen konsolin avaamista: tunnelin nimi, liitäntä, reitittimen osoite, peer-osoite, peer-ASN. Luo sitten molemmat tunnelit yhdellä kertaa, jotta toista ei täytetä ensimmäisen jäänteillä.
Kolme muuta syytä istunnon odottamiselle
Peer-ASN on ensimmäinen: kumpikin puoli on määritettävä toisen puolen ASN:llä, ja ero saavuttaa peerin mutta ei koskaan muodosta yhteyttä. Toinen on peerin oma palomuuri, jonka on sallittava TCP 179 tunneliliitännällä; IKE- tai ESP-sääntö ei kata sitä. Kolmas on peer, joka vastaa eri lähdeosoitteesta kuin se, joka on määritetty sen naapuriksi.
Peerin oma loki on ratkaiseva. Jos sen BGP-yhteenveto ei luettele naapuria kyseiselle osoitteelle, paketit eivät saavu paikalle ja pari tai polku on väärä. Jos naapuri on tilassa Active tai Connect, paketit saapuvat ja istunnon parametrit ovat ristiriidassa.
Tarkista siinä järjestyksessä kuin paketit kulkevat
Työskentele ulospäin: tunnelin tila, sitten reitittimen BGP-peer-tila, sitten peerin BGP-yhteenveto, sitten reitit. Jos kaksi ensimmäistä ovat kunnossa, lopeta Cloud VPN -puolen muokkaaminen ja työskentele peer-laitteella. Jos reititin ilmoittaa peerin olevan alhaalla eikä laitteessasi ole naapuria, pari on väärä tai BGP-portti on suodatettu. Paketin kaappaus peerin tunneliliitännällä ratkaisee asian yhdellä silmäyksellä, koska OPEN-paketit joko saapuvat sinne tai eivät koskaan saavu.
gcloud compute routers get-status ROUTER --region=REGION tulostaa peerin tilan sen käyttämän osoitteen viereen, ja se on täsmälleen se pari, joka sinun pitää vertailla.
Kun istunto muodostuu, varmista että opittu etuliite ilmestyy VPC:n reititystaulukkoon ja että yksi isäntä kummallakin puolella vastaa. Kirjaa sitten lopulliset parit tunnelien nimien viereen, jotta seuraava uudelleenrakennus alkaa tarkistetusta taulukosta eikä konsolin yhteenvedosta.