Wolk-VPN het BGP nodig: waarom ander roeteringsprotokolle misluk
Die tonnel is op en die prefiks verskyn nooit. Bestuurde wolk-VPN's praat BGP as die roeteringskontrak, so kyk eerste na die diensvereiste.
Die IPsec-sekuriteitsassosiasie is op, die tonneltellers beweeg, en verkeer na die wolkprefiks verdwyn. Die operateur probeer dan OSPF op die klant se roeteerder aktiveer en verwag dat die buurman moet vorm, en niks gebeur nie. Die tonnel was nooit die ontbrekende stuk nie: 'n bestuurde wolk-VPN bied 'n gedefinieerde roeteringskontrak, en op die groot platforms is daardie kontrak BGP. Totdat 'n sessie bestaan en 'n prefiks aanvaar word, is die tonnel net 'n geënkripteerde pad met geen bestemmings agter dit nie.
Die tonnel is op en die roete ontbreek
Fase 1 en fase 2 wat voltooi, bewys dat die eweknieë oor beskerming saamstem, nie dat enige kant weet waarheen om verkeer te stuur nie. Dit is aparte toestandmasjiene met aparte mislukkingsmodusse.
Vra drie vrae in volgorde: is die prefiks geadverteer, is dit deur die eweknie aanvaar, en is dit vir aanstuur geïnstalleer? 'n Prefiks wat geadverteer en gefiltreer is, is 'n beleidsprobleem. 'n Prefiks wat nooit geadverteer is nie, is 'n sessie- of konfigurasieprobleem. 'n Prefiks wat aanvaar maar nie geïnstalleer is nie, is 'n roetekeuseprobleem, en elke antwoord wys na 'n ander deel van die konfigurasie.
Wat die verskaffer werklik aan jou gee
'n Bestuurde VPN-hek is nie 'n onbeperkte roeteerder nie. Die verskaffer gee jou 'n hek met ondersteunde eweknie-adresse, 'n outonome stelsel-instelling, prefiksgrense en 'n gedefinieerde falinggedrag. Daardie oppervlak is die produk.
Google Cloud dokumenteer dinamiese BGP-roetering vir HA VPN, met Cloud Router wat eweknie-roetes leer en geskikte pasgemaakte dinamiese roetes aan die VPC verskaf. AWS Site-to-Site VPN dokumenteer 'n keuse tussen statiese en dinamiese roetering, en beskryf BGP-lewendheidskontroles as nuttig vir tonnel-oorskakeling terwyl dit ook gesondheidskontroles ondersteun vir toestelle sonder BGP. Geen platform se gedrag moet uit die ander se produknaam afgelei word nie.
Die praktiese gevolg is dat jy eers die bestuurde modus kies en dan die ondersteunde knoppies lees. 'n Ontwerp wat 'n aangrensingstipe aanneem wat die diens nie bied nie, is nie 'n konfigurasieprobleem om op die klant se roeteerder op te los nie.
Tonnelbeskerming en bereikbaarheid is aparte take
IPsec beskerm die verkeer wat vir die tonnel gekies word. BGP verskaf die bereikbaarheidsinligting wat 'n prefiks geskik maak. 'n Werkende tonnel bewys nie dat die verwagte prefiks geadverteer, aanvaar of geïnstalleer is nie.
Stel jou 'n tak voor wat 10.42.0.0/16 deur twee geskikte tonnelpaaie adverteer. Verwyder een bruikbare pad en die roetekeuse kan verander sonder dat iemand elke werklading se roete wysig. Opsporing, roetekeuse en toepassingherstel is nie onmiddellik nie, en hulle is nie identies oor ontplooiings nie, so die oorskakelingstoets moet die hele reeks waarneem eerder as die eerste pakkie wat deurkom.
Wanneer 'n wolkprefiks onbereikbaar is, kyk na die sessietoestand en die geleerde roetes voordat jy aan kripto raak. 'n SA wat op is met geen roete agter dit nie, is die algemeenste weergawe van hierdie simptoom.
Waar OSPF-aannames breek
OSPF, IS-IS of 'n ander protokol binne 'n IPsec-tonnel is heeltemal moontlik op 'n selfbestuurde toestel, waar jy albei kante en die aanstuurontwerp besit. Daardie feit sê niks oor 'n bestuurde diens wat net BGP as sy dinamiese roeteringsmodus bied nie.
As 'n voorgestelde ontwerp 'n aangrensing nodig het wat die diens nie ondersteun nie, verander die argitektuur doelbewus. Opsies sluit in 'n selfbestuurde toestel in die VPC, statiese roetering waar die diens dit ondersteun, of 'n ander konnektiwiteitsproduk. Om die protokol net op die klant se roeteerder te konfigureer, kan nie 'n wolk-kant eweknie byvoeg wat nie bestaan nie, en dit sal nie die prefiks laat verskyn nie.
Moenie een verskaffer se antwoord na 'n ander verskaffer se hek dra nie. Dieselfde woorde, soos dinamiese roetering of tonnel-oorskakeling, kan verskillende meganismes en verskillende grense beskryf.
Lees die diensvereiste, ontwerp dan
Skryf voor die eerste konfigurasiereël die buuradresse, die outonome stelsel-nommers, die prefikse wat jy sal adverteer en aanvaar, die roetegrense en die verwagte gedrag wanneer 'n tonnel faal, neer. Daardie vyf items is die kontrak waarteen jy ontwerp.
Verifieer dan in dieselfde volgorde: sessie gevestig, prefiks ontvang, roete teenwoordig in die VPC-roetetabel, en 'n werklike vloei na 'n diensadres. Herhaal ná 'n gedwonge oorskakeling, want 'n sessie wat weer vestig, kan met 'n ander roetestel terugkom. As die ontwerp van sub-sekonde konvergensie afhang, meet dit eerder as om dit te aanvaar.
Hou die dienskontrak by die veranderingsrekord. Wanneer iemand later vra waarom die tonnel nie OSPF kan loop nie, is die antwoord 'n produkegrens, nie 'n protokolbeperking nie, en die rekord moet dit sê.