Matangazo ya BGP ya VGW dhidi ya jedwali la njia la VPC: nini hubadilisha nini

Kiambishi awali kinachokosekana katika jedwali la njia la subneti ya VPC na kiambishi awali kinachokosekana kwenye router ya mteja ni hitilafu mbili tofauti, na ni moja tu kati yao hutengenezwa ndani ya majedwali ya njia ya AWS. Lango la faragha pepe hutangaza vitalu vya CIDR vinavyohusiana na VPC yake; jedwali la njia la subneti huamua mzigo wa kazi hutuma jibu wapi. Kuchukua la pili kama njia ya kubadilisha la kwanza ni kosa la kawaida zaidi katika utambuzi huu. Tekeleza ukaguzi ulio hapa chini kwa mpangilio na utenganishe mielekeo miwili.

Taja kiambatisho kabla ya kusoma jedwali lolote

VPN ya tovuti-hadi-tovuti huishia kwenye lango la faragha pepe au lango la usafirishaji, na vitambulisho vya rasilimali huamua ni mfumo gani wa njia unaotumika. Visome kwanza: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Jibu linakuambia kama jedwali linalofuata la kukagua ni jedwali la njia la VPC au jedwali la njia la lango la usafirishaji.

Ikiwa VPN imeambatishwa kwenye lango la usafirishaji, acha kuchukua jedwali la njia la VPC kama tabaka la udhibiti. Huko jedwali la VPC linaelekeza kwenye kiambatisho cha lango, na uhusiano na uenezaji hufanyika katika jedwali la njia la lango la usafirishaji. Kuchanganya mitazamo miwili hutoa hitimisho la uhakika kuhusu kitu kisichofaa.

Mwelekeo kutoka AWS kuelekea ofisini ni tangazo

Kwa kiambatisho cha VGW, lango hutangaza vitalu vya CIDR vinavyohusiana na VPC yake kwa lango la mteja kupitia BGP. Kuongeza njia moja ya subneti, au kuelekeza njia kwenye VPC iliyooanishwa au kifaa, hakuongezi CIDR nyingine inayohusiana na hakuonekani katika tangazo hilo. Ikiwa ofisini kinakosekana kiambishi awali, linganisha orodha ya njia zilizopokelewa na uhusiano wa VPC kabla ya kuhariri jedwali lolote la njia.

Kanuni rahisi ina istisna, kwa hiyo iweke ndani ya wigo wake. Mpangilio wa VPN CloudHub unaweza kutangaza upya viambishi awali vya tovuti kati ya lango za wateja, na lango la usafirishaji hufuata kanuni zake za uenezaji. Kauli kwamba VGW hutangaza VPC yake tu ni chaguo-msingi lenye manufaa, si sheria inayoshughulikia kila topolojia utakayokutana nayo.

Mwelekeo kutoka ofisini kuelekea AWS ni uenezaji pamoja na uteuzi

Katika mwelekeo kinyume VGW hujifunza kiambishi awali cha ofisi, lakini hilo peke yake hakisogezi mzigo wa kazi. Jedwali la njia la subneti lazima liwe na uenezaji umewashwa kwa kiambatisho au libebe njia tuli kuelekea lengo lilelile. Wakati vyote viwili vipo kwa kiambishi awali kimoja, njia tuli hushinda, na ulinganishaji wa kiambishi awali kirefu zaidi hufanyika kabla ya vyote viwili.

Soma asili badala ya kuifikiria: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Ingizo lenye asili EnableVgwRoutePropagation lilitoka BGP; ingizo lenye asili CreateRoute liliandikwa na mtu na litaendelea kushinda hadi mtu afute.

Kitabu cha uendeshaji kinachotenganisha mielekeo miwili

Andika ukweli nne upande wa AWS kabla ya kubadilisha chochote: aina ya kiambatisho, CIDR za VPC zinazohusiana, asili ya njia ya subneti kwa kiambishi awali husika, na hali ya handaki na BGP. Wito huo huo wa describe hurudisha VgwTelemetry na hesabu ya njia zilizokubaliwa kwa kila handaki, ambayo inakuambia kama AWS ilikubali njia zozote kabisa. Kisha linganisha hilo na kile kifaa cha mteja kilichosakinisha kweli. Kiambishi awali kilichopo katika BGP lakini hakipo katika jedwali la upelekaji ni tatizo la uingizaji wa ndani au njia bora, si tatizo la jedwali la njia la AWS.

Ikiwa jedwali la subneti halina kiambishi awali kabisa, washa uenezaji au ongeza njia tuli, kisha soma tena swali lilelile baada ya muda wa uenezaji badala ya kudhani mabadiliko yalikuwa ya papo hapo. Ikiwa kiambishi awali kipo na trafiki bado inashindwa, acha tabaka la udhibiti na uende kwenye njia ya data.

Nini usibadilishe ukiwa huko

Usiwasha au kuzima uenezaji kwenye majedwali ya njia yasiyohusiana ili kurekebisha kiambishi awali kimoja kinachokosekana, na usiongeze njia chaguo-msingi ili kufunika CIDR moja isiyopo. Mabadiliko yote mawili yanapanua wigo wa athari na kufanya utambuzi unaofuata kuwa mgumu. Weka uhariri kwenye jedwali linalohudumia subneti ya mzigo wa kazi husika tu.

Njia ya data imetenganishwa na haya yote. Vikundi vya usalama vina hali, ACL za mtandao hazina, na firewall ya mwenyeji au njia ya kurudi isiyolingana inaweza kuacha trafiki ambayo uelekezaji uliwasilisha kwa usahihi. Muunganiko uliotangazwa pia hauidhinishi kila huduma ndani yake, kwa hiyo punguza ufikiaji kwenye mpaka wa sera badala ya kutegemea kama anwani inaonekana kwa bahati katika tangazo la BGP.

Hifadhi kabla na baada ya kila hoja ya jedwali la njia katika rekodi ya mabadiliko. Ikiwa mabadiliko yanafanya mambo kuwa mabaya zaidi, rejesha njia za awali na uthibitishe na hoja ilelile, kwa sababu urejeshaji ambao huwezi kuuthibitisha ni dhana tu.