Hodeiko VPNak BGP behar du: zergatik huts egiten dute beste bideratze-protokoloek

IPsec segurtasun-elkartea martxan dago, tunelaren kontagailuak mugitzen dira, eta hodeiko aurrizkirako trafikoa desagertzen da. Orduan operadoreak OSPF gaitu nahi du bezeroaren bideratzailean, bizilaguna eratuko dela espero du, eta ezer ez da gertatzen. Tunela ez zen inoiz falta zen pieza: kudeatutako hodeiko VPN batek bideratze-kontratu zehaztu bat erakusten du, eta plataforma handietan kontratu hori BGP da. Saioa existitu eta aurrizki bat onartu arte, tunela bideratze-irteerarik gabeko bide zifratu bat besterik ez da.

Tunela martxan dago eta bidea falta da

1. fasea eta 2. fasea osatzeak frogatzen du aldeak babesarekin ados daudela, ez alderen batek trafikoa nora bidali badaki. Egoera-makina bereiziak dira, hutsegite-modu bereiziekin.

Egin hiru galdera hurrenez hurren: aurrizkia iragarri zen, pareak onartu zuen, eta aurreratzeko instalatu zen? Iragarri eta iragazi zen aurrizkia politika-arazoa da. Inoiz iragarri ez zen aurrizkia saio edo konfigurazio arazoa da. Onartu baina instalatu ez zen aurrizkia bide-hautapeneko arazoa da, eta erantzun bakoitzak konfigurazioaren zati desberdin bat seinalatzen du.

Zer ematen dizu hornitzaileak benetan

Kudeatutako VPN ate bat ez da murrizketarik gabeko bideratzailea. Hornitzaileak ate bat ematen dizu onartutako pare-helbideekin, sistema autonomoaren ezarpenarekin, aurrizki-mugekin eta hutsegite-jokabide zehaztuarekin. Azalera hori da produktua.

Google Cloud-ek BGP bideratze dinamikoa dokumentatzen du HA VPN-rako, Cloud Router-ek pareen bideak ikasi eta VPCra bide dinamiko pertsonalizatu egokiak hornitzen dituela. AWS Site-to-Site VPN-ek bideratze estatikoaren eta dinamikoaren arteko hautua dokumentatzen du, eta BGP bizi-kontrolek tunelaren hutsegite-aldaketarako balio dutela deskribatzen du, BGPrik gabeko gailuetarako osasun-kontrolak ere onartuz. Ez da plataforma baten jokabidea bestearen produktu-izenetik ondorioztatu behar.

Ondorio praktikoa da lehenik kudeatutako modua hautatzen duzula eta gero onartutako parametroak irakurtzen dituzula. Zerbitzuak eskaintzen ez duen aldamenotasun mota suposatzen duen diseinua ez da bezeroaren bideratzailean konpondu beharreko konfigurazio-arazoa.

Tunelaren babesa eta irisgarritasuna lan bereiziak dira

IPsec-ek tunelerako hautatutako trafikoa babesten du. BGP-k aurrizki bat egokia egiten duen irisgarritasun-informazioa ematen du. Funtzionatzen duen tunel batek ez du frogatzen espero zen aurrizkia iragarri, onartu edo instalatu zenik.

Irudi ezazu 10.42.0.0/16 bi tunel-bide egokiren bidez iragartzen duen sukurtsal bat. Kendu erabilgarri den bide bat eta bide-hautapena alda daiteke inork lan-karga bakoitzaren bidea editatu gabe. Detekzioa, bide-hautapena eta aplikazioaren berreskuratzea ez dira berehalakoak, eta ez dira berdinak hedapen guztietan, beraz hutsegite-aldaketaren probak sekuentzia osoa behatu behar du, igarotzen den lehen paketea ez ezik.

Hodeiko aurrizki bat irisgarria ez denean, egiaztatu saioaren egoera eta ikasitako bideak kriptografiari ukitu aurretik. Martxan dagoen SA bat atzean biderik gabe sintoma honen formarik ohikoena da.

Non hausten dira OSPFri buruzko suposizioak

OSPF, IS-IS edo beste protokolo bat IPsec tunel baten barruan erabat posible da zuk zeuk kudeatutako gailu batean, non bi muturrak eta aurreratze-diseinua zureak diren. Gertaera horrek ezer ez du esaten BGP bakarrik bideratze dinamikoko modu gisa eskaintzen duen zerbitzu kudeatu bati buruz.

Proposatutako diseinuak zerbitzuak onartzen ez duen aldamenotasun bat behar badu, aldatu arkitektura nahita. Aukerak hauek dira: VPCn kudeatzen duzun gailu bat, bideratze estatikoa zerbitzuak onartzen duen tokian, edo konektibitate-produktu desberdin bat. Protokoloa bezeroaren bideratzailean bakarrik konfiguratzeak ezin du hodei aldeko pare bat gehitu existitzen ez dena, eta ez du aurrizkia agerraraziko.

Ez eraman hornitzaile baten erantzuna beste hornitzaile baten atera. Hitz berberek, hala nola bideratze dinamikoak edo tunelaren hutsegite-aldaketak, mekanismo eta muga desberdinak deskriba ditzakete.

Irakurri zerbitzuaren baldintza, eta gero diseinatu

Lehen konfigurazio-lerroa baino lehen, idatzi bizilagunen helbideak, sistema autonomoen zenbakiak, iragarri eta onartuko dituzun aurrizkiak, bide-mugak eta tunel bat huts egitean espero den jokabidea. Bost elementu horiek dira diseinatzen ari zaren kontratua.

Gero egiaztatu ordena berean: saioa ezarrita, aurrizkia jasota, bidea VPCren bide-taulan eta benetako fluxua zerbitzu-helbide baterantz. Errepikatu behartutako hutsegite-aldaketa baten ondoren, zeren berrezartzen den saio bat bide-multzo desberdinarekin itzul baitaiteke. Diseinuak segundo azpiko konbergentziaren mende badago, neurtu, ez suposatu.

Mantendu zerbitzu-kontratua aldaketaren erregistroarekin. Geroago norbaitek galdetzen duenean zergatik ezin duen tunelak OSPF exekutatu, erantzuna produktu-muga bat da, ez protokolo-murrizketa bat, eta erregistroak hori esan behar luke.