GCP HA VPN: BGP-sesje hinget op Waiting for peer, de omwikseling fan it adrespear
In Cloud VPN BGP-sesje dy't op Waiting for peer hinget, hat meastentiids it tunnel- en peer-adres omwiksele. Kontrolearje it pear foardat jo wat opnij bouwe.
In BGP-sesje dy't op in Cloud VPN-tunnel nea Established berikt, is meastentiids gjin routingprobleem. It is in bedradingsprobleem: twa adressen dy't elkoar spegelje moatte, binne yn 'e ferkearde folchoarder ynfierd, of it pear fan 'e earste tunnel is op 'e twadde wer brûkt. De tunnel sels kin folslein sûn wêze wylst de sesje op Waiting for peer stiet, want IPsec en BGP binne aparte ûnderhannelings tusken deselde twa einpunten. Bepaal hokker fan 'e twa stikken is foardat jo wat opnij bouwe.
Ien fraach beslist de measte gefallen: sjocht it peer-apparaat it adres fan 'e Cloud Router wol?
Tunnelstatus en sesjestatus binne ferskillende kontrôles
IKE en ESP komme earst. As de tunnel net oprjochte is, betsjutet neat derbinnen wat en is de BGP-adresdiskúsje foartidich. Lês de status en de detaillearre status fan 'e tunnel, en dêrnei de BGP-peerstatus fan 'e router foar deselde tunnel.
In tunnel dy't omheech is wylst syn BGP-peer omleech is, beheint de flater ta de sesje: peer-adres, ASN of TCP 179 dat op it ynderlike adres oankomt. In tunnel omheech, in sesje omheech en noch gjin rûtes yn 'e VPC is in tredde gefal. Adressen feroarje sil dêr net helpe, want de sesje wurket al en it foarheaksel wurdt gewoan net oankundige of net foarkarre. Dy trije gefallen apart hâlde is it grutste part fan it wurk.
Elke tunnel hat syn eigen /30 nedich, mei beide einen ynfold
Elke HA VPN-tunnel krijt in link-local /30 út 169.254.0.0/16, mei ien adres op 'e Cloud Router-ynterface en de oare op jo peer. It peer-fjild moat de fiere ein neame, nea it eigen adres fan 'e router.
Twa tunnels betsjutte twa ynterfaces op 'e Cloud Router, elk mei in oar /30. It pear fan tunnel 0 wer brûke op tunnel 1 is de flater dy't der yn in gearfettingstabel kreas útsjocht en yn it OPEN-pakket stjert.
| 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 |
Lês it pear út 'e router-boarne yn stee fan út 'e konsolgearfetting. De gearfetting listet it peer-adres yn in kolom dy't maklik ferkeard lêzen wurdt, en de ipRange fan 'e ynterface plus de peerIpAddress fan 'e peer moatte tsjinoerstelde einen fan ien /30 beskreauwe.
De omwikseling bart meastentiids by in weropbou
It is by it werbouwen fan in tunnel dat pearen kruse. It peer-adres fan 'e âlde tunnel wurdt kopiearre yn it ynterfacefjild fan 'e nije, of de nije sesje wiist nei de peer fan 'e foarige sesje. Hoe dan ek stjoert de Cloud Router OPEN-pakketten nei in adres dat no himsels is of nei in adres sûnder tunnel efter.
Skriuw de pearen op foardat jo de konsôle iepenje: tunnelnamme, ynterface, routeradres, peer-adres, peer-ASN. Meitsje dêrnei beide tunnels yn ien pass, sadat de twadde net út 'e oerbliuwsels fan 'e earste folle wurdt.
Trije oare redenen wêrom't in sesje wachtet
De peer-ASN is de earste: elke kant moat konfigurearre wêze mei de ASN fan 'e oare kant, en in misferstân berikt de peer mar rjochtet nea op. De twadde is de eigen firewall fan 'e peer, dy't TCP 179 op 'e tunnel-ynterface tastean moat; in IKE- of ESP-regel dekt dat net. De tredde is in peer dy't antwurdet fan in oar boarne-adres as dat fan syn neiste.
It eigen log fan 'e peer is de ûnderskieder. As syn BGP-gearfetting gjin neiste foar dat adres listet, komme pakketten net oan en is it pear of it paad ferkeard. As de neiste yn Active of Connect stiet, komme pakketten oan en binne de sesjeparameters ûnearich.
Kontrolearje yn 'e folchoarder wêryn't de pakketten reizgje
Wurkje nei bûten: tunnelstatus, dan BGP-peerstatus fan 'e router, dan de BGP-gearfetting fan 'e peer, dan de rûtes. As de earste twa sûn binne, stopje mei it bewurkjen fan 'e Cloud VPN-kant en wurkje op it peer-apparaat. As de router de peer as omleech rapportearret en jo apparaat hat gjin neiste, dan is it pear ferkeard of de BGP-poarte wurdt filtere. In pakketopname op 'e tunnel-ynterface fan 'e peer beslist it yn ien eachopslach, want OPEN-pakketten komme dêr oan of komme der nea.
gcloud compute routers get-status ROUTER --region=REGION prints de peerstatus njonken it adres dat it brûkt, en dat is krekt it pear dat jo fergelykje moatte.
Sadree't de sesje oprjochte is, befêstigje dat it learde foarheaksel yn 'e VPC-rûtetabel ferskynt en dat ien host oan elke kant antwurdet. Skriuw dan de definitive pearen njonken de tunnelnammen op, sadat de folgjende weropbou fan in bewiisd tabel begjint en net fan 'e konsolgearfetting.