AWS Site-to-Site VPN تر NAT Gateway: VGW یا Transit Gateway

ټول لومړی ځل هماغه ډیاګرام کاږي: VPN VPC ته، بیا NAT gateway انټرنیټ ته، تمام. خو AWS هغه لار نه ملاتړ کوي کله چې VPN په virtual private gateway پای ته رسېږي، او ناکامي دومره غلې ده چې ټیمونه یې له یو ځل ډېر بیا جوړوي. هغه ډیزاین چې کار کوي transit gateway ته اړتیا لري، او دا د دواړو خواوو gateway او route tables بدلوي. د هر څه کاږلو دمخه دواړه بڼې پرتله کړئ.

هغه ټوپولوژي چې ښکاره ښکاري خو ملاتړ نه لري

د AWS NAT gateway اسناد یوه کرښه کاږي چې هر هغه څوک حیرانوي چې یوازې د یو VPC ډیزاینونه جوړ کړي: د Site-to-Site VPN اړیکې ترافیک نشي کولی د virtual private gateway له لارې NAT gateway ته route شي. د gateway هغه ډول چې VPN پرې پای ته رسېږي دا فیصله کوي چې آیا د ژباړې لار شته که نه. غلطي پاتې کېږي ځکه چې د تونل حالت UP دی او په هماغه subnet کې EC2 انسټنټس پرته له ستونزې انټرنیټ ته رسېږي. له دواړو کتنو څخه هیڅ یوه هم مات شوې لوري نه ازمویي.

په عمل کې پاکټ د محلي شبکې د سرچینې پتې سره راځي او هغه ملاتړ شوی بل hop نه مومي چې ژباړه یې کړي. د جدولونو له مخې په egress پوله غورځول کېږي، او ځکه چې تونل UP پاتې کېږي او په هماغه subnet کې انسټنټس انټرنیټ ته رسېږي، ناکامي د محلي firewall ستونزه بلل کېږي.

Virtual private gateway د transit gateway په وړاندې

یو virtual private gateway یوازې د یو VPC دی. دا VPN پای ته رسوي، په هغه VPC کې routes ځای پرځای کوي او هماغه ځای ودريږي. د attachment ماډل نه لري، نو ترافیک نه شي کولی بل VPC یا شریک egress برخې ته وسپاري. همدا د یو VPC حد ټوله محدودیت دی، او په VPC کې دننه اضافه شوی هیڅ route دا نه بدلوي.

Transit gateway یو سیمه ایز مرکز دی چېرې چې VPN، هر spoke VPC او د شریکو خدماتو VPC ټول د attachment په توګه ښکاري. دا خپل route tables لري چې ټاکي کوم attachment یو ورکړل شوی prefix اخلي.

همدا مرکز مرکزي egress ممکنوي: VPN د یو attachment په توګه ځای پرځای کېږي، egress VPC د بل په توګه، او transit gateway route table د انټرنیټ په لور prefixes له لومړي څخه دویم ته لېږي. د virtual private gateway سره د لېږلو لپاره دویم attachment نشته، له همدې کبله ډیزاین وروسته پیچ کېدلی نه شي.

ملاتړ شوې egress لار، ګام په ګام

مرجع ډیزاین پنځه hops لري او هر غشي یو route پرېکړه ده چې تاسو یې باید تنظیم کړئ. ترافیک د محلي شبکې څخه Site-to-Site VPN attachment ته وځي، transit gateway route table هغه egress VPC attachment ته لېږي، چېرې چې subnet جدول هغه عامه NAT gateway ته لېږي. NAT gateway سرچینه ژباړي او internet gateway پاکټ بهر بوځي.

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

دوه ځانګړنې فیصله کوي چې وروستي hops کار کوي که نه. NAT gateway باید عامه وي، د elastic IP او internet gateway ته د route سره، ځکه چې خصوصي NAT gateway د شبکو ترمنځ ژباړه کوي او هیڅکله د انټرنیټ وتل نه شي کېدای.

