Pagdaragdag ng lokal na subnet sa isang AWS VPN: VGW kumpara sa Transit Gateway
Sinasabi ng anunsyo ng BGP sa AWS kung saan ipapadala ang mga packet; hindi ito gumagawa ng lokal na landas. Suriin ang hangganan ng VGW o transit gateway, pagkatapos ang patakaran ng pagbabalik.
May umiiral na Site-to-Site VPN na nagdadala ng 10.60.0.0/16, may bagong serbisyo network na lumilitaw sa likod ng parehong lokal na gateway bilang 10.70.0.0/16, at may nagtatanong kung kailangan ng proxy. Karaniwang hindi: kayang dalhin ng ruta ang prefix, pero kung tatlong bagay ang magtugma lamang, at kung aling tatlo ay nakadepende sa AWS architecture na pinapatakbo mo na. Ang virtual private gateway ay may isang hangganan ng routing table; ang transit gateway ay nagdadagdag ng pangalawa. Tamang anunsyo at maling table ay nagbubunga ng session na mukhang maayos at walang naipapadala.
Ilathala ang prefix na talagang kayang ihatid ng gateway
Kailangan ng lokal na gateway ng landas patungo sa bagong network bago maging makabuluhan ang anumang anunsyo. Ang pag-anunsyo ng 10.70.0.0/16 sa pamamagitan ng BGP ay nagsasabi sa AWS kung saan ipapadala ang mga packet para sa saklaw na iyon; hindi nito ginagawa ang lokal na daan ng pagpapasa na nagpapabukas ng saklaw sa kabilang dulo. Tiyakin na may ruta ang gateway para sa prefix na tumuturo sa device na may hawak nito, at ang device ay naka-configure na tumugon para sa mga address na iyon. Ang patakaran ng pag-export at mga tinatanggap na limitasyon ng prefix ang susunod na hadlang, dahil ang prefix na sinasala ng session ay hindi umaabot sa AWS.
Panatilihing sinadya ang mga aggregate at mas tiyak na ruta. Ang mga rutang nagsasapawan na nagmumula sa dalawang direksyon ay desisyon sa disenyo, hindi detalyeng matutuklasan mamaya.
Landas isa: ang hangganan ng virtual private gateway
Sa virtual private gateway, inilalarawan ng dokumentasyon ng routing ng AWS VPN ang dalawang paraan ng pamamahagi, static na ruta at anunsyo ng BGP, at pareho silang nakadepende sa routing table ng subnet na aktwal na ginagamit ng application. Maginhawa ang pagpapalaganap kapag kontrolado mo ang buong saklaw, at mas madaling isipin ang tahasang ruta kapag gusto mong nakalista ang destinasyon sa tabi ng target. Anuman ang kaso, isa lang ang pagsusuri: may gumaganang landas ba patungo sa target ng VPN para sa bagong prefix ang table ng partikular na subnet ng application, at natatalo ba nito ang anumang mas tiyak?
Pinatutunayan ng maayos na session ng BGP na mayroon ang channel. Wala itong sinasabi tungkol sa kung kinuha ng isang table ng subnet ang ruta.
Landas dalawa: nagdadagdag ng table ang transit gateway
Hinahati ng transit gateway ang nag-iisang tanong na iyon sa dalawa. Kailangang ipadala ng subnet ng VPC ang destinasyon sa attachment ng transit gateway, at pagkatapos ay kailangang piliin ng routing table ng transit gateway ang attachment ng VPN para sa parehong prefix. Ang mga pagpipilian sa asosasyon at pagpapalaganap ang nagtatakda kung aling mga nakakabit na network ang makakakuha ng ruta, kaya ang isang prefix ay maaaring maanunsyo nang tama ng VPN at gayunpaman ay hindi kailanman makarating sa VPC na ang table ay hindi kailanman iniugnay sa tamang routing table.
Ang karaniwang kabiguan ay isang rutang umiiral sa isang table at wala sa isa, habang bawat koponan ay kumbinsido na tama ang kanilang panig. Kapag inihambing mo ang dalawang arkitektura, ang karagdagang hangganang ito ang buong pagkakaiba: mas maraming lugar na titignan, at mas tiyak na kontrol sa kung sino ang makakakuha ng ruta.
Ang pagpapalaganap ng ruta ay hindi rin nagbibigay ng prefix sa bawat attachment. Ipinamimigay ito sa mga table na naka-configure na tumanggap nito.
Ang landas ng pagbabalik ay sariling desisyon sa patakaran
Ang trapikong dumarating ay kalahati lamang ng palitan. Kailangan ng bagong lokal na network ng landas pabalik sa mga source prefix ng AWS sa pamamagitan ng tamang gateway, at dapat pahintulutan ng patakaran ng seguridad sa magkabilang dulo ang pares na iyon ng source at destinasyon. Kung nakikipag-usap ang tunnel sa saklaw ng proteksyon gamit ang mga tagapili ng trapiko, kailangang nasa loob nito ang bagong prefix, kung hindi ay itinatapon ang packet bago pa tingnan ang anumang routing table.
Ang pagsasapawan ng address ang isa pang bitag. Ang magkahiwalay at tahasang pag-aaring saklaw ay nagpapanatiling simple nito; ang nagsasapawang saklaw ay nangangahulugan ng pagsasalin o muling disenyo, at wala sa dalawa ang mapagpapalit na bersyon ng parehong resipe.
Subukan gamit ang source sa bagong network at destinasyon sa subnet ng application, pagkatapos ay ulitin sa kabilang direksyon. Ang isang-direksyong pagsubok ay nagpapatunay lamang ng isang direksyon.
Kailan tunay na mas mahusay na hangganan ang proxy
Nakukuha ng proxy ang lugar nito kapag ang pangangailangan ay makitid na interface ng serbisyo, kapag inaasahan na ng application ang arkitekturang iyon, o kapag hindi magawang dalhin ng landas ng network ang prefix nang walang pagsasaling hindi mo gusto. Hindi ito ang pantulong na solusyon para sa entry sa routing table na walang sinumang tumingin.
Magpasya sa ganitong pagkakasunod-sunod: lokal na pagpapasa, anunsyo, hangganan ng table, patakaran ng pagbabalik. Ayusin ang unang nabigo, at pagkatapos lamang itanong kung ang rutang dinaanan ay siya nga ang tamang sagot.