Kāpēc BGP virs VPN nepārvalda jūsu apakšējā slāņa ceļu

Divi objekti savieno BGP pār IPsec tuneli, apgūst viens otra prefiksus, un diagramma tiek pārdēvēta par ceļa kontroli. Tieši šis apzīmējums ir apjukumā sākums. Sesija tiešām apmainās ar sasniedzamību un tiešām piemēro politiku, bet tai nav teikšanas, kurš pakalpojumu sniedzējs, kabelis vai maršrutētājs pārvadā šifrētos paketus. Esmu redzējis komandu pārbūvējam strādājošu tuneli, jo tā gaidīja, ka BGP maršruta izmaiņa pārvietos satiksmi uz citu šķiedras ceļu, kuru sesija nekad nevarēja ietekmēt.

Ko cilvēki domā, ka sesija nopērk

Lielākā daļa gaidu nāk no tā, kā maršruta izmaiņa izskatās laboratorijā. Jūs paziņojat prefiksu pār tuneli, tālā puse to instalē, un satiksme pārvietojas. Tā pati secība notiek maršrutētājā, kuram tiešām ir satiksmes inženierijas sviras, tāpēc abi tiek sajaukti. Laboratorijā abi objekti parasti dala vienu piekļuves līniju, un tieši tāpēc atšķirība tur nekad neparādās.

BGP ir sasniedzamības protokols. Tas pasaka partnerim, ka varat piegādāt paketus prefiksam, un ļauj katrai pusei sarindot saņemtos piedāvājumus. Tas ir patiešām noderīgi pār tuneli: prefiksi parādās un pazūd, objektiem nākot un ejot, un jūs varat atteikt diapazonu, neierakstot statisku maršrutu katrā malas ierīcē. Ko tas nedara, ir pakalpojumu sniedzēja maršrutētāju nodošana jūsu kontrolē.

Apakšējais slānis pārvadā ārējo galveni. Jūsu tuneļa galapunkts sūta šifrētus paketus uz partnera adresi, un tīkls starp šīm divām adresēm tos pārsūta ar maršrutiem, ko instalējuši tā operatori. Nekas BGP sesijā nemaina šo lēmumu, ja vien tas pats pakalpojumu sniedzējs nepiedāvā atbalstītu pakalpojumu, kas to dara.

Ko sesija patiešām pārvadā

BGP runātājs atver TCP savienojumu uz sava partnera portu 179, izmantojot RFC 4271 definētos ziņojumu formātus un ceļa atribūtus. Kad partnera adrese atrodas tuneļa iekšpusē, tunelim jābūt paceltam un adresei sasniedzamai, pirms sesija vispār var sākties. Pabeigta IKE apmaiņa nav BGP kaimiņš. Maršrutos balstītas IPsec implementācijas laiž satiksmi cauri tikai tad, kad pastāv atbilstošs tuneļa maršruts, bet politikā balstītajai partnera adresei jābūt aizsargātajā selektorā. Apgriežot to otrādi, rodas klasiskais stāvoklis, kurā tunelis ir zaļš, bet sesija stāv dīkā.

Kad sesija ir pacelta, politika izlemj, kas to šķērso. Prefiksu saraksti, AS-ceļa filtri, maksimālā prefiksu robeža un skaidrs lēmums par noklusējuma maršrutiem ir minimums, un tie attiecas abos virzienos. Partneris, kas pieņem visu, ko saņem, var dot jums noklusējuma maršrutu, kas klusi aizstāj vietējo interneta piekļuvi. Abiem virzieniem vajag atsevišķus sarakstus, jo tas, ko pieņemat no partnera, un tas, ko tam paziņojat, ir dažādi lēmumi.

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

Tālāk kož MTU. Iekapsulēšana samazina izmantojamo kravu, tāpēc liels atjauninājums var apturēt sesiju, kas izskatās pilnīgi nodibināta: partneris paliek augšā, prefiksi nekad neierodas, un žurnālā nekas acīmredzams neparādās. Ierobežojiet TCP MSS tuneļa saskarnē vai iestatiet tuneļa MTU ar vietu papildu izmaksām, pirms vainojat filtrus.

Kur ārējie paketi tomēr aiziet

Šifrēti paketi no viena objekta uz otru iziet pa to ceļu, ko vietējais maršrutētājs izvēlas partnera publiskajai adresei. Ja abi objekti pērk tranzītu no viena pakalpojumu sniedzēja, šķērso vienu un to pašu metro objektu vai viena puse atrodas aiz operatora līmeņa NAT, tunelis pakalpojumu sniedzēja atteici pārdzīvo tikai nejauši. Tuneļu ikonu skaitīšana uzraudzības rīkā par to neko nepasaka.

Maršruta izvēle un pārsūtīšanas instalēšana arī ir atsevišķi notikumi. Prefikss var sēdēt BGP tabulā kā labākais un tomēr trūkt pārsūtīšanas tabulā, jo nākamais lēciens nav atrisināms vai uzvar konkrētāks maršruts. Kad kāds ziņo, ka BGP ir iemācījies prefiksu, bet satiksme neplūst, noderīgais jautājums ir, vai tas ir instalēts un uz kuru nākamo lēcienu tas rāda.

