Af hverju BGP yfir VPN stýrir ekki undirlagsleiðinni þinni

Tvær staðsetningar peer-a BGP yfir IPsec-göng, læra forskeyti hvors annars, og skýringarmyndin er endurmerkt sem leiðarstýring. Það merki er þar sem ruglingurinn byrjar. Lotan skiptist sannarlega á aðgengi og beitir sannarlega stefnu, en hún hefur ekkert að segja um hvaða þjónustuveitandi, kaðall eða beinir flytur dulkóðuðu pakkana. Ég hef séð teymi endurbyggja virkt göng vegna þess að það bjóst við að BGP-leiðarbreyting myndi færa umferðina yfir á aðra trefjarleið sem lotan gat aldrei haft áhrif á.

Hvað fólk gerir ráð fyrir að lota kaupi

Megnið af væntingunni kemur frá því hvernig leiðarbreyting lítur út á rannsóknarstofu. Þú auglýsir forskeyti yfir göngin, fjarlæga hliðin setur það upp og umferðin hreyfist. Sama röð gerist á beini sem hefur í raun stýringar fyrir umferðarverkfræði, svo þessu tvennu er ruglað saman. Á rannsóknarstofunni deila báðar staðsetningarnar venjulega einni aðgangstengingu, og það er einmitt hvers vegna munurinn kemur aldrei fram þar.

BGP er aðgengisprotokoll. Það segir peer að þú getir afhent pakka fyrir forskeyti og leyfir hvorri hlið að raða tilboðunum sem hún fær. Það er sannarlega gagnlegt yfir göng: forskeyti birtast og hverfa eftir því sem staðsetningar koma og fara, og þú getur hafnað bili án þess að skrifa kyrra leið á hvert jaðartæki. Það sem það gerir ekki er að setja beina þjónustuveitanda undir stjórn þína.

Undirlagið ber ytri hausinn. Endapunktur ganganna þinna sendir dulkóðaða pakka á peer-fangstöð, og netið milli þessara tveggja fangstaða sendir þá áfram með þeim leiðum sem rekstraraðilar þess hafa sett upp. Ekkert í BGP-lotunni breytir þeirri ákvörðun, nema sami þjónustuveitandi bjóði upp á studda þjónustu sem gerir það.

Hvað lotan ber í raun

BGP-talarinn opnar TCP-tengingu á port 179 hjá peer sínum og notar skeytaform og leiðareiginleika sem skilgreindir eru í RFC 4271. Þegar peer-fangstaðurinn er inni í göngunum verða göngin að vera uppi og fangstaðurinn aðgengilegur áður en lotan getur byrjað. Lokið IKE-skipti er ekki BGP-nágranni. IPsec-útfærslur sem byggja á leiðum hleypa umferð aðeins í gegn þegar samsvarandi gönguleið er til, og sú sem byggir á stefnu þarf peer-fangstaðinn inni í varða veljaranum. Að snúa þessu við skapar hina klassísku stöðu þar sem göngin eru græn og lotan situr aðgerðalaus.

Þegar lotan er uppi ákveður stefnan hvað fer yfir hana. Forskeytalistar, AS-leiðasíur, hámark á fjölda forskeyta og skýr ákvörðun um sjálfgefnar leiðir eru lágmarkið, og þau gilda í báðar áttir. Peer sem samþykkir allt sem það fær getur gefið þér sjálfgefna leið sem kemur hljóðlega í stað staðbundins internet-aðgangs. Báðar áttirnar þurfa aðskilda lista, því það sem þú samþykkir frá peer og það sem þú auglýsir til þess eru tvær ólíkar ákvarðanir.

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

Næst bítur MTU. Innpakningin minnkar nothæfa hleðslu, svo stór uppfærsla getur stöðvað lotu sem lítur fullkomlega út fyrir að vera komin á fót: peer helst uppi, forskeyti koma aldrei og ekkert augljóst lendir í annálnum. Takmarkaðu TCP MSS á gönguviðmótinu, eða stilltu göngu-MTU með plássi fyrir yfirhöfuðið, áður en þú kennir síunum um.

Hvert ytri pakkarnir fara samt

Dulkóðaðir pakkar frá einni staðsetningu til annarrar fara út um það sem staðbundni beinirinn velur fyrir opinbert fangstað peer. Ef báðar staðsetningarnar kaupa flutning frá sama þjónustuveitanda, fara yfir sömu borgaraðstöðu eða önnur hliðin er bak við NAT á stigi símafyrirtækis, lifir göngin af bilun þjónustuveitanda aðeins fyrir tilviljun. Að telja göngutákn í eftirlitstæki segir þér ekkert um það.

Leiðarval og uppsetning áframleiðslu eru líka aðskildir atburðir. Forskeyti getur setið í BGP-töflunni sem best og samt vantað í áframleiðslutöfluna, því næsta stökk er óleysanlegt eða nákvæmari leið vinnur. Þegar einhver greinir frá því að BGP hafi lært forskeytið en umferðin flæði ekki, er gagnlega spurningin hvort það sé uppsett og hvaða næsta stökki það bendir á.

