په ډیفالټ ډول، AWS Site-to-Site VPN انتظار کوي تر څو customer gateway خبرې اترې پیل کړي. دا ډیفالټ یو تنظیم دی، نه قانون، او د تنظیم نوم Startup action دی. مخکې له دې چې ورته لاس ووهئ، دوه پوښتنې جلا کړئ چې تل ګډېږي: تونل څوک جوړوي، او ایا هغو پاکټونو چې تاسو ته مهم دي د دې له لارې لاره لري. یوازې لومړی یې د تونل په انتخابونو کې دی.

د پیل کړنه له DPD د وخت پای کړنې جلا کړئ

د هر تونل لپاره دوه انتخابونه دوه بېلې پېښې کنټرولوي، او د یوې ټاکل د بلې په اړه هیڅ نه وایي.

EventOptionUseful values
A new or modified VPN connection needs a tunnelStartup actionadd waits for the peer; start asks AWS to initiate
Dead peer detection times outDPD timeout actionclear ends the session, restart reinitiates, none does nothing

که AWS باید نوی یا بدل شوی تونل پورته کړي، وټاکئ start. که AWS باید د DPD د وخت له پای وروسته خبرې اترې هم بیا پیل کړي، د هغې پېښې لپاره جلا restart تنظیم کړئ. دواړه انتخابونه د اپلیکیشن د بیا هڅې تګلاره نه ده، او هیڅ یو د کیلي د بدلون وقفه نه ده: DPD ګوري چې همکار ژوندی دی که نه، په داسې حال کې چې د کیلي بدلون په فعال تونل کې security associations بدلوي.

هغه اپلیکیشن چې د وخت پای ته رسېږي په داسې حال کې چې تونل لا هم up ښیي، د معلوماتو په لاره کې ستونزه لري. د DPD ټایمر لنډول به یې سم نه کړي، او کېدای شي هغه زوږ را زیات کړي چې وروسته یې تشریح کول ضروري وي.

وګورئ چې AWS د خبرو اترو د لېږلو ځای لري

د AWS له خوا پیل یوازې د IKEv2 سره ممکن دی، او AWS ته د customer gateway عامه پته اړینه ده تر څو پوه شي وړاندیز چېرته ولېږي. تر ټولو دردوونکې پېښه هغه customer gateway سرچینه ده چې پرته له پتې جوړه شوې او د سند له مخې تصدیق شوې: د AWS اسناد د پتې سره نوي customer gateway سرچینې جوړول او بیا د VPN نښلون د هغې پر لور اړول بیانوي.

سند ثابتوي چې همکار څوک دی. دا AWS ته نه وایي چې همکار چېرته دی، او دا دوه بېلې اړتیاوې دي. نو ځکه حل نوی سند نه، بلکې نوې customer gateway سرچینه ده. د سند بدلول AWS د هماغې ورکې موخې سره پرېږدي.

که customer gateway د NAT شاته وي, AWS ته د تنظیم شوې responder identity هم اړتیا ده، IDr, تر څو د همکار هویت د هغه څه سره سم وي چې وسیله یې تمه لري. مخکې له دې چې هغه انتخاب چې همدا اوس مو بدل کړ ملامت کړئ، هغه ارزښت او د اوروژنې هغه لاره تایید کړئ چې د IKE ترافیک تېروي. start ټاکل نشي کولی نه‌رسېدونکی یا ناسم پېژندل شوی همکار اړ کړي چې وړاندیز ومني.

بدلون په یو تونل تطبیق کړئ او د بندېدو تمه لرئ

د VPN نښلون دوه تونلونه لري چې خپلواک انتخابونه لري، نو د باندې پتې له مخې تایید کړئ چې کوم یو سمولئ. AWS اجازه ورکوي چې په یو وخت کې یوازې یو تونل بدل شي، او د ټاکل شوي تونل له لارې نښلون ښايي څو دقیقې پرې شي.

  1. د Site-to-Site VPN نښلون وټاکئ او Modify VPN tunnel options پرانیزئ.
  2. تونل د باندې IP پتې له مخې وټاکئ او د هغه IKE نسخه او customer gateway سرچینه تایید کړئ.
  3. هغه د پیل او DPD کړنې تنظیم کړئ چې واقعاً یې غواړئ، بیا په هغه وخت کې یې خوندي کړئ چې تاسو یې کنټرول لرئ.
  4. تایید کړئ چې بدل شوی تونل جوړېږي، او مخکې له بل بدلون بل تونل او لارښوونه وګورئ.

یو چلند مخکې له ساتنې د پام وړ دی. کله چې د AWS پیل فعال وي هیڅ د وخت پای نشته: AWS تر هغه هڅه کوي چې تونل پورته شي، او بیا پیلېږي کله چې customer gateway د delete-SA پیغام ولېږي. که همکار په قصد بند کړئ، AWS به ټک وهلو ته دوام ورکړي، او د همکار ثبتونه به دا وښیي.

د تونل حالت نه، د اپلیکیشن لاره تایید کړئ

هغه تونل چې up ښیي د هغې غوښتنې سره برابر نه دی چې کار کوي. د VPC سره نښلول شوې Lambda فنکشن لا هم د پیرودونکي مخکښې ته subnet لارې، د ترافیک اجازه ورکوونکو security group او network ACL قاعدو، د سمې پتې راګرځوونکي نوم حل، او د پیرودونکي په خوا کې د راستنېدو لارېته اړتیا لري.

له اپلیکیشن د هغه له شرایطو یو ځل د ریښتیني غوښتنې سره ازموئ، او که پاتې راغی flow logs ولولئ. کله چې د AWS پیل بند وي او بې‌کاره تونل ته د پاتې کېدو لپاره پاکټونه اړین وي، keepalive ترافیک قانوني انتخاب دی، خو باید هغه څارنې پرېکړه وي چې تاسو یې نومولی شئ، نه د فنکشن سره تړل شوی ناتشریح شوی ping څرخ.

لومړی وټاکئ چې تونل څوک جوړوي، بیا پاتې نیمګړتیا د هغې په خپله طبقه کې تشخیص کړئ. د AWS د پیل اړوند اسناد د کونسل د اشارو په پرتله د پتې، هویت او بیا هڅې اړتیاوې په ډېر تفصیل پوښي.

اړوندې مقالې