د AWS Client VPN له لارې ناوبوري لاسرسی: هر نښلول شوی سبنیټ وګورئ
ځینې AWS Client VPN ناستې د اپلیکیشن VPC ته رسېږي او ځینې نور وخت تېرېږي. لومړی د پای نقطې لارې د هر اړیکې د VPC لار جدول سره پرتله کړئ.
یو کاروونکی نښلوي، کورنی اپلیکیشن پرانیزي او ځواب ترلاسه کوي؛ په همدې پای نقطه کې یو همکار په همدې Wi-Fi کې له ورته لپ ټاپ څخه د وخت تېرېدو پیغام ترلاسه کوي. دا بڼه د client VPN پای نقطې نښه ده چې له یوې ډېرې نښلول شوې سبنیټ سره وي، چېرې چې لارې سره برابرې نه دي. زه دا له کنسول څخه بهر ته تعقیبوم، ځکه دوه ټبونه پرېکړه کوي چې پاتې څېړنه ارزښت لري که نه. د کلاینټ په ترتیباتو کې هېڅ شی دا نه تشرېح کوي.
د پای نقطې څخه پیل کړئ او اړیکې ولیکئ
په VPC کنسول کې Client VPN endpoints پرانیزئ، پای نقطه وټاکئ او Associations ټب ولولئ. هره اړیکه په لاسرسي سیمه کې یوه سبنیټ ده، او کلاینټ هغه سبنیټ ته کېږي چې خدمت د اړیکې جوړولو پر مهال ټاکي. د سبنیټ ID او هغه لار جدول ولیکئ چې هر یو یې واقعاً کاروي، ځکه همدا دوه لیستونه هغه پرتله ده چې تاسو یې کوئ.
که پای نقطه یوازې یوه اړیکه وښيي، دا نظریه غلطه ده او کلاینټ غوره شکمن دی.
د پای نقطې لار جدول له هرې اړیکې سره پرتله کړئ
په همدې پای نقطه کې Route table ټب پرانیزئ. هلته هر منزل CIDR یو هدف لري، او په client VPN کې هدف اړیکه ده نه ګېټ وې. AWS د هرې نښلول شوې سبنیټ لپاره د منزل ثبت غواړي، نو هغه لار چې یوازې یوې ته اشاره کوي لاسرسی په دې تکیه کوي چې ناسته چېرې کښېنستله. هغه منزل چې تاسو واقعاً ورته اړتیا لرئ وګورئ، بیا د هغه د اجازې قاعده وګورئ، ځکه لار مسیر برابروي او قاعده پرېکړه کوي چې څوک یې کارولی شي.
کله چې دواړه طبقې په جدول کې راوستل شوې، نیمګړتیا له سترګو تېرول سخت دي.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
په ډېرو ټیکټونو کې دوهمه کرښه ټوله نیمګړتیا ده. د پای نقطې لار شته، نو څوک نور نه ګوري، او پاکټ یو ټوپ وروسته د VPC دننه مري.
هره سبنیټ تر خپل اغېزمن لار جدول پورې تعقیب کړئ
هغه سبنیټ چې د لار جدول څرګنده اړیکه نه لري د VPC اصلي جدول په میراث اخلي. هغه جدول ولولئ چې واقعاً نافذ دی، نه هغه چې نوم یې سم ښکاري، او د کرښې لیبل پرځای منزل او هدف پرتله کړئ.
د AWS د ناوبوري لاسرسي لارښود دا د اړیکو په اوږدو کې د لارو پوښښ بولي، چې سم ماډل دی. پای نقطه پاکټ یوې سبنیټ ته رسوي، او د هغې سبنیټ جدول لا هم باید پوه شي چې د اپلیکیشن شبکه چېرې ده.
نیمګړې کرښه په هغه جدول کې سمه کړئ چې مالک یې دی. له کارکوونکې سبنیټ څخه د ټول لار جدول کاپي کول د انټرنیټ، وسیلې او جلا کولو هغه انتخابونه هم کاپي کوي چې هېڅکله دې ته نه وو ټاکل شوي، او دا تبادله معمولاً له هغې خنډ څخه بدتره ده چې تاسو پیل کړی و.
د اجازې قواعد وګورئ، بیا د بېرته راتلو لار
د اجازې قواعد د هر منزل او هرې ډلې لپاره دي، او له لارو جلا ارزول کېږي. هغه منزل چې هرې خوا لارې لري خو د کاروونکي ډلې لپاره قاعده نه لري د روغ ښکاري لار جدول سره د تور سوري په څېر چلند کوي.
د بېرته راتلو لار هم هماغه پام غواړي. peering اړیکه د اپلیکیشن VPC کې د کلاینټ CIDR ته بېرته اشاره کوونکې لار، د امنیت ډلې هغه قواعد چې په دواړو سرونو کې ترافیک اجازه کوي، او هغه شبکې ACL غواړي چې هغه نه غورځوي. یوې خوا ته رسېدنه، چېرې چې ping کار کوي او د TCP لاس ورکول نه، معمولاً VPN ته نه بلکې ACL یا امنیت ډلې ته اشاره کوي.
د پای نقطې خپلې امنیت ډلې د اړیکې په انعطاف منونکې شبکې انټرفېسونو کې دي، نو هغه قاعده چې د کلاینټ CIDR څخه د اپلیکیشن پورټ اجازه ورکوي باید له اړیکې سره وتړل شي، نه یوازې له نسخې سره.
د یوې بختورې غوښتنې پرځای، په بیا نښلولو سره تایید کړئ
د split tunnel سره، د پای نقطې لارې د اړیکې د جوړېدو پر مهال لېږل کېږي، نو بدل شوې لارې ټولګه هغه کلاینټ ته چې نښلول شوی پاتې کېږي هېڅکله نه رسېږي. له ملاتړ شوي کلاینټ له لارې اړیکه پرې کړئ او بیا ونښلوئ، بیا ډاډ ترلاسه کړئ چې نوي لارې په ماشین کې شته.
په پای کې، د اړیکو لاګ له هغه پتې سره وتړئ چې کلاینټ ترلاسه کړې وه، او ازموینه دومره ځلې تکرار کړئ چې له یوې ډېرې اړیکې سره مخ شئ. له سمون وروسته یوه بریالۍ غوښتنه ثابتوي چې یوه لار کار کوي، او ټیکټ د بلې په اړه و.