Pse BGP mbi një VPN nuk kontrollon rrugën e shtresës së poshtme

Dy vende bëjnë peering BGP përmes një tuneli IPsec, mësojnë prefikset e njëri-tjetrit dhe diagrami riemërtohet si kontroll rruge. Ky etiketim është fillimi i konfuzionit. Sesioni vërtet shkëmben arritshmëri dhe vërtet zbaton politikë, por nuk ka zë se cili ofrues, kabllo apo ruter transporton paketat e kriptuara. Kam parë një ekip duke rindërtuar një tunel që funksiononte sepse prisnin që një ndryshim rruge BGP të zhvendoste trafikun në një rrugë tjetër fibri që sesioni nuk mund ta ndikonte kurrë.

Çfarë mendojnë njerëzit se blen një sesion

Pjesa më e madhe e pritshmërisë vjen nga mënyra si duket një ndryshim rruge në laborator. Shpallni një prefiks përmes tunelit, ana e largët e instalon dhe trafiku lëviz. E njëjta sekuencë ndodh në një ruter që vërtet ka kontrolle të inxhinierisë së trafikut, prandaj të dyja ngatërrohen. Në laborator të dy vendet zakonisht ndajnë një lidhje të vetme aksesi, dhe pikërisht për këtë dallimi nuk shfaqet kurrë atje.

BGP është një protokoll arritshmërie. I thotë një peer se mund të dorëzoni paketa për një prefiks dhe lejon secilën anë të rendisë ofertat që merr. Kjo është vërtet e dobishme përmes një tuneli: prefikset shfaqen dhe zhduken ndërsa vendet vijnë dhe shkojnë, dhe mund të refuzoni një interval pa shkruar një rrugë statike në çdo pajisje buzë. Ajo që nuk bën është t'i vërë ruterat e një ofruesi nën kontrollin tuaj.

Shtresa e poshtme mban kokën e jashtme. Pika juaj fundore e tunelit dërgon paketa të kriptuara në një adresë peer, dhe rrjeti midis këtyre dy adresave i përcjell ato me rrugët që kanë instaluar operatorët e tij. Asgjë në sesionin BGP nuk e ndryshon atë vendim, përveç nëse i njëjti ofrues ofron një shërbim të mbështetur që e bën këtë.

Çfarë mbart vërtet sesioni

Folësi BGP hap një lidhje TCP drejt portës 179 të peer-it të vet, duke përdorur formatet e mesazheve dhe atributet e rrugës të përcaktuara në RFC 4271. Kur adresa e peer-it ndodhet brenda tunelit, tuneli duhet të jetë lart dhe adresa e arritshme përpara se sesioni të mund të fillojë fare. Një shkëmbim IKE i përfunduar nuk është fqinj BGP. Implementimet IPsec të bazuara në rrugë lejojnë trafikun të kalojë vetëm kur ekziston një rrugë tuneli që përputhet, dhe ajo e bazuar në politikë kërkon adresën e peer-it brenda selektorit të mbrojtur. Kthimi mbrapsht i kësaj prodhon gjendjen klasike ku tuneli është i gjelbër dhe sesioni rri pa punë.

Pasi sesioni është lart, politika vendos çfarë e kalon atë. Listat e prefikseve, filtrat AS-path, një tavan i numrit maksimal të prefikseve dhe një vendim i qartë për rrugët e parazgjedhura janë minimumi, dhe zbatohen në të dy drejtimet. Një peer që pranon gjithçka merr mund t'ju japë një rrugë të parazgjedhur që zëvendëson në heshtje aksesin lokal në internet. Të dy drejtimet kanë nevojë për lista të veçanta, sepse ajo që pranoni nga një peer dhe ajo që i shpallni atij janë dy vendime të ndryshme.

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

Më pas kafshon MTU. Enkapsulimi zvogëlon ngarkesën e dobishme, kështu që një përditësim i madh mund të bllokojë një sesion që duket plotësisht i vendosur: peer-i mbetet lart, prefikset nuk vijnë kurrë dhe asgjë e dukshme nuk bie në regjistër. Kufizoni TCP MSS në ndërfaqen e tunelit, ose vendosni një MTU tuneli me hapësirë për mbingarkesën, përpara se të fajësoni filtrat.

Ku shkojnë ende paketat e jashtme

Paketat e kriptuara nga një vend në tjetrin dalin përmes asaj që ruteri lokal zgjedh për adresën publike të peer-it. Nëse të dy vendet blejnë transit nga i njëjti ofrues, kalojnë të njëjtin objekt metro ose njëra anë është pas NAT të nivelit të operatorit, tuneli i mbijeton një dështimi të ofruesit vetëm rastësisht. Numërimi i ikonave të tuneleve në një mjet monitorimi nuk ju thotë asgjë për këtë.

Zgjedhja e rrugës dhe instalimi i përcjelljes janë gjithashtu ngjarje të veçanta. Një prefiks mund të rrijë në tabelën BGP si më i miri dhe prapë të mungojë në tabelën e përcjelljes, sepse hop-i i radhës nuk zgjidhet ose fiton një rrugë më specifike. Kur dikush raporton se BGP e mësoi prefiksin por trafiku nuk rrjedh, pyetja e dobishme është nëse është instaluar dhe drejt cilit hop i radhës tregon.

