BGP-seanss, mis ei jõua Cloud VPN tunnelil kunagi olekusse Established, ei ole tavaliselt marsruutimise probleem. See on ühenduse probleem: kaks aadressi, mis peavad üksteist peegeldama, sisestati vales järjekorras või kasutati esimese tunneli paari teise jaoks uuesti. Tunnel ise võib olla täiesti terve, samal ajal kui seanss seisab olekus Waiting for peer, sest IPsec ja BGP on samade kahe lõpp-punkti vahel eraldi läbirääkimised. Otsustage, kumb neist kahest on katki, enne kui midagi ümber ehitate.

Üks küsimus lahendab enamiku juhtudest: kas peer-seade näeb üldse Cloud Routeri aadressi?

Tunneli olek ja seansi olek on erinevad kontrollid

Kõigepealt tulevad IKE ja ESP. Kui tunnel ei ole loodud, ei loe selle sees miski ja BGP-aadressi arutelu on ennatlik. Lugege tunneli olekut ja üksikasjalikku olekut, seejärel ruuteri BGP-peer-olekut sama tunneli jaoks.

Tunnel, mis on üleval, samal ajal kui selle BGP-peer on maas, kitsendab vea seansile: peer-aadress, ASN või TCP 179, mis saabub sisaadressile. Tunnel üleval, seanss üleval ja endiselt mitte ühtegi marsruuti VPC-s on kolmas juhtum. Aadresside muutmine ei aita seal, sest seanss juba töötab ja prefiksit lihtsalt ei kuulutata või ei eelistata. Nende kolme juhtumi eristamine on suurem osa tööst.

Iga tunnel vajab oma /30, mõlemad otsad täidetud

Iga HA VPN tunnel saab link-local /30 vahemikust 169.254.0.0/16, üks aadress Cloud Routeri liidesel ja teine teie peeril. Peer-väli peab nimetama kaugema otsa, mitte kunagi ruuteri enda aadressi.

Kaks tunnelit tähendavad kahte liidest Cloud Routeril, kummalgi erinev /30. Tunneli 0 paari uuesti kasutamine tunnelil 1 on viga, mis näeb kokkuvõtvas tabelis korralik välja ja sureb OPEN-paketis.

TunnelRouter interfacePeer addressWhat a swap produces
tunnel 0169.254.1.1/30169.254.1.2OPEN sent to itself or to nothing; session waits
tunnel 1169.254.1.5/30169.254.1.6same failure on the second session
bothone pair reusedone address reusedone session up, the other never leaves waiting

Lugege paari ruuteri ressursist, mitte konsooli kokkuvõttest. Kokkuvõte loetleb peer-aadressi veerus, mida on lihtne valesti lugeda, ja liidese ipRange koos peeri peerIpAddress-iga peavad kirjeldama ühe /30 vastassuunalisi otsi.

Vahetus toimub tavaliselt ümberehituse ajal

Just tunneli ümberehitamisel lähevad paarid risti. Vana tunneli peer-aadress kopeeritakse uue tunneli liidese väljale või suunatakse uus seanss eelmise seansi peerile. Mõlemal juhul saadab Cloud Router OPEN-pakette aadressile, mis on nüüd tema ise, või aadressile, mille taga tunnel puudub.

Kirjutage paarid enne konsooli avamist üles: tunneli nimi, liides, ruuteri aadress, peer-aadress, peer-ASN. Seejärel looge mõlemad tunnelid ühe käiguga, et teist ei täidetaks esimese jääkidest.

Kolm muud põhjust, miks seanss ootab

Peer-ASN on esimene: kumbki pool tuleb seadistada teise poole ASN-iga ja erinevus jõuab peerini, kuid ei loo kunagi ühendust. Teine on peeri enda tulemüür, mis peab lubama TCP 179 tunneliliidesel; IKE- või ESP-reegel seda ei kata. Kolmas on peer, mis vastab teisest lähteaadressist kui see, mis on seadistatud tema naabriks.

Peeri enda logi on määrav. Kui selle BGP-kokkuvõte ei loetle selle aadressi jaoks ühtegi naabrit, ei saabu paketid ja paar või tee on vale. Kui naaber seisab olekus Active või Connect, saabuvad paketid ja seansi parameetrid ei klapi.

Kontrollige selles järjekorras, kuidas paketid liiguvad

Töötage väljapoole: tunneli olek, seejärel ruuteri BGP-peer-olek, seejärel peeri BGP-kokkuvõte, seejärel marsruudid. Kui kaks esimest on terved, lõpetage Cloud VPNi poole muutmine ja töötage peer-seadmel. Kui ruuter teatab peeri maas olevaks ja teie seadmel pole ühtegi naabrit, on paar vale või BGP-port on filtreeritud. Paketi püüdmine peeri tunneliliidesel lahendab selle ühe pilguga, sest OPEN-paketid kas saabuvad sinna või ei saabu kunagi.

gcloud compute routers get-status ROUTER --region=REGION trükib peeri oleku selle kasutatava aadressi kõrvale ja see on täpselt see paar, mida peate võrdlema.

Kui seanss on loodud, kinnitage, et õpitud prefiks ilmub VPC marsruuditabelisse ja et mõlemal pool vastab üks host. Seejärel kirjutage lõplikud paarid tunnelinimede kõrvale, et järgmine ümberehitus algaks kontrollitud tabelist, mitte konsooli kokkuvõttest.

Seotud artiklid