Debesų VPN reikia BGP: kodėl kiti maršrutizavimo protokolai nepavyksta

IPsec saugos asociacija veikia, tunelio skaitikliai juda, o srautas į debesijos prefiksą išnyksta. Tada operatorius bando įjungti OSPF kliento maršrutizatoriuje, tikėdamasis, kad susidarys kaimynas, ir nieko neįvyksta. Tunelis niekada nebuvo trūkstama dalis: valdoma debesų VPN pateikia apibrėžtą maršrutizavimo sutartį, o didelėse platformose ta sutartis yra BGP. Kol nėra sesijos ir nepriimtas prefiksas, tunelis tėra šifruotas kelias be paskirties vietų už jo.

Tunelis veikia, o maršruto nėra

1 ir 2 fazių užbaigimas įrodo, kad šalys sutaria dėl apsaugos, o ne kad kuri nors pusė žino, kur siųsti srautą. Tai atskiros būsenos mašinos su atskirais gedimo režimais.

Užduokite tris klausimus iš eilės: ar prefiksas buvo paskelbtas, ar kaimynas jį priėmė ir ar jis buvo įdiegtas peradresavimui? Paskelbtas ir filtruotas prefiksas yra politikos problema. Niekada nepaskelbtas prefiksas yra sesijos arba konfigūracijos problema. Priimtas, bet neįdiegtas prefiksas yra maršruto pasirinkimo problema, ir kiekvienas atsakymas nurodo skirtingą konfigūracijos dalį.

Ką tiekėjas iš tikrųjų duoda

Valdomas VPN šliuzas nėra neribotas maršrutizatorius. Tiekėjas duoda šliuzą su palaikomais kaimynų adresais, autonominės sistemos nuostata, prefiksų limitais ir apibrėžtu gedimo elgesiu. Tas paviršius ir yra produktas.

Google Cloud dokumentuoja dinaminį BGP maršrutizavimą HA VPN, kai Cloud Router mokosi kaimynų maršrutų ir tiekia tinkamus pasirinktinius dinaminius maršrutus į VPC. AWS Site-to-Site VPN dokumentuoja pasirinkimą tarp statinio ir dinaminio maršrutizavimo ir aprašo BGP gyvybingumo patikras kaip naudingas tunelio perjungimui, taip pat palaikydamas sveikatos patikras įrenginiams be BGP. Nė vienos platformos elgesio negalima spręsti iš kitos produkto pavadinimo.

Praktinė pasekmė: pirmiausia pasirenkate valdomą režimą, tada skaitote palaikomus parametrus. Projektas, kuris daro prielaidą apie kaimynystės tipą, kurio paslauga nesiūlo, nėra konfigūracijos problema, kurią reikia spręsti kliento maršrutizatoriuje.

Tunelio apsauga ir pasiekiamumas yra atskiri darbai

IPsec apsaugo srautą, pasirinktą tuneliui. BGP tiekia pasiekiamumo informaciją, kuri daro prefiksą tinkamą. Veikiantis tunelis neįrodo, kad laukiamas prefiksas buvo paskelbtas, priimtas ar įdiegtas.

Įsivaizduokite filialą, kuris skelbia 10.42.0.0/16 per du tinkamus tunelio kelius. Pašalinkite vieną tinkamą kelią, ir maršruto pasirinkimas gali pasikeisti niekam neredaguojant kiekvienos darbo apkrovos maršruto. Aptikimas, maršruto pasirinkimas ir programos atkūrimas nėra momentiniai ir nėra vienodi skirtinguose diegimuose, todėl perjungimo testas turi stebėti visą seką, o ne pirmą praėjusį paketą.

Kai debesijos prefiksas nepasiekiamas, patikrinkite sesijos būseną ir išmoktus maršrutus prieš liesdami kriptografiją. Veikianti SA be maršruto už jos yra labiausiai paplitusi šio simptomo forma.

Kur lūžta OSPF prielaidos

OSPF, IS-IS ar kitas protokolas IPsec tunelio viduje yra visiškai įmanomas savarankiškai valdomame įrenginyje, kai abu galai ir peradresavimo projektas priklauso jums. Šis faktas nieko nesako apie valdomą paslaugą, kuri kaip dinaminio maršrutizavimo režimą siūlo tik BGP.

Jei siūlomas projektas reikalauja kaimynystės, kurios paslauga nepalaiko, sąmoningai pakeiskite architektūrą. Parinktys apima savarankiškai valdomą įrenginį VPC, statinį maršrutizavimą ten, kur paslauga jį palaiko, arba kitą ryšio produktą. Protokolo konfigūravimas tik kliento maršrutizatoriuje negali pridėti debesijos pusėje neegzistuojančio kaimyno ir neprivers prefikso pasirodyti.

Neperkelkite vieno tiekėjo atsakymo į kito tiekėjo šliuzą. Tie patys žodžiai, pavyzdžiui, dinaminis maršrutizavimas arba tunelio perjungimas, gali apibūdinti skirtingus mechanizmus ir skirtingas ribas.

Perskaitykite paslaugos reikalavimą ir tada projektuokite

Prieš pirmąją konfigūracijos eilutę surašykite kaimynų adresus, autonominių sistemų numerius, prefiksus, kuriuos skelbsite ir priimsite, maršrutų limitus ir laukiamą elgesį, kai tunelis sugenda. Tie penki punktai yra sutartis, pagal kurią projektuojate.

Tada patikrinkite ta pačia tvarka: sesija užmegzta, prefiksas gautas, maršrutas yra VPC maršrutų lentelėje ir realus srautas į paslaugos adresą. Pakartokite po priverstinio perjungimo, nes atnaujinta sesija gali grįžti su kitu maršrutų rinkiniu. Jei projektas priklauso nuo konvergencijos per mažiau nei sekundę, išmatuokite ją, o ne darykite prielaidą.

Saugokite paslaugos sutartį kartu su pakeitimų įrašu. Kai vėliau kas nors paklaus, kodėl tunelis negali vykdyti OSPF, atsakymas yra produkto riba, o ne protokolo apribojimas, ir įrašas turėtų tai pasakyti.