Kodėl BGP per VPN nevaldo jūsų pagrindinio sluoksnio kelio

Dvi vietos susieja BGP per IPsec tunelį, išmoksta viena kitos prefiksus, ir diagrama pervadinama į kelio valdymą. Būtent ši etiketė yra painiavos pradžia. Sesija tikrai keičiasi pasiekiamumu ir tikrai taiko politiką, bet ji neturi žodžio, kuris tiekėjas, kabelis ar maršrutizatorius neša užšifruotus paketus. Mačiau komandą, kuri perstatė veikiantį tunelį, nes tikėjosi, kad BGP maršruto pakeitimas perkels srautą į kitą šviesolaidinį kelią, kurio sesija niekada negalėjo paveikti.

Ką žmonės mano, kad sesija nusiperka

Didžioji dalis lūkesčio kyla iš to, kaip maršruto pakeitimas atrodo laboratorijoje. Skelbiate prefiksą per tunelį, tolimoji pusė jį įdiegia, ir srautas juda. Ta pati seka vyksta maršrutizatoriuje, kuris tikrai turi srauto inžinerijos svirtis, todėl abu sumaišomi. Laboratorijoje abi vietos paprastai dalijasi viena prieigos linija, ir būtent todėl skirtumas ten niekada nepasireiškia.

BGP yra pasiekiamumo protokolas. Jis pasako partneriui, kad galite pristatyti paketus prefiksui, ir leidžia kiekvienai pusei surikiuoti gautus pasiūlymus. Tai tikrai naudinga per tunelį: prefiksai atsiranda ir išnyksta vietoms ateinant ir išeinant, ir galite atsisakyti diapazono nerašydami statinio maršruto kiekviename krašto įrenginyje. Ko jis nedaro, tai nepadaro tiekėjo maršrutizatorių jūsų kontroliuojamais.

Pagrindinis sluoksnis neša išorinę antraštę. Jūsų tunelio galinis taškas siunčia užšifruotus paketus partnerio adresu, ir tinklas tarp tų dviejų adresų persiunčia juos maršrutais, kuriuos įdiegė jo operatoriai. Niekas BGP sesijoje nekeičia to sprendimo, nebent tas pats tiekėjas siūlo palaikomą paslaugą, kuri tai daro.

Ką sesija iš tikrųjų neša

BGP kalbėtojas atidaro TCP ryšį į savo partnerio 179 prievadą, naudodamas RFC 4271 apibrėžtus pranešimų formatus ir kelio atributus. Kai partnerio adresas yra tunelio viduje, tunelis turi būti pakeltas ir adresas pasiekiamas, kol sesija dar gali prasidėti. Baigtas IKE mainas nėra BGP kaimynas. Maršrutais pagrįstos IPsec implementacijos praleidžia srautą tik tada, kai egzistuoja atitinkamas tunelio maršrutas, o politikos pagrįsta turi turėti partnerio adresą apsaugotame selektoriuje. Apvertus tai gaunama klasikinė būsena, kai tunelis žalias, o sesija stovi be darbo.

Kai sesija pakelta, politika nusprendžia, kas ją kerta. Prefiksų sąrašai, AS-kelio filtrai, didžiausia prefiksų riba ir aiškus sprendimas dėl numatytųjų maršrutų yra minimumas, ir jie galioja abiem kryptimis. Partneris, kuris priima viską, ką gauna, gali duoti jums numatytąjį maršrutą, kuris tyliai pakeičia vietinę interneto prieigą. Abi kryptys turi turėti atskirus sąrašus, nes tai, ką priimate iš partnerio, ir tai, ką jam skelbiate, yra skirtingi sprendimai.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Toliau kandžioja MTU. Inkapsuliavimas sumažina naudingąją apkrovą, todėl didelis atnaujinimas gali sustabdyti sesiją, kuri atrodo visiškai nusistovėjusi: partneris lieka pakeltas, prefiksai niekada neatkeliauja, ir nieko akivaizdaus nepatenka į žurnalą. Apribokite TCP MSS tunelio sąsajoje arba nustatykite tunelio MTU su vietos perdavimo išlaidoms, prieš kaltindami filtrus.

Kur vis dar eina išoriniai paketai

Užšifruoti paketai iš vienos vietos į kitą išeina tuo keliu, kurį vietinis maršrutizatorius pasirenka partnerio viešajam adresui. Jei abi vietos perka tranzitą iš to paties tiekėjo, kerta tą pačią metro įstaigą arba viena pusė yra už operatoriaus lygio NAT, tunelis tiekėjo gedimą išgyvena tik atsitiktinai. Tunelių piktogramų skaičiavimas stebėjimo įrankyje nieko apie tai nesako.

Maršruto pasirinkimas ir persiuntimo įdiegimas taip pat yra atskiri įvykiai. Prefiksas gali stovėti BGP lentelėje kaip geriausias ir vis tiek trūkti persiuntimo lentelėje, nes kitas šuolis yra neišsprendžiamas arba laimi konkretesnis maršrutas. Kai kas nors praneša, kad BGP išmoko prefiksą, bet srautas neteka, naudingas klausimas yra, ar jis įdiegtas ir į kurį kitą šuolį jis rodo.