Heiðarlegt svar fyrir hönnunarúttekt er listi yfir sameiginlegar ósjálfstæður: aðgangsrás, þjónustuveitandi ofar, aðstaða og hvert ástandstæki á afturleiðinni. Lota yfir göngunum getur ekki fjarlægt ósjálfstæðu sem hún situr ekki yfir.

Þrjár ákvarðanir sem vert er að aðskilja

Þegar hönnun blandar þessu saman fer hvert bilanatilvik í hringi. Aðskildu þau fyrst á pappír og tengdu svo hvert við tækið sem framfylgir því í raun.

Hver röð hefur annan eiganda. Fyrsta er samningaviðræður, önnur er stilling á þínum tækjum, þriðja er að mestu net annars aðila. Breytingabeiðni sem nefnir röðina sem hún snertir er mun auðveldara að samþykkja en sú sem segir BGP-vandamál.

Bilanamáta sem vert er að skipuleggja fyrir

Að samþykkja samantektarleið peer er algengasta sjálfskipuð sárið. Einhver auglýsir stutta samtöku til að einfalda skiptin, fjarlæga hliðin samþykkir hana og umferð fyrir svið sem eru ekki bak við göngin fylgir göngunum og deyr. Síaðu á nákvæmlega væntu forskeytin, eða notaðu forskeytalista með réttum mörkum, og samþykktu aldrei bert samtöku því það lætur lotuna líta snyrtilega út.

Tímasetning afturköllunar er sú önnur. Greining fer eftir haldtímamælum, BFD ef þú virkjaðir það, dauðs-peer-greiningu ganganna og hversu hratt fjarlæga hliðin hættir að auglýsa. Núverandi lotur eru sérstakt vandamál: ný leið getur endurheimt nýjar tengingar á meðan komnar TCP-lotur halda áfram að nota úrelta fangstaði, og ástandsfirewallar eða NAT á leiðinni geta haldið færslum sem passa ekki lengur. Settu endurheimt forritsins í samþykkisskilyrðin í stað þess að gera ráð fyrir að leiðarbreyting leysi allt.

Þriðja er ósamhverfa afturleiðarinnar. Umferð getur komið yfir göngin og snúið til baka um tengingu þjónustuveitanda sem aldrei var ætlað að bera hana, sem birtist sem einstefnu hljóð, misheppnuð handtök eða firewall sem hendir svörum. Athugaðu báðar áttirnar sérstaklega.

Hvað á að skrifa í samninginn og hvernig á að sannreyna það

Biddu um leyfðu forskeytin skriflega: hver er heimilaður að skapa hvert svið, hvort sjálfgefin leið er leyfð og hvaða fangstaðaflokka gönguþjónustan styður. RFC 8212 gerði skýra inn- og útflutningsstefnu að væntingunni fyrir eBGP í útfærslum sem fylgja henni, svo peer sem enn treystir á óbeint samþykkja-allt-hegðun er þess virði að spyrja um.

Sannreyndu svo frá tækinu frekar en skýringarmyndinni. Gagnlegar skipanir á beinum í FRR-stíl:

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

Bættu við tveimur athugunum sem leiðartöfluna getur ekki gefið þér. Taktu upp á ytra viðmótinu til að staðfesta hvaða fangstað innpökkuðu pakkarnir stefna í raun á, til dæmis tcpdump -ni eth0 udp port 51820 fyrir WireGuard-göng, eða ESP-síu fyrir IPsec. Rekjaðu svo í átt að opinberum fangstað peer og berðu stökkin saman við rek í göngunum; ef bæði fylgja sömu keðju þjónustuveitanda býr varasemdin þín í leiðarstefnunni en ekki í netinu.

Að lokum skaltu prófa afturköllun viljandi. Taktu göngin niður í viðhaldsglugga, skráðu hversu lengi forskeytið helst uppsett, hvað verður um núverandi lotur og hvort fjarlæga hliðin fellur aftur á leið sem þú myndir í raun samþykkja. Sú æfing segir meira um hönnunina en nokkur skýringarmynd.

Leið er ekki heimild. Forskeytin sem þú samþykkir að skiptast á segja ekkert um hvaða notendur mega ná hvaða þjónustu bak við göngin, svo haltu auðkenningu, leyfðum þjónustum og firewallum hýsilsins nákvæmlega þar sem þau voru. Aðgengilegt peer er heldur ekki leyfi fyrir ótakmörkuðum flutningi eða til að skapa handahófskennda fangstaði, og slíkt vald á heima í samningnum sem viðskiptaleg spurning, ekki í BGP-stefnulínu.

• Nefndu forskeytin sem hvor hlið má skapa og þau sem hún má aldrei samþykkja.
• Takmarkaðu MSS á göngunum og staðfestu að stórar uppfærslur berist í raun.
• Listaðu sameiginlegu undirlagsósjálfstæðurnar, ekki fjölda ganga.
• Tímasettu raunverulega afturköllun og skráðu hvað forritið gerir.