Godīga atbilde dizaina pārskatam ir kopīgu atkarību saraksts: piekļuves ķēde, augšupējais pakalpojumu sniedzējs, objekts un jebkura stāvokli saglabājoša ierīce atgriešanās ceļā. Sesija pār tuneli nevar noņemt atkarību, virs kuras tā nesēž.

Trīs lēmumi, ko ir vērts atdalīt

Kad dizains šos sajauc, katra atteices saruna iet pa apli. Vispirms atdaliet tos uz papīra, pēc tam katru piesaistiet ierīcei, kas to patiešām īsteno.

Katrai rindai ir cits īpašnieks. Pirmā ir sarunas, otrā ir konfigurācija jūsu ierīcēs, trešā pārsvarā ir kāda cita tīkls. Izmaiņu pieprasījumu, kurā nosaukta rinda, ko tas skar, ir daudz vieglāk apstiprināt nekā tādu, kurā teikts BGP problēma.

Atteices režīmi, ko ir vērts plānot

Partnera kopsavilkuma maršruta pieņemšana ir visizplatītākā pašnodarītā brūce. Kāds paziņo īsu agregātu, lai vienkāršotu apmaiņu, tālā puse to pieņem, un satiksme diapazoniem, kas nav aiz tuneļa, seko tunelim un iet bojā. Filtrējiet pēc precīzi gaidītajiem prefiksiem vai izmantojiet prefiksu sarakstu ar pareizām robežām, un nekad nepieņemiet kailu agregātu, jo tas liek sesijai izskatīties kārtīgai.

Atsaukšanas laiks ir otrais. Noteikšana ir atkarīga no turēšanas taimeriem, no BFD, ja to ieslēdzāt, no tuneļa mirušā partnera noteikšanas un no tā, cik ātri tālā puse pārstāj paziņot. Esošās sesijas ir atsevišķa problēma: jauns maršruts var atjaunot jaunus savienojumus, kamēr nodibinātās TCP sesijas turpina izmantot novecojušas adreses, un stāvokli saglabājošas ugunsmūri vai NAT ceļā var turēt ierakstus, kas vairs neatbilst. Ievietojiet lietojumprogrammas atjaunošanu pieņemšanas kritērijos, nevis pieņemiet, ka maršruta izmaiņa visu nokārto.

Trešā ir atgriešanās ceļa asimetrija. Satiksme var ierasties pa tuneli un atgriezties pa pakalpojumu sniedzēja līniju, kas nekad nav bijusi paredzēta to pārvadāt, kas izpaužas kā vienvirziena audio, neizdevušās rokasspiedieni vai ugunsmūris, kas met nost atbildes. Pārbaudiet abus virzienus atsevišķi.

Ko ierakstīt līgumā un kā to pārbaudīt

Pieprasiet atļautos prefiksus rakstiski: kam ir tiesības ģenerēt katru diapazonu, vai noklusējuma maršruts ir atļauts un kuras adrešu saimes tuneļa pakalpojums atbalsta. RFC 8212 padarīja skaidru importa un eksporta politiku par eBGP gaidām implementācijās, kas to ievēro, tāpēc partneris, kas joprojām paļaujas uz netiešu visu pieņemšanas uzvedību, ir pelnījis jautājumu.

Pēc tam pārbaudiet no ierīces, nevis no diagrammas. Noderīgas komandas FRR stila maršrutētājos:

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

Pievienojiet divus novērojumus, ko maršrutu tabula jums nevar dot. Ierakstiet ārējā saskarnē, lai apstiprinātu, uz kuru adresi iekapsulētie paketi patiešām mērķē, piemēram tcpdump -ni eth0 udp port 51820 WireGuard tunelim vai ESP filtrs IPsec. Pēc tam sekojiet uz partnera publisko adresi un salīdziniet lēcienus ar pēdu tuneļa iekšpusē; ja abi seko vienai un tai pašai pakalpojumu sniedzēja ķēdei, jūsu dublējums dzīvo maršrutu politikā, nevis tīklā.

Visbeidzot, apzināti pārbaudiet atsaukšanu. Nolaidiet tuneli apkopes logā, pierakstiet, cik ilgi prefikss paliek instalēts, kas notiek ar esošajām sesijām un vai tālā puse atkrīt uz maršrutu, ko jūs patiešām pieņemtu. Šis vingrinājums par dizainu pasaka vairāk nekā jebkura diagramma.

Maršruts nav atļauja. Prefiksi, par kuriem vienojaties apmainīties, neko nepasaka par to, kuri lietotāji var sasniegt kuru pakalpojumu aiz tuneļa, tāpēc turiet autentifikāciju, atļautos pakalpojumus un resursdatora ugunsmūrus tieši tur, kur tie bija. Sasniedzams partneris arī nav atļauja neierobežotam tranzītam vai patvaļīgu adrešu ģenerēšanai, un šāda veida pilnvaras pieder līgumam kā komerciāls jautājums, nevis BGP politikas rindai.

• Nosauciet prefiksus, ko katra puse var ģenerēt, un tos, ko tā nekad nedrīkst pieņemt.
• Ierobežojiet MSS tunelī un apstipriniet, ka lieli atjauninājumi patiešām ierodas.
• Uzskaitiet kopīgās apakšējā slāņa atkarības, nevis tuneļu skaitu.
• Izmēriet īstu atsaukšanu un atzīmējiet, ko dara lietojumprogramma.