Sąžiningas atsakymas dizaino apžvalgai yra bendrų priklausomybių sąrašas: prieigos grandinė, aukštutinis tiekėjas, įstaiga ir bet kuris būseną išlaikantis įrenginys grįžimo kelyje. Sesija per tunelį negali pašalinti priklausomybės, virš kurios ji nesėdi.

Trys sprendimai, kuriuos verta atskirti

Kai dizainas tai sumaišo, kiekvienas gedimo pokalbis eina ratu. Pirmiausia atskirkite juos popieriuje, tada kiekvieną priskirkite įrenginiui, kuris jį iš tikrųjų vykdo.

Kiekviena eilutė turi skirtingą savininką. Pirmoji yra derybos, antroji yra konfigūracija jūsų įrenginiuose, trečioji daugiausia yra kažkieno kito tinklas. Pakeitimo prašymą, kuriame nurodyta eilutė, kurios jis liečia, patvirtinti daug lengviau nei tą, kuriame sakoma BGP problema.

Gedimų režimai, kuriuos verta planuoti

Partnerio suvestinio maršruto priėmimas yra labiausiai paplitusi sau padaryta žaizda. Kažkas skelbia trumpą agregatą, kad supaprastintų mainus, tolimoji pusė jį priima, ir srautas diapazonams, kurie nėra už tunelio, seka tunelį ir miršta. Filtruokite pagal tiksliai laukiamus prefiksus arba naudokite prefiksų sąrašą su teisingomis ribomis, ir niekada nepriimkite pliko agregato, nes jis leidžia sesijai atrodyti tvarkingai.

Atsaukimo laikas yra antrasis. Aptikimas priklauso nuo laikymo laikmačių, BFD, jei jį įjungėte, tunelio mirusio partnerio aptikimo ir nuo to, kaip greitai tolimoji pusė nustoja skelbti. Esamos sesijos yra atskira problema: naujas maršrutas gali atkurti naujus ryšius, o nusistovėjusios TCP sesijos toliau naudoja pasenusius adresus, ir būseną išlaikantys ugniasieniai ar NAT kelyje gali laikyti įrašus, kurie nebeatitinka. Įdėkite programos atkūrimą į priėmimo kriterijus, o ne manykite, kad maršruto pakeitimas viską sutvarko.

Trečiasis yra grįžimo kelio asimetrija. Srautas gali atvykti per tunelį ir grįžti tiekėjo linija, kuri niekada nebuvo skirta jam nešti, o tai pasireiškia kaip vienkryptis garsas, nepavykę rankos paspaudimai ar ugniasienė, kuri meta atsakymus. Tikrinkite abi kryptis atskirai.

Ką įrašyti į sutartį ir kaip tai patikrinti

Paprašykite leidžiamų prefiksų raštu: kas turi teisę generuoti kiekvieną diapazoną, ar leidžiamas numatytasis maršrutas ir kokias adresų šeimas palaiko tunelio paslauga. RFC 8212 pavertė aiškią importo ir eksporto politiką eBGP lūkesčiu implementacijose, kurios jos laikosi, todėl partneris, kuris vis dar remiasi numanomu viską priimti elgesiu, vertas klausimo.

Tada tikrinkite iš įrenginio, o ne iš diagramos. Naudingos komandos FRR tipo maršrutizatoriuose:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Pridėkite du stebėjimus, kurių maršrutų lentelė jums negali duoti. Fiksuokite išorinėje sąsajoje, kad patvirtintumėte, į kurį adresą inkapsuliuoti paketai iš tikrųjų taiko, pavyzdžiui tcpdump -ni eth0 udp port 51820 WireGuard tuneliui arba ESP filtras IPsec. Tada sekite link partnerio viešojo adreso ir palyginkite šuolius su pėdsaku tunelio viduje; jei abu seka tą pačią tiekėjo grandinę, jūsų pertekliškumas gyvena maršrutų politikoje, o ne tinkle.

Galiausiai sąmoningai išbandykite atšaukimą. Nuleiskite tunelį techninės priežiūros lange, užfiksuokite, kiek ilgai prefiksas lieka įdiegtas, kas atsitinka esamoms sesijoms ir ar tolimoji pusė grįžta prie maršruto, kurį tikrai priimtumėte. Šis pratimas apie dizainą pasako daugiau nei bet kokia diagrama.

Maršrutas nėra leidimas. Prefiksai, dėl kurių sutariate keistis, nieko nesako apie tai, kurie vartotojai gali pasiekti kurią paslaugą už tunelio, todėl palikite autentifikavimą, leidžiamas paslaugas ir pagrindinio kompiuterio ugniasienes tiksliai ten, kur jos buvo. Pasiekiamas partneris taip pat nėra leidimas neribotam tranzitui ar savavališkų adresų generavimui, ir tokio pobūdžio įgaliojimas priklauso sutarčiai kaip komercinis klausimas, o ne BGP politikos eilutei.

• Įvardykite prefiksus, kuriuos kiekviena pusė gali generuoti, ir tuos, kurių ji niekada neturi priimti.
• Apribokite MSS tunele ir patvirtinkite, kad dideli atnaujinimai tikrai atvyksta.
• Išvardykite bendras pagrindinio sluoksnio priklausomybes, o ne tunelių skaičių.
• Išmatuokite tikrą atšaukimą ir pažymėkite, ką daro programa.