AWS Client VPN یا bastion د peered VPC ته رسېدو لپاره

یو Client VPN endpoint کولی شي هغه VPC ته ورسېږي چې د خپل تړلي VPC سره peered دی، او د دې قانوني کولو لپاره bastion ته اړتیا نه لرئ. هغه انتخاب چې د کولو ارزښت لري دا دی چې ترافیک چېرته لاس بدلوي: endpoint لاره چې په association subnet کې کښېږي او peering اړیکه تېروي، یا په peered VPC کې host چې session پای ته رسوي. دواړه لارې کار کوي او په بېلو ځایونو کې ناکامېږي، نو پریکړه د مالکیت او پلټنې په اړه ده، نه د دې په اړه چې AWS څه اجازه ورکوي. دلته هغه څه دي چې زه څنګه د دوی ترمنځ غوره کوم، او هغه څلور ننوتنې چې routed لاره کاروي.

دوه لارې، یو endpoint، بېل مالکان

په routed لاره کې د کلینټ ترافیک endpoint ته رسېږي، په association subnet کې د Client VPN شبکې انټرفیس پتې ته ژباړل کېږي، او له A څخه B ته د peering اړیکې له لارې له دې subnet څخه وځي. VPC B هېڅ VPN session نه پای ته رسوي؛ دا له VPC A څخه عادي ترافیک ویني، ځکه چې د دې د بېرته راتګ لاره VPC A ته اشاره کوي، نه د کلینټ pool ته.

په bastion لاره کې کلینټ لومړی host ته رسېږي. په A کې bastion لا هم وروستی ټوپ د peering اړیکې له لارې تېرېږي، نو peering کار پاتې کېږي او یو session ورزیاتېږي. په B کې bastion هم له کلینټ څخه لاره غواړي، او کله چې هغه لاره همدا endpoint لاره وي، routed ډیزاین ته یو ټوپ ورزیاتېږي. bastion یوازې هغه وخت کار کموي چې دا له مخکې شتون ولري، له مخکې تصویب شوی وي، او د دې شاته شی ته د شبکې حد پرځای د session حد ته اړتیا وي.

څلور ننوتنې routed لاره کاروي

AWS دا سناریو په Client VPN how-it-works پاڼه کې مستند کوي، او په عمل کې دوه یا درې ټیمونو ته اړوندو څلورو ننوتنو ته رسیږي. ساحې د بېلګې په توګه دي؛ peered ساحه باید یوازې وي او د بېرته راتګ ساحه باید ستاسو له پلان سره سمه وي.

لاره او اجازه جلا کنټرولونه دي. سم endpoint لاره پرته له سمونې اجازې قاعدې کلینټ ته هېڅ نه ورکوي؛ د هغه منزل لپاره اجازه قاعده چې endpoint یې نشي رونې کولی، هغه ته توره سوري ورکوي. دواړه باید یوه ساحه ونومي.

endpoint لاره د endpoint خپل VPC کې subnet ته اشاره کوي، هېڅکله peering اړیکې ته نه. د VPC لارو جدولونه peering اړیکې ته اشاره کوي، هېڅکله instance یا انټرفیس ته نه. د دواړو ترمنځ ارزښت کاپي کول پرته له شکایت خوندي کېږي او هېڅ نه رونې کوي.

ځکه چې association subnet د کلینټ سرچینه ژباړي، B باید د کلینټ pool ته نه، بلکې VPC A ته بېرته ورسیږي. د peering اړیکې له لارې د کلینټ ساحې لېږل همغږي ښکاري، بیاکتنه تېروي او په خاموشۍ ناکامېږي ځکه چې B هېڅکله د کلینټ سرچینې لرونکی پاکټ نه ویني.

د امنیت ډلې او د اجازې وروستی متر

رونه پاکټونه B ته رسوي؛ پریکړه B لا هم کوي. په همدې سیمه کې د فعالې peering اړیکې لپاره، په B کې امنیتي ډله کولی شي Client VPN association باندې تطبیق شوې ډلې ته اشاره وکړي، چې قاعده تنګ ساتي او د پتو بدلونونو ته درېږي. چېرته چې د ډلې اشاره ممکنه نه وي، د 0.0.0.0/0 ته پراخولو پرځای د association subnet ساحه په ښکاره ډول اجازه کړئ، ځکه چې دا د رونې تېروتنه په بې توضیح timeout بدلوي.

بیا هغه څه وګورئ چې رونه هېڅکله نه یې لمس کوي: په دواړو subnetونو کې شبکه ACLونه، د اپلیکیشن allow-list یا د token اورېدونکي، او DNS. peering شخصي هوسټ شوې زونونه کاپي نه کوي، نو لیپ ټاپ کولی شي هغه پتې ته کاري لاره ولري چې نشي حل کولی، او peering اړیکه سند ته باور نه ورزیاتوي. endpoint هغه resolver ته اشاره کړئ چې د B لپاره ځواب وایي، بیا تایید کړئ چې شخصي نوم او سند سره سمون لري.