Përgjigjja e ndershme për një rishikim dizajni është një listë varësish të përbashkëta: qarku i aksesit, ofruesi i sipërm, objekti dhe çdo pajisje me gjendje në rrugën e kthimit. Një sesion përmes tunelit nuk mund të heqë një varësi mbi të cilën nuk rri.

Tre vendime që ia vlen të ndahen

Kur një dizajn i përzien këto, çdo bisedë për dështim shkon në rreth. Ndajini së pari në letër, pastaj lidhni secilin me pajisjen që vërtet e zbaton.

Çdo rresht ka një pronar tjetër. I pari është një negocim, i dyti është konfigurim në pajisjet tuaja, i treti është kryesisht rrjeti i dikujt tjetër. Një kërkesë ndryshimi që emërton rreshtin që prek është shumë më e lehtë për t'u miratuar sesa një që thotë problem BGP.

Mënyra dështimi për të cilat ia vlen të planifikohet

Pranimi i rrugës përmbledhëse të peer-it është plagë e zakonshme e vetëshkaktuar. Dikush shpall një agregat të shkurtër për të thjeshtuar shkëmbimin, ana e largët e pranon dhe trafiku për intervalet që nuk janë pas tunelit ndjek tunelin dhe vdes. Filtroni në prefikset saktësisht të pritura, ose përdorni një listë prefiksesh me kufijtë e duhur, dhe mos pranoni kurrë një agregat të zhveshur sepse e bën sesionin të duket i rregullt.

Koha e tërheqjes është e dyta. Zbulimi varet nga kohëmatësit e mbajtjes, nga BFD nëse e aktivizuat, nga zbulimi i peer-it të vdekur të tunelit dhe nga sa shpejt ana e largët ndalon së shpalluri. Sesionet ekzistuese janë problem i veçantë: një rrugë e re mund të rivendosë lidhje të reja ndërsa sesionet TCP të vendosura vazhdojnë të përdorin adresa të vjetruara, dhe muret e zjarrit me gjendje ose NAT në rrugë mund të mbajnë zëra që nuk përputhen më. Vendosni rikuperimin e aplikacionit në kriteret e pranimit në vend që të supozoni se një ndryshim rruge zgjidh gjithçka.

E treta është asimetria e rrugës së kthimit. Trafiku mund të mbërrijë përmes tunelit dhe të kthehet përmes një lidhjeje ofruesi që nuk ishte menduar kurrë ta transportojë atë, gjë që shfaqet si audio njëdrejtimëshe, shtrëngime duarsh të dështuara ose një mur zjarri që hedh poshtë përgjigjet. Kontrolloni të dy drejtimet veçmas.

Çfarë të shkruhet në kontratë dhe si të verifikohet

Kërkoni me shkrim prefikset e lejuara: kush është i autorizuar të krijojë çdo interval, nëse një rrugë e parazgjedhur lejohet dhe cilat familje adresash mbështet shërbimi i tunelit. RFC 8212 e bëri politikën e qartë të importit dhe eksportit pritshmëri për eBGP në implementimet që e ndjekin, prandaj një peer që ende mbështetet në sjelljen e nënkuptuar të pranimit të gjithçkaje meriton një pyetje.

Më pas verifikoni nga pajisja dhe jo nga diagrami. Komanda të dobishme në ruterat e stilit FRR:

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

Shtoni dy vëzhgime që tabela e rrugëve nuk mund t'ju japë. Kapni në ndërfaqen e jashtme për të konfirmuar se cilën adresë synojnë vërtet paketat e enkapsuluara, për shembull tcpdump -ni eth0 udp port 51820 për një tunel WireGuard, ose një filtër ESP për IPsec. Pastaj gjurmoni drejt adresës publike të peer-it dhe krahasoni hop-et me një gjurmim brenda tunelit; nëse të dyja ndjekin të njëjtin zinxhir ofruesi, teprica juaj jeton në politikën e rrugëve dhe jo në rrjet.

Së fundi, provoni me qëllim një tërheqje. Ulni tunelin në një dritare mirëmbajtjeje, vini re sa kohë prefiksi mbetet i instaluar, çfarë ndodh me sesionet ekzistuese dhe nëse ana e largët kthehet në një rrugë që do ta pranonit vërtet. Ai ushtrim thotë më shumë për dizajnin sesa çdo diagram.

Një rrugë nuk është autorizim. Prefikset që bini dakord të shkëmbeni nuk thonë asgjë se cilët përdorues mund të arrijnë cilën shërbim pas tunelit, prandaj mbajini vërtetimin, shërbimet e lejuara dhe muret e zjarrit të hosteve pikërisht aty ku ishin. Një peer i arritshëm nuk është as leje për transit të pakufizuar ose për të krijuar adresa arbitrare, dhe ai lloj autoriteti i takon kontratës si çështje tregtare, jo një rreshti të politikës BGP.

• Emërtoni prefikset që secila anë mund të krijojë, dhe ato që nuk duhet t'i pranojë kurrë.
• Kufizoni MSS në tunel dhe konfirmoni që përditësimet e mëdha vërtet mbërrijnë.
• Listoni varësitë e përbashkëta të shtresës së poshtme, jo numrin e tuneleve.
• Matni një tërheqje reale dhe vini re çfarë bën aplikacioni.