GCP HA VPN: BGP-sesio restas ĉe Waiting for peer, la interŝanĝo de la adresparo
Cloud VPN BGP-sesio blokita ĉe Waiting for peer kutime havas interŝanĝitajn la tunelan kaj la peer-adreson. Kontrolu la paron antaŭ ol vi rekonstruos ion ajn.
BGP-sesio, kiu neniam atingas Established sur Cloud VPN-tunelo, kutime ne estas enkursiga problemo. Ĝi estas dratada problemo: du adresoj, kiuj devas speguli unu la alian, estis entajpitaj en la malĝusta ordo, aŭ la paro de la unua tunelo estis reuzita en la dua. La tunelo mem povas esti tute sana dum la sesio restas ĉe Waiting for peer, ĉar IPsec kaj BGP estas apartaj intertraktadoj inter la samaj du finpunktoj. Decidu, kiun el la du estas difektita, antaŭ ol vi rekonstruos ion ajn.
Unu demando solvas la plej multajn kazojn: ĉu la peer-aparato entute vidas la adreson de Cloud Router?
Tunela stato kaj sesia stato estas malsamaj kontroloj
IKE kaj ESP venas unue. Se la tunelo ne estas establita, nenio ene de ĝi gravas kaj la diskuto pri la BGP-adreso estas tro frua. Legu la staton kaj la detalan staton de la tunelo, poste la BGP-peer-statun de la enkursigilo por tiu sama tunelo.
Tunelo, kiu estas supren dum ĝia BGP-peer estas malsupren, mallarĝigas la difekton al la sesio: peer-adreso, ASN aŭ TCP 179 alvenanta sur la interna adreso. Tunelo supren, sesio supren kaj ankoraŭ neniuj itineroj en la VPC estas tria kazo. Ŝanĝi adresojn ne helpos tie, ĉar la sesio jam funkcias kaj la prefikso simple ne estas anoncata aŭ ne preferata. Teni tiujn tri kazojn apartaj estas la plej granda parto de la laboro.
Ĉiu tunelo bezonas sian propran /30, kun ambaŭ finoj plenigitaj
Ĉiu HA VPN-tunelo ricevas link-local /30 el 169.254.0.0/16, kun unu adreso sur la Cloud Router-interfaco kaj la alia ĉe via peer. La peer-kampo devas nomi la malproksiman finon, neniam la propran adreson de la enkursigilo.
Du tuneloj signifas du interfacojn sur la Cloud Router, ĉiu kun malsama /30. Reuzi la paron de tunelo 0 en tunelo 1 estas la eraro, kiu aspektas ordema en resuma tabelo kaj mortas en la OPEN-paketo.
| 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 |
Legu la paron el la enkursigila rimedo prefere ol el la konzola resumo. La resumo listigas la peer-adreson en kolumno, kiun oni facile mislegas, kaj la ipRange de la interfaco plus la peerIpAddress de la peer devas priskribi kontraŭajn finojn de unu /30.
La interŝanĝo kutime okazas dum rekonstruo
Ĝuste dum tunelo estas rekonstruata la paroj kruciĝas. La peer-adreso de la malnova tunelo estas kopiita en la interfacan kampon de la nova, aŭ la nova sesio celas la peer de la antaŭa sesio. Ĉiel ajn la Cloud Router sendas OPEN-paketojn al adreso, kiu nun estas ĝi mem, aŭ al adreso sen tunelo malantaŭ ĝi.
Skribu la parojn antaŭ ol malfermi la konzolon: tunela nomo, interfaco, enkursigila adreso, peer-adreso, peer-ASN. Poste kreu ambaŭ tunelojn en unu paseo, por ke la dua ne estu plenigita el la restaĵoj de la unua.
Tri pliaj kaŭzoj, kial sesio atendas
La peer-ASN estas la unua: ĉiu flanko devas esti agordita kun la ASN de la alia flanko, kaj malkongruo atingas la peer sed neniam establiĝas. La dua estas la propra fajroŝirmilo de la peer, kiu devas permesi TCP 179 sur la tunela interfaco; regulo por IKE aŭ ESP ne kovras tion. La tria estas peer, kiu respondas el alia fonta adreso ol tiu agordita kiel ĝia najbaro.
La propra protokolo de la peer estas la distingilo. Se ĝia BGP-resumo listigas neniun najbaron por tiu adreso, la paketoj ne alvenas kaj la paro aŭ la vojo estas malĝustaj. Se la najbaro restas en Active aŭ Connect, la paketoj alvenas kaj la sesiaj parametroj malkongruas.
Kontrolu laŭ la ordo, en kiu vojaĝas la paketoj
Laboru eksteren: tunela stato, poste la BGP-peer-stato de la enkursigilo, poste la BGP-resumo de la peer, poste la itineroj. Se la unuaj du estas sanaj, ĉesu redakti la Cloud VPN-flankon kaj laboru sur la peer-aparato. Se la enkursigilo raportas la peer kiel malsupren kaj via aparato havas neniun najbaron, la paro estas malĝusta aŭ la BGP-pordo estas filtrita. Paketkaptado sur la tunela interfaco de la peer solvas ĝin per unu rigardo, ĉar OPEN-paketoj aŭ alvenas tien aŭ neniam alvenas.
gcloud compute routers get-status ROUTER --region=REGION presas la peer-statun apud la adreso, kiun ĝi uzas, kaj tio estas ĝuste la paro, kiun vi devas kompari.
Post kiam la sesio establiĝos, konfirmu, ke la lernita prefikso aperas en la itinera tabelo de la VPC kaj ke po unu gastiganto ambaŭflanke respondas. Poste notu la finajn parojn apud la tunelaj nomoj, por ke la sekva rekonstruo komenciĝu de kontrolita tabelo anstataŭ de la konzola resumo.