Miks BGP VPN-i kohal ei kontrolli sinu aluskihi teed
BGP VPN-i kohal vahetab kättesaadavust ja rakendab marsruudipoliitikat, kuid aluskiht valib ikkagi välise tee. Mida sessioon tegelikult kontrollib.
Kaks saiti peerivad BGP-d üle IPsec-tunneli, õpivad teineteise prefiksid, ja diagramm nimetatakse ümber teekontrolliks. Just see silt on segaduse algus. Sessioon vahetab tõesti kättesaadavust ja rakendab tõesti poliitikat, kuid tal ei ole sõnaõigust, milline teenusepakkuja, kaabel või ruuter kannab krüpteeritud pakette. Olen näinud meeskonda töötavat tunnelit ümber ehitamas, sest nad ootasid, et BGP marsruudi muudatus viib liikluse teisele fiiberteele, mida sessioon ei oleks kunagi suutnud mõjutada.
Mida inimesed arvavad, et sessioon ostab
Suurem osa ootusest tuleb sellest, kuidas marsruudi muudatus laboris välja näeb. Kuulutad prefiksi üle tunneli, kaugem pool paigaldab selle ja liiklus liigub. Sama jada juhtub ruuteril, millel on tõesti liikluse insenerimise hoovad, seega aetakse need kaks segi. Laboris jagavad mõlemad saidid tavaliselt ühte juurdepääsuliini, ja täpselt seetõttu ei ilmne erinevus seal kunagi.
BGP on kättesaadavuse protokoll. See ütleb peerile, et suudad prefiksi jaoks pakette kohale toimetada, ja laseb kummalgi poolel saadud pakkumisi järjestada. See on üle tunneli tõeliselt kasulik: prefiksid ilmuvad ja kaovad, kui saidid tulevad ja lähevad, ja saad vahemikust keelduda, kirjutamata igasse servaseadmesse staatilist marsruuti. Mida see ei tee, on teenusepakkuja ruuterite viimine sinu kontrolli alla.
Aluskiht kannab välist päist. Sinu tunneli lõpp-punkt saadab krüpteeritud paketid peeri aadressile, ja nende kahe aadressi vaheline võrk edastab need marsruutide järgi, mille selle operaatorid on paigaldanud. Miski BGP sessioonis ei muuda seda otsust, kui just sama teenusepakkuja ei paku toetatud teenust, mis seda teeb.
Mida sessioon tegelikult kannab
BGP kõneleja avab TCP-ühenduse peeri pordile 179, kasutades sõnumivorminguid ja teeatribuute, mis on määratletud RFC 4271-s. Kui peeri aadress asub tunneli sees, peab tunnel olema üleval ja see aadress kättesaadav, enne kui sessioon üldse alata saab. Lõpetatud IKE-vahetus ei ole BGP-naaber. Marsruudipõhised IPsec-teostused lasevad liiklust läbi alles siis, kui sobiv tunnelimarsruut on olemas, ja poliitikapõhine vajab peeri aadressi kaitstud valija sees. Selle tagurpidi tegemine tekitab klassikalise olukorra, kus tunnel on roheline ja sessioon seisab jõude.
Kui sessioon on üleval, otsustab poliitika, mis seda läbib. Prefiksite loendid, AS-tee filtrid, maksimaalsete prefiksite ülempiir ja selgesõnaline otsus vaikemarsruutide kohta on miinimum, ja need kehtivad mõlemas suunas. Peer, kes võtab vastu kõik, mis saabub, võib anda sulle vaikemarsruudi, mis asendab vaikselt kohaliku internetiühenduse. Kaks suunda vajavad eraldi loendeid, sest see, mida peerilt vastu võtad, ja see, mida talle kuulutad, on erinevad otsused.
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
Järgmisena hammustab MTU. Kapseldamine vähendab kasulikku koormust, nii et suur uuendus võib seisma jätta sessiooni, mis näib täiesti püstitatud: peer jääb üles, prefiksid ei saabu kunagi ja logisse ei satu midagi ilmset. Piira TCP MSS tunneliliidesel või sea tunnelile MTU, milles on üldkulule ruumi, enne kui filtreid süüdistad.
Kuhu välised paketid ikkagi lähevad
Krüpteeritud paketid ühest saidist teise väljuvad selle kaudu, mille kohalik ruuter peeri avaliku aadressi jaoks valib. Kui mõlemad saidid ostavad transiiti samalt teenusepakkujalt, läbivad sama metroorajatist või üks pool asub operaatoritaseme NAT-i taga, jääb tunnel teenusepakkuja rikkest ellu ainult juhuslikult. Tunnelite ikoonide loendamine jälgimisvahendis ei ütle selle kohta sulle midagi.
Marsruudi valik ja edastamise paigaldamine on samuti eraldi sündmused. Prefiks võib seista BGP tabelis parimana ja ikkagi edastustabelist puududa, sest järgmine hüpe on lahendamatu või võidab täpsem marsruut. Kui keegi teatab, et BGP õppis prefiksi, kuid liiklus ei voola, on kasulik küsimus, kas see on paigaldatud ja millisele järgmisele hüppele see osutab.
Aus vastus disainiülevaatusele on jagatud sõltuvuste loend: juurdepääsuahel, ülemvoolu-teenusepakkuja, rajatis ja iga olekut säilitav seade tagasiteel. Sessioon üle tunneli ei saa eemaldada sõltuvust, millest see ülalpool ei asu.
Kolm otsust, mida tasub eraldada
Kui disain need segi ajab, käib iga katkestusvestlus ringiratast. Eralda need kõigepealt paberil, seejärel vastenda igaüks seadmele, mis seda tegelikult jõustab.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
Igal real on erinev omanik. Esimene on läbirääkimine, teine on sinu seadmete konfiguratsioon, kolmas on enamasti kellegi teise võrk. Muudatustaotlust, mis nimetab rida, mida see puudutab, on palju lihtsam kinnitada kui seda, mis ütleb BGP probleem.
Rikkeolukorrad, millega tasub arvestada
Peeride kokkuvõtliku marsruudi vastuvõtmine on kõige levinum ise tekitatud haav. Keegi kuulutab lühikese agregaadi vahetuse lihtsustamiseks, kaugem pool võtab selle vastu ja liiklus vahemikele, mis ei asu tunneli taga, järgib tunnelit ja sureb. Filtreeri täpselt oodatud prefiksite järgi või kasuta õigete piiridega prefiksite loendit, ja ära kunagi võta vastu paljast agregaati, sest see teeb sessiooni korralikuks.
Tagasivõtmise ajastus on teine. Tuvastus sõltub hoiutaimeritest, BFD-st, kui selle lubasid, tunneli surnud peeri tuvastusest ja sellest, kui kiiresti kaugem pool kuulutamise lõpetab. Olemasolevad sessioonid on eraldi probleem: uus marsruut võib taastada uued ühendused, samal ajal kui püstitatud TCP sessioonid kasutavad edasi aegunud aadresse, ja teel olevad olekut säilitavad tulemüürid või NAT võivad hoida kirjeid, mis enam ei sobi. Pane rakenduse taastumine vastuvõtukriteeriumidesse, selle asemel et eeldada, et marsruudi muudatus lahendab kõik.
Kolmas on tagasitee asümmeetria. Liiklus võib saabuda üle tunneli ja naasta teenusepakkuja lingi kaudu, mis ei olnud kunagi mõeldud seda kandma, mis väljendub ühesuunalise helina, ebaõnnestunud kätlemistena või tulemüürina, mis vastused maha viskab. Kontrolli mõlemat suunda eraldi.
Mida lepingusse kirjutada ja kuidas seda kontrollida
Küsi lubatud prefiksid kirjalikult: kellel on õigus iga vahemikku originaerida, kas vaikemarsruut on lubatud ja milliseid aadressiperesid tunneliteenus toetab. RFC 8212 tegi selgesõnalise impordi- ja ekspordipoliitika eBGP ootuseks teostustes, mis seda järgivad, seega peer, kes veel toetub kaudsele kõike-vastuvõtu käitumisele, tasub küsimuse ära.
Seejärel kontrolli seadmest, mitte diagrammilt. Kasulikud käsud FRR-laadsetel ruuteritel:
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
Lisa kaks tähelepanekut, mida marsruutimistabel sulle anda ei saa. Püüa välisliidesel, et kinnitada, millist aadressi kapseldatud paketid tegelikult sihivad, näiteks tcpdump -ni eth0 udp port 51820 WireGuard-tunneli jaoks või ESP-filter IPsec-i jaoks. Seejärel jälgi peeri avaliku aadressi suunas ja võrdle hüppeid tunnelisisese jäljega; kui mõlemad järgivad sama teenusepakkuja ahelat, elab sinu liiasus marsruudipoliitikas, mitte võrgus.
Lõpuks testi tagasivõtmist meelega. Võta tunnel hooldusakna ajal maha, pane kirja, kui kaua prefiks paigaldatuks jääb, mis juhtub olemasolevate sessioonidega ja kas kaugem pool langeb tagasi marsruudile, mille sa tegelikult vastu võtaksid. See harjutus ütleb disaini kohta rohkem kui ükski diagramm.
Marsruut ei ole volitus. Prefiksid, mille vahetamises kokku lepite, ei ütle midagi selle kohta, millised kasutajad võivad jõuda millise teenuseni tunneli taga, seega hoia autentimine, lubatud teenused ja hosti tulemüürid täpselt seal, kus need olid. Kättesaadav peer ei ole ka luba piiramatuks transiidiks ega suvaliste aadresside originaerimiseks, ja selline volitus kuulub lepingusse äriküsimusena, mitte BGP poliitikareale.
- Nimeta prefiksid, mida kumbki pool võib originaerida, ja need, mida see ei tohi kunagi vastu võtta.
- Piira MSS tunnelil ja kinnita, et suured uuendused tõesti saabuvad.
- Loetle jagatud aluskihi sõltuvused, mitte tunnelite arv.
- Mõõda tegelikku tagasivõtmist ja pane kirja, mida rakendus teeb.