Pilvi-VPN tarvitsee BGP:n: miksi muut reititysprotokollat epäonnistuvat

IPsec-turva-assosiaatio on pystyssä, tunnelin laskurit liikkuvat ja liikenne pilven etuliitteeseen katoaa. Operaattori yrittää silloin ottaa OSPF:n käyttöön asiakkaan reitittimessä odottaen, että naapuri muodostuu, eikä mitään tapahdu. Tunneli ei ollut koskaan puuttuva pala: hallinnoitu pilvi-VPN tarjoaa määritellyn reitityssopimuksen, ja suurilla alustoilla se sopimus on BGP. Ennen kuin istunto on olemassa ja etuliite hyväksytään, tunneli on vain salattu polku, jonka takana ei ole kohteita.

Tunneli on pystyssä ja reitti puuttuu

Vaiheen 1 ja vaiheen 2 valmistuminen todistaa, että osapuolet sopivat suojauksesta, ei sitä, että kumpikaan tietäisi, mihin liikenne lähetetään. Ne ovat erillisiä tilakoneita, joilla on erilliset vikatilat.

Esitä kolme kysymystä järjestyksessä: mainostettiinko etuliite, hyväksyikö naapuri sen ja asennettiinko se edelleenlähetystä varten? Mainostettu ja suodatettu etuliite on käytäntöongelma. Etuliite, jota ei koskaan mainostettu, on istunto- tai kokoonpano-ongelma. Etuliite, joka hyväksyttiin mutta jota ei asennettu, on reitinvalintaongelma, ja jokainen vastaus osoittaa kokoonpanon eri osaan.

Mitä palveluntarjoaja todella antaa sinulle

Hallinnoitu VPN-yhdyskäytävä ei ole rajoittamaton reititin. Palveluntarjoaja antaa yhdyskäytävän, jossa on tuetut naapuriosoitteet, autonomisen järjestelmän asetus, etuliiterajoitukset ja määritelty vikakäyttäytyminen. Se pinta on tuote.

Google Cloud dokumentoi dynaamisen BGP-reitityksen HA VPN:lle, jossa Cloud Router oppii naapurien reitit ja toimittaa kelvolliset mukautetut dynaamiset reitit VPC:hen. AWS Site-to-Site VPN dokumentoi valinnan staattisen ja dynaamisen reitityksen välillä ja kuvaa BGP:n elossaolotarkistukset hyödyllisiksi tunnelin siirtymässä ja tukee samalla terveystarkistuksia laitteille, joissa ei ole BGP:tä. Kummankaan alustan käyttäytymistä ei pitäisi päätellä toisen tuotenimestä.

Käytännön seuraus on, että valitset ensin hallinnoidun tilan ja luet sitten tuetut säätimet. Suunnittelu, joka olettaa naapuruustyypin, jota palvelu ei tarjoa, ei ole kokoonpano-ongelma, joka ratkaistaan asiakkaan reitittimessä.

Tunnelin suojaus ja tavoitettavuus ovat erillisiä tehtäviä

IPsec suojaa liikenteen, joka on valittu tunneliin. BGP toimittaa tavoitettavuustiedon, joka tekee etuliitteestä kelvollisen. Toimiva tunneli ei todista, että odotettu etuliite mainostettiin, hyväksyttiin tai asennettiin.

Kuvittele sivukonttori, joka mainostaa 10.42.0.0/16:tä kahden kelvollisen tunnelipolun kautta. Poista yksi käyttökelpoinen polku, ja reitinvalinta voi muuttua ilman, että kukaan muokkaa kunkin työkuorman reittiä. Havaitseminen, reitinvalinta ja sovelluksen palautuminen eivät ole välittömiä eivätkä samanlaisia eri käyttöönotoissa, joten siirtymätestin on tarkkailtava koko jaksoa eikä ensimmäistä läpi menevää pakettia.

Kun pilven etuliite ei ole tavoitettavissa, tarkista istunnon tila ja opitut reitit ennen kuin kosket salaukseen. Pystyssä oleva SA, jonka takana ei ole reittiä, on tämän oireen yleisin muoto.

Missä OSPF-oletukset murtuvat

OSPF, IS-IS tai muu protokolla IPsec-tunnelin sisällä on täysin mahdollista itse hallinnoimassasi laitteessa, jossa omistat molemmat päät ja edelleenlähetyssuunnittelun. Tämä tosiasia ei kerro mitään hallinnoidusta palvelusta, joka tarjoaa dynaamisen reitityksen tilana vain BGP:n.

Jos ehdotettu suunnittelu tarvitsee naapuruuden, jota palvelu ei tue, muuta arkkitehtuuria tarkoituksella. Vaihtoehtoja ovat itse hallinnoitu laite VPC:ssä, staattinen reititys siellä missä palvelu tukee sitä, tai eri yhteys tuote. Protokollan määrittäminen vain asiakkaan reitittimessä ei voi lisätä pilven puoleista naapuria, jota ei ole olemassa, eikä se saa etuliitettä ilmestymään.

Älä siirrä yhden toimittajan vastausta toisen toimittajan yhdyskäytävään. Samat sanat, kuten dynaaminen reititys tai tunnelin siirtymä, voivat kuvata eri mekanismeja ja eri rajoja.

Lue palvelun vaatimus ja suunnittele vasta sitten

Kirjoita ennen ensimmäistä kokoonpanoriviä naapurien osoitteet, autonomisten järjestelmien numerot, etuliitteet, jotka mainostat ja hyväksyt, reittirajat ja odotettu käyttäytyminen, kun tunneli epäonnistuu. Ne viisi kohtaa ovat sopimus, jonka mukaan suunnittelet.

Tarkista sitten samassa järjestyksessä: istunto muodostettu, etuliite vastaanotettu, reitti läsnä VPC:n reititystaulukossa ja todellinen virta palveluosoitteeseen. Toista pakotetun siirtymän jälkeen, koska uudelleen muodostuva istunto voi palata eri reittijoukon kanssa. Jos suunnittelu riippuu alle sekunnin konvergenssista, mittaa se sen sijaan että olettaisit sen.

Pidä palvelusopimus muutoskirjauksen kanssa. Kun joku myöhemmin kysyy, miksi tunneli ei voi ajaa OSPF:ää, vastaus on tuoteraja, ei protokollarajoitus, ja kirjauksen pitäisi sanoa niin.