AWS Client VPN au bastion kufikia VPC yenye peering
Njia zote mbili zinafanya kazi, lakini zinavunjika mahali tofauti. Linganisha njia za endpoint, uelekezaji wa kurudi na hali tatu ambapo bastion ni mpaka wa uaminifu.
Endpoint moja ya Client VPN inaweza kufikia VPC inayofanya peering na VPC yake inayohusiana, na huhitaji bastion kuifanya hiyo kuwa halali. Uchaguzi unaostahili kufanywa ni wapi trafiki inabadilisha mikono: njia ya endpoint inayotua kwenye subnet ya ushirika na kuvuka muunganisho wa peering, au host katika VPC yenye peering inayomaliza kikao. Njia zote mbili zinafanya kazi na zinashindwa mahali tofauti, kwa hiyo uamuzi ni kuhusu umiliki na ukaguzi, si kuhusu kile AWS inaruhusu. Hapa ni jinsi ninachagua kati yao, na maingizo manne yanayofanya njia iliyoelekezwa ifanye kazi.
Njia mbili, endpoint moja, wamiliki tofauti
Kwenye njia iliyoelekezwa trafiki ya mteja inafikia endpoint, inatafsiriwa kuwa anwani ya kiolesura cha mtandao wa Client VPN katika subnet ya ushirika, na inaondoka kwenye subnet hiyo kupitia muunganisho wa peering kutoka A hadi B. VPC B haimalizi kikao chochote cha VPN; inaona trafiki ya kawaida kutoka VPC A, ndiyo sababu njia yake ya kurudi inaelekeza VPC A, si bwawa la wateja.
Kwenye njia ya bastion mteja anafikia host kwanza. Bastion katika A bado inaruhusu hop ya mwisho kuvuka muunganisho wa peering, kwa hiyo unabaki na kazi ya peering na unaongeza kikao. Bastion katika B pia inahitaji njia kutoka kwa mteja, na wakati njia hiyo ni njia hiyo hiyo ya endpoint, una muundo ulioelekezwa pamoja na hop moja. Bastion inaondoa kazi tu wakati ipo tayari, imeidhinishwa tayari, na kitu kilicho nyuma yake kinahitaji mpaka wa kikao badala ya mpaka wa mtandao.
Maingizo manne yanafanya njia iliyoelekezwa ifanye kazi
AWS inaandika hali hii kwenye ukurasa wa Client VPN how-it-works, na kwa vitendo inakuja kwa maingizo manne yanayomilikiwa na timu mbili au tatu. Masafa ni mifano; masafa ya peering lazima yawe ya kipekee na masafa ya kurudi lazima yalingane na mpango wako.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
Njia na ruhusa ni vidhibiti tofauti. Njia sahihi ya endpoint bila kanuni ya uidhinishaji inayolingana haimpi mteja kitu; kanuni ya uidhinishaji kwa lengo ambalo endpoint haiwezi kuelekeza inampa shimo jeusi. Zote mbili lazima zitaje masafa sawa.
Njia ya endpoint inaelekeza subnet katika VPC ya endpoint yenyewe, kamwe si muunganisho wa peering. Jedwali za njia za VPC zinaelekeza muunganisho wa peering, kamwe si instance au kiolesura. Kunakili thamani kati ya hizo mbili huhifadhiwa bila malalamiko na hakuelekezi kitu.
Kwa sababu subnet ya ushirika inatafsiri chanzo cha mteja, B lazima ielekeze kurudi VPC A, si kwenye bwawa la wateja. Kutuma masafa ya wateja juu ya muunganisho wa peering inaonekana linganifu, inapita ukaguzi na inashindwa kimya kwa sababu B haioni kamwe pakiti yenye chanzo cha mteja.
Vikundi vya usalama na mita ya mwisho ya ruhusa
Uelekezaji huleta pakiti ndani ya B; B bado inaamua. Kwa muunganisho hai wa peering katika mkoa huo huo, kikundi cha usalama katika B kinaweza kurejelea kikundi kilichotumika kwenye ushirika wa Client VPN, ambacho hukiweka kanuni nyembamba na hustahimili mabadiliko ya anwani. Ambapo rejeleo la kikundi haliwezekani, ruhusu masafa ya subnet ya ushirika waziwazi badala ya kupanua hadi 0.0.0.0/0, ambayo hubadilisha kosa la uelekezaji kuwa timeout isiyoelezeka.
Kisha angalia kile uelekezaji haugusi kamwe: ACL za mtandao kwenye subnet zote mbili, orodha ya kuruhusiwa au hadhira ya token ya programu, na DNS. Peering hainakili kanda za kibinafsi zilizopangishwa, kwa hiyo kompyuta ndogo inaweza kushikilia njia inayofanya kazi kwa anwani ambayo haiwezi kuisuluhisha, na muunganisho wa peering hauongezi imani kwa cheti. Elekeza endpoint kwa resolver inayojibu kwa B, kisha hakikisha kwamba jina la kibinafsi na cheti vinalingana.
Wakati bastion ni jibu la uaminifu
Ninaweka vichocheo vitatu vya kuchagua bastion kwa makusudi. VPC yenye peering ni ya timu ambayo haitaongeza njia ya kurudi kwa masafa yako au haitakubali rejeleo la kikundi. Ufikiaji lazima uidhinishwe au urekodiwe kwa kila kikao na programu haiwezi kuibeba yenyewe. Au hop ya mwisho lazima ibaki ndani ya B kwa sababu huduma inasuluhishwa hapo tu na utambulisho wake wa TLS umebandikwa kwa jina la ndani.
Hakuna chochote kati ya hivi ni njia ya kuzunguka ukweli kwamba peering si tranzi. Kutokuwa tranzi kunazuia kile rasilimali katika B zinaweza kufanya: haziwezi kutumia A kama tranzi kwa VPC ya tatu ambayo A inafanya nayo peering. Hiyo haijawahi kumaanisha kuwa mtumiaji wa VPN hawezi kufikia VPC yenye peering moja kwa moja, na bastion iliyojengwa kuzunguka usomaji huo mbaya ni host inayopigwa patch bila sababu.
Kosa la kinyume linagharimu zaidi kwa muda: pitisha kila timu kupitia bastion moja iliyopo tayari, kisha ugundue kwamba kikundi chake cha usalama, jedwali la njia na dirisha la patch ni utegemezi wa uzalishaji. Andika ni kichocheo gani host inahudumia, na uiondoe kazini kichocheo kinapotoweka.
Transit Gateway na ushirika kadhaa hubadilisha hesabu
Ikiwa endpoint imeunganishwa moja kwa moja na Transit Gateway badala ya subnet, muundo hubadilika: wateja hawatafsiriwi tena kuwa anwani ya kiolesura katika subnet ya ushirika, na jedwali za njia za lango lazima zibebe masafa ya wateja pamoja na kiambatisho kinachoelekea VPC yenye peering. Hilo ni safi zaidi kwa kiwango, lakini kazi inahamia kutoka maingizo manne hadi jedwali za njia za lango.
Ushirika kadhaa huzidisha ukaguzi. Njia ya endpoint ni ya endpoint, lakini kila subnet ya ushirika inahitaji jedwali la njia lenye hop inayofuata ya peering halisi. Kikao kinaweza kufanikiwa kupitia ushirika mmoja wakati mwingine hauna njia ya kurudi, kwa hiyo jaribu kila kimoja.
Mpangilio wa uthibitishaji unaopata uvunjiko haraka
Endesha hizi kwa mpangilio; kila hatua inaweza kupita wakati inayofuata inashindwa, na timeout ya mteja karibu kamwe haisemi ni ipi iliyovunjika.
- Tatua jina la programu kutoka kwa mteja na uangalie kwamba anwani iko ndani ya masafa ya peering.
- Ungana, kisha soma kumbukumbu ya miunganisho ya endpoint kwa ushirika uliomaliza kikao.
- Kwenye subnet hiyo ya ushirika, hakikisha kwamba jedwali la njia linaelekeza masafa ya peering kwenye muunganisho hai wa peering.
- Kwenye subnet ya rasilimali katika B, hakikisha ingizo la kurudi kwa masafa ya kiolesura na kanuni za kikundi zinazolingana.
- Jaribu operesheni moja iliyoruhusiwa na rasilimali moja ambayo lazima ibaki isifikiki; ya pili inakamata mabaki ya utatuzi.
- Ungana tena baada ya mabadiliko yoyote ya njia ya split-tunnel, kwa sababu handaki inayoendesha haitachukua seti mpya ya njia.
Dalili mbili zinastahili kukumbukwa. SYN inayofikia B bila jibu karibu kila mara ni njia ya kurudi inayokosekana. Muunganisho unaokamilika kisha kuweka upya kwa kawaida ni kikundi, ACL au programu. Hakuna hata moja inayoonekana kwenye kumbukumbu ya endpoint kama sababu, kwa hiyo shikilia maingizo manne na mmiliki kando ya kila moja.
Ikiwa hakuna kichocheo kati ya vitatu kinachotumika, kamilisha njia iliyoelekezwa na urekodi maingizo hayo manne. Ikiwa kimoja kinatumika, shikilia bastion kwa mpaka huo tu na uache njia ya endpoint kwa huduma ambazo hazihitaji kikao mbele yao.