AWS Site-to-Site VPN hadi NAT Gateway: VGW dhidi ya Transit Gateway

Kila mtu huchora mchoro ule ule mara ya kwanza: VPN ndani ya VPC, NAT gateway nje hadi intaneti, imekamilika. Lakini AWS haitumii njia hiyo wakati VPN inaishia kwenye virtual private gateway, na hitilafu ni ya kimya kiasi kwamba timu huijenga upya zaidi ya mara moja. Muundo unaofanya kazi unahitaji transit gateway, ambao hubadilisha gateway na majedwali ya njia pande zote mbili. Linganisha maumbo mawili kabla ya kuchora chochote.

Topolojia inayoonekana wazi na isiyotumika

Nyaraka za NAT gateway za AWS huchora mstari unaowashangaza wote waliojenga miundo ya VPC moja pekee: trafiki kutoka muunganisho wa Site-to-Site VPN haiwezi kuelekezwa kwa NAT gateway kupitia virtual private gateway. Aina ya gateway ambayo VPN inaishia ndiyo inayoamua kama njia ya tafsiri ipo kabisa. Hitilafu inaendelea kwa sababu hali ya handaki ni UP na EC2 instance katika subnet hiyo hiyo hufikia intaneti bila shida. Hakuna moja ya uchunguzi huo miwili unaojaribu mwelekeo uliovunjika.

Kwa vitendo pakiti hufika na anwani ya chanzo kutoka mtandao wa ndani na haipati hop inayofuata inayotumika ambayo ingeitafsiri. Kulingana na majedwali, hutupwa kwenye mpaka wa kutoka, na kwa kuwa handaki linabaki UP wakati instance katika subnet hiyo hiyo inafikia intaneti, hitilafu huripotiwa kama tatizo la firewall ya ndani.

Virtual private gateway dhidi ya transit gateway

Virtual private gateway ni ya VPC moja. Inamaliza VPN, inaweka njia kwenye majedwali ya njia ya VPC hiyo, na inasimama hapo. Haina modeli ya attachment, kwa hiyo haiwezi kuwasilisha trafiki kwa VPC nyingine au sehemu ya kutoka inayoshirikiwa. Upeo huu wa VPC moja ndio kikomo chote, na hakuna njia unayoongeza ndani ya VPC inayobadilisha hilo.

Transit gateway ni kitovu cha kikanda ambapo VPN, kila spoke VPC na VPC ya huduma zinazoshirikiwa zote huonekana kama attachments. Ina majedwali yake ya njia yanayochagua attachment ipi inapokea prefix fulani.

Kitovu hicho ndicho kinachowezesha kutoka kwa njia ya kati: VPN inatua kama attachment moja, VPC ya kutoka kama nyingine, na jedwali la njia la transit gateway hutuma prefixes zinazoelekea intaneti kutoka ya kwanza hadi ya pili. Kwa virtual private gateway hakuna attachment ya pili ya kutumia kitu, ndiyo sababu muundo hauwezi kurekebishwa baadaye.

Njia ya kutoka inayotumika, hatua kwa hatua

Muundo wa marejeleo una hops tano na kila mshale ni uamuzi wa uelekezaji ambao lazima uusanidi. Trafiki inatoka mtandao wa ndani kuingia attachment ya Site-to-Site VPN, jedwali la transit gateway linaipeleka kwa attachment ya VPC ya kutoka, ambapo jedwali la subnet linaituma kwa NAT gateway ya umma. NAT gateway inatafsiri chanzo na internet gateway inachukua pakiti nje.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Mambo mawili huamua kama hops za mwisho zitafanya kazi. NAT gateway lazima iwe ya umma, ikiwa na elastic IP na njia kwa internet gateway, kwa sababu NAT gateway ya kibinafsi hufanya tafsiri kati ya mitandao na haifanyiki kamwe kuwa njia ya kutoka intaneti.

Panga NAT gateway moja kwa kila Availability Zone unayokusudia kuhudumia, na kila jedwali la subnet lielekee la ndani. Weka jedwali la transit gateway na majedwali ya VPC kama vitu tofauti katika maelezo yako, kwa sababu moja huchagua attachment na lingine huchagua rasilimali ndani ya VPC. Njia ya chaguo-msingi katika moja tu yao huacha nusu ya njia isiyoelezwa na huzalisha hitilafu za sehemu ambazo ni ngumu zaidi kuhusisha.

Miundo hii hushindwa kwenye njia ya kurudi

NAT gateway huhifadhi hali kwa mtiririko ambao tayari umeuona, kwa hiyo majibu ya muunganisho wa kutoka hurudi bila kanuni mpya ya kuingia. Sifa hiyo haichapishi huduma ya ndani kwenye intaneti, na kuichukulia kama inafanya hivyo hugharimu timu siku moja kutatua muunganisho ambao haungeundwa kamwe. Kwa trafiki inayoanzishwa na mteja, njia nne lazima zikubaliane: sera ya ndani, jedwali la transit gateway, jedwali la subnet ya kutoka na jedwali la subnet ya NAT. Ukikosa la mwisho, ombi linaondoka jengo wakati jibu linakufa ndani ya AWS.

Thibitisha kwa mteja halisi nyuma ya VPN na uangalie anwani gani ya chanzo ya umma anayowasilisha. Ikiwa ni elastic IP ya NAT gateway, tafsiri inafanyika; ikiwa ni kitu kingine, unapima njia nyingine ya kutoka.

Toleo lisilo na ulinganifu la hitilafu hii linafaa kutambuliwa mapema. Wakati jedwali la subnet ya NAT la Availability Zone moja lina njia ya kurudi kwa prefix ya mteja na lingine halina, muunganisho mpya hufanikiwa au kushindwa kulingana na eneo ambalo mtiririko unaangukia, na muundo huo husomwa vibaya kama intaneti isiyo imara. Linganisha majedwali ya subnet kwa kila eneo unalohudumia badala ya kurekebisha lile ambapo tikiti ilifunguliwa, kwa sababu njia inayokosekana ndio hitilafu yote na upande wa pili hakuna kinachohitaji kubadilishwa.

Wakati proxy iliyo wazi ndio muundo bora

HTTP proxy kwenye instance katika VPC ya kutoka ni mbadala halali na mara nyingi wa bei nafuu. Wateja husanidiwa kuutumia, proxy hufungua muunganisho wake mwenyewe kwenda nje, na njia ya kurudi inakuwa tatizo lake badala ya fumbo la uelekezaji linganifu. Kwa programu chache hii huondoa sehemu kubwa ya kazi ya transit gateway. Pia hutoa kumbukumbu kwa kila mtumiaji ambazo NAT gateway haiwezi kuzalisha.

Hata hivyo si wazi. Kitu chochote kinachopuuza mipangilio ya proxy, na kila itifaki isiyo HTTP, haitafuata njia hiyo.

Uchaguzi unategemea kile ambacho programu zako huzungumza kweli na ni kiasi gani cha utambulisho unachohitaji kwenye kumbukumbu. Wanapozungumza HTTP, proxy hupata nafasi yake; unapohitaji njia ya jumla kwa itifaki yoyote, muundo wa transit gateway ndio unaotumika kwa AWS. Kuamua hilo mapema ni nafuu kuliko kugundua baada ya majedwali ya njia kujengwa.