د هر Availability Zone لپاره چې غواړئ خدمت ورته وکړئ یو NAT gateway پلان کړئ، او هر subnet جدول محلي ته اشاره وکړي. په خپلو یادښتونو کې transit gateway جدول او VPC جدولونه جلا شیان وساتئ، ځکه یو attachment او بل د VPC دننه سرچینه ټاکي. یوازې په یوه کې default route پاتې کېدل نیمه لار ناڅرګنده پرېږدي او هغه جزوي ناکامۍ جوړوي چې نسبت ورکول یې تر ټولو ستونزمن دي.

همدا ډیزاینونه د بېرته راتلو په لار کې ناکامېږي

NAT gateway د هغو flows لپاره چې مخکې یې لیدلي stateful دی، نو د وتونکې اړیکې ځوابونه پرته له نوي inbound قاعده بېرته راځي. هغه ځانګړنه کوم محلي خدمت انټرنیټ ته نه خپروي، او داسې انګېرل چې خپروي یې، ټیم دې ته اړ باسي چې یوه ورځ د هغې اړیکې په ډیبګ کې تېره کړي چې هیڅکله به نه جوړېده. د پیرودونکي له خوا پیل شوي ترافیک لپاره څلور routes باید سره سمون ولري: محلي تګلاره، transit gateway جدول، egress subnet جدول او NAT subnet جدول. وروستی پاتې شي نو غوښتنه ودانۍ پرېږدي او ځواب د AWS دننه مري.

د VPN شاته ریښتیني پیرودونکي سره تایید کړئ او وګورئ کوم عامه سرچینه پته ښیي. که هغه د NAT gateway elastic IP وي، ژباړه کېږي؛ که بل څه وي، تاسو بله egress اندازه کوئ.

د دې ناکامۍ غیر متقارن بڼه باید ژر وپیژندل شي. کله چې د یو Availability Zone NAT subnet جدول د پیرودونکي prefix ته د بېرته راتلو route ولري او بل نه لري، نوي اړیکې د دې له مخې بریالۍ یا ناکامېږي چې flow په کومه سیمه کې غورځي، او دا بڼه په غلطه توګه د بې ثباته انټرنیټ په توګه لوستل کېږي. د ټکټ خلاصې سیمې د سمولو پرځای هغه هرې سیمې subnet جدولونه پرتله کړئ چې خدمت ورته کوئ، ځکه ورک route ټول عیب دی او بلې خوا ته هیڅ بدلون ته اړتیا نشته.

کله روښانه proxy غوره ډیزاین وي

د egress VPC په انسټنټس باندې HTTP proxy قانوني بدیل دی او ډېری وخت ارزانه. پیرودونکي د هغې د کارولو لپاره تنظیمېږي، proxy خپله اړیکه بهر ته پرانیزي، او د بېرته راتلو لار د متقارن routing معما نه بلکې د proxy ستونزه کېږي. د لږو اپلیکیشنونو لپاره دا د transit gateway ډېره برخه کار لرې کوي. دا د هر کارونکي لپاره logging هم ورکوي چې NAT gateway یې نه شي تولیدولی.

خو دا روڼ نه دی. هر څه چې د proxy تنظیمات له پامه غورځوي، او هر پروتوکول چې HTTP نه وي، دې لارې به نه ځي.

ټاکنه په دې پورې ده چې ستاسو اپلیکیشنونه واقعاً څه وایي او په logs کې څومره پیژندنه ته اړتیا لرئ. چېرې چې HTTP وایي هلته proxy خپل ځای ګټي؛ چېرې چې د خپل سري پروتوکولونو لپاره عمومي egress ته اړتیا وي، هغه ډیزاین چې AWS ملاتړ کوي transit gateway دی. دا له مخکې فیصله کول د route tables له جوړولو وروسته کشف کولو څخه ارزانه دي.