کله bastion صادق ځواب دی

زه د bastion په قصد غوره کولو لپاره درې محرکونه ساتم. peered VPC د هغې ډلې دی چې ستاسو ساحې لپاره د بېرته راتګ لاره نه ورزیاتوي یا د ډلې اشاره نه مني. لاسرسی باید هر session لپاره تصویب یا ثبت شي او اپلیکیشن دا پخپله نشي پورته کولی. یا وروستی ټوپ باید د B دننه پاتې شي ځکه چې خدمت یوازې هماغه ځای حل کېږي او د هغې TLS هویت یو داخلي نوم ته pinned دی.

له دې څخه هېڅ هم د دې حقیقت څخه تېښته نه ده چې peering انتقالي نه دی. غیرانتقالیت محدودوي چې په B کې سرچینې څه کولی شي: دوی نشي کولی A د دریم VPC ته د ترانزیټ په توګه وکاروي چې A ورسره peering لري. دا هېڅکله د دې معنا نه وه چې VPN کاروونکی نشي کولی مستقیم peered VPC ته ورسېږي، او هغه bastion چې د دې غلطې لوستنې د تېښتې لپاره جوړ شوی، هغه host دی چې بې سببه patch کېږي.

مخالف تېروتنه په وخت کې ډېره لګښت لري: هر ټیم له هغه یوازیني bastion څخه تېر کړئ چې له مخکې شتون لري، بیا ومومئ چې د هغې امنیتي ډله، د لارو جدول او د patch کړکۍ تولیدي تړاو دی. ولیکئ چې host کوم محرک ته خدمت کوي، او کله چې محرک ولاړ شي له کاره یې وباسئ.

Transit Gateway او څو association حساب بدلوي

که endpoint د subnet پرځای مستقیم Transit Gateway سره تړلی وي، ماډل بدلېږي: کلینټ نور په association subnet کې انټرفیس پتې ته نه ژباړل کېږي، او د gateway لارو جدولونه باید د کلینټ ساحه او هغه نښلون چې peered VPC ته وړي دواړه وړي. دا په کچه پاک دی، خو کار له څلورو ننوتنو د gateway لارو جدولونو ته ځي.

څو association ازموینې ضربوي. endpoint لاره د endpoint ده، خو هر association subnet ته د ریښتیني peering راتلونکي ټوپ سره لارو جدول ته اړتیا ده. session کولی شي د یوې association له لارې بریالی شي پداسې حال کې چې بل ته د بېرته راتګ لاره نه وي، نو هر یو وآزمویئ.

د ماتې ژر موندلو د تایید ترتیب

دا په ترتیب سره چلوئ؛ هر ګام کولی شي تېر شي پداسې حال کې چې بل ناکامېږي، او د کلینټ timeout تقریبا هېڅکله نه وایي چې کوم مات شو.

1. له کلینټ څخه د اپلیکیشن نوم حل کړئ او وګورئ چې پته د peered ساحې دننه ده.
2. نښلئ، بیا د هغې association لپاره چې session یې پای ته رسولی endpoint د نښلون ثبت ولولئ.
3. په هغه association subnet کې تایید کړئ چې د لارو جدول peered ساحه فعالې peering اړیکې ته اشاره کوي.
4. په B کې د سرچینو subnet کې، د انټرفیس ساحې لپاره د بېرته راتګ ننوتنه او سمونې ډلې قاعدې تایید کړئ.
5. یو اجازه شوی عملیات او یو هغه سرچینه وآزمویئ چې باید نه رسېدونکې پاتې شي؛ دوهمه د ډیبګ پاتې شونې نیسي.
6. له هر split-tunnel لارې بدلون وروسته بیا ونښلئ، ځکه چې روان ټنل نوی لارو سیټ نه اخلي.

دوه نښې د یادولو ارزښت لري. هغه SYN چې پرته له ځواب B ته رسېږي تقریبا تل ورکه شوې د بېرته راتګ لاره ده. هغه نښلون چې بشپړ شي او بیا ریسیټ شي معمولا ډله، ACL یا اپلیکیشن وي. هېڅ یو یې په endpoint ثبت کې د لامل په توګه نه ښکاري، نو څلور ننوتنې د هر یو ترڅنګ مالک سره وساتئ.

که له درې محرکونو هېڅ یو هم نه وي، routed لاره بشپړه کړئ او هغه څلور ننوتنې ثبت کړئ. که یو وي، bastion یوازې د هغه حد لپاره وساتئ او endpoint لاره هغو خدمتونو ته پرېږدئ چې مخې ته session ته اړتیا نه لري.