AWS Client VPN وصل دی، خو EC2 لا هم ځواب نه ورکوي

زما لپ ټاپ وصل ښوده. د AWS Client VPN کلاینټ خپل شنه حالت وښود، endpoint یوه ناسته ثبت کړه، او بیا هم زه ونه توانیدم چې په خصوصي فرعي شبکه کې د EC2 انسټنس په MongoDB پورټ کې پرانیزم. په ښکاره ډول هېڅ شی نه و خراب: سند معتبر و، پروفایل له کنسول څخه راغی، او تونل ترافیک وړاندې کاوه. تېروتنه زما وه، ځکه چې ما وصل د اجازه ورکړل شوي په توګه لوست.

ننوتل په سمه توګه یوې پوښتنې ته ځواب ورکوي: ایا دا هویت کولی شي ناسته جوړه کړي؟ له دې وروسته هر څه جلا قواعد فیصله کوي چې ستاسو سند هېڅکله نه ویني. هغه ناسته چې تصدیق کوي او هغه پاکټ چې رسېږي دوه بېلې بریاوې دي، او د دوی ترمنځ تشه هغه ځای دی چې د VPN چالان دی خو هوسټ نه رسېږي ډوله ډېری شکایتونه پکې اوسیږي.

لاندې څېړنې هغه ترتیب دی چې اوس یې کاروم.

وصل شوې ناسته واقعاً څه ثابتوي

د handshake پر مهال endpoint د کلاینټ سند د خپل trust store پر وړاندې اعتبار کوي، یا کله چې SAML تنظیم شوی وي براوزر ستاسو د هویت ورکوونکي ته لارښوونه کوي. که هغه تېر شي، کلاینټ له endpoint د کلاینټ CIDR څخه پته ترلاسه کوي او کنسول فعاله اړیکه ښيي. د دې تبادلې په هېڅ برخه کې دا نه پوښتل کېږي چې ایا تاسو کولی شئ 10.0.4.17 ته د 27017 پورټ له لارې ورسیږئ.

د یوې موخې لپاره اجازه په endpoint کې جلا شی دی. هره بهیر د اجازې قواعدو سره پرتله کېږي، او هر قاعده د موخې CIDR له هغه ګروپ سره نښلوي چې قاعده ورته ورکړل شوې. کله چې هېڅ قاعده موخه ونه پوښي، endpoint ناسته مني او ترافیک غورځوي. نه بنر شته، نه د بیا نښلېدو لوپ، او نه په کلاینټ انټرفیس کې هغه څه چې رد شو ووایي.

د اجازې قاعده له VPC سره نه، له سرچینې سره پرتله کړئ

قاعدې لیست کړئ او هغه د هغې پتې څنګ ته کېږدئ چې انسټنس واقعاً لري:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

پایله د هرې قاعدې لپاره د موخې CIDR او ګروپ ID ښيي. په دې کې دوه نیمګړتیاوې پټې دي. قاعده کېدای شي 10.0.0.0/16 ته اجازه ورکړي په داسې حال کې چې انسټنس په 10.1.0.0/16 کې peer شوې VPC کې ناست دی؛ د peering لار شته، خو چا د دویمې لړۍ لپاره د اجازې قاعده نه ده لیکلې. یا قاعده داسې لیستري ګروپ ته اشاره کوي چې کارونکی په لیستري کې غړی دی خو په هغه ګروپ کې نه چې endpoint یې ارزوي.

تر ټولو تنګه قاعده ولیکئ چې موخه پوښي، او دویمه یوازې هغه وخت ورزیاته کړئ چې دویم CIDR واقعاً اړین وي. له چټک پیل څخه راغلې پراخه 0.0.0.0/0 قاعده کار کوي، او همدا لامل دی چې تر تولید پورې ژوندې پاتې کېږي او ماډل پټوي.

پاکټ به ځي که نه، دا دوه د لارو جدولونه فیصله کوي

د endpoint لار د موخې CIDR له هغو فرعي شبکو څخه یوې سره نښلوي چې endpoint ورسره تړلی دی. دا د لارې نیمایي ده. د فرعي شبکې خپل د لارو جدول لا هم باید پوه شي چې پاکټ څنګه وړاندې ولېږي، او دا هغه شېبه مهمه ده چې موخه د peering اړیکې، ټرانسټ ګېټوې یا د site-to-site تونل له لارې د رسېدو وړ سیمه‌ایزې لړۍ شاته وي.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

داسې لار ولټوئ چې موخه یې د سرچینې CIDR سره سمه وي او هدف یې تړلې فرعي شبکه وي. که لار نه وي، ورزیاته کړئ. که وي او هوسټ لا هم غلی وي، تشه د VPC خوا ته ده، نو د تړونې فرعي شبکې د لارو جدول سره پرتله کړئ.

د کلاینټ خوا یو تنظیم تونل نه ماتوي خو لارښوونه ماتوي: هغه پروفایل چې route-nopull لري. دا لارښوونه د OpenVPN پر بنسټ کلاینټ ته وایي چې هغه لارې له پامه وغورځوي چې سرور یې ټېل وهونکې دي، نو انټرفیس یوازې د endpoint په خپله پته پورته کېږي او موخه ساده لار نه لري. په Linux کې ip route show یا په macOS کې netstat -rn سره وګورئ چې د tun انټرفیس له لارې لار شته که نه. که نه وي، route-nopull له صادر شوي پروفایل څخه لرې کړئ او بیا ونښلئ تر څو ټېل وهل شوې لارې پلي شي.

امنیتي ګروپونه ستاسو د کلاینټ پته نه ویني

دا هغه برخه ده چې ما یوه نیمه ورځ غلطه درلوده. د فرعي شبکې سره تړلي IPv4 endpoint لپاره، خدمت د کلاینټ د سرچینې پته په هماغه فرعي شبکه کې د endpoint د شبکې انټرفیس پتې ته ژباړي. هغه پاکټ چې انسټنس ته رسېږي هغه پته نه لري چې ستاسو کلاینټ ښودلې وه، نو د امنیتي ګروپ هغه قاعده چې د کلاینټ حوض، فرضاً 172.16.0.0/22، ته اجازه ورکوي له هېڅ شي سره سمون نه خوري.

پورټ ته د کلاینټ CIDR څخه نه، بلکې د endpoint د امنیتي ګروپ څخه اجازه ورکړئ چې د تړونې انټرفیس سره نښتي دی. ګروپ ته اشاره کول له کلک کوډ شوې پتې څخه زیات دوام لري، ځکه چې د انټرفیس پته ستاسو په کنټرول کې نه ده. شبکې ACL بې حالته دي، نو چېرې چې ځانګړي ننوتنې شته، هم د ننوتلو او هم د وتلو لوري ته باید بهیر اجازه ولري.

انسټنس ته د هغه خصوصي پتې له لارې هم ونښلئ. عامه IP پاکټ له VPC څخه باسي او د نورو قواعدو سره بلې لارې ته بېرته راولي، نو د عامه پتې له لارې ازموینه د خصوصي لارې په اړه هېڅ نه وایي.

د جلا کولو ترتیب چې په لومړنۍ ناکامۍ کې درېږي

دا په ترتیب سره ترسره کړئ او چېرې چې یو ناکام شي هماغلته ودروئ. هر ګام یوه طبقه نه، بلکې ټولې نه استثنا کوي.

1. تایید کړئ چې ناستې کوم هویت کارولی او endpoint کوم ګروپ ارزوي. د یو trust store سند هغه ورته اصلي ګډونوال نه دی چې له لیستري څخه راغلی SAML ادعا ده.
2. تایید کړئ چې د اجازې قاعده د هغه ګروپ لپاره د سرچینې CIDR پوښي.
3. تایید کړئ چې د endpoint لار شته او تړلې فرعي شبکې ته اشاره کوي، بیا چې د فرعي شبکې د لارو جدول کولی شي وړاندې ولېږي.
4. تایید کړئ چې امنیتي ګروپ پورټ ته له کلاینټ حوض څخه نه، بلکې د endpoint له انټرفیس څخه اجازه ورکوي.
5. د غوښتنلیک ستونزه له کلاینټ لارې ستونزې څخه جلا کولو لپاره د VPC له داخل څخه، په هماغه فرعي شبکه کې په بل انسټنس د SSM ناستې سره وازموئ.

کله چې ګامونه فیصله کوونکي نه وي، زه پر دې جدول تکیه کوم:

د حساب دوه توضیحات هغه نښې پیدا کوي چې د اجازې ناکامۍ ته ورته ښکاري. هر کارونکي ته جلا کلاینټ سند ته اړتیا ده؛ یو یې په دوو ماشینونو ووېشل ناستې یو بل ته پرېږدي، او پایله رد نه، بلکې د بیا نښلېدو لوپ دی. کله چې نوی endpoint جوړ شي، کنسول یو DNS نوم ښيي چې ځینې کلاینټ نسخې یې یوازې د endpoint په پاڼه ښودل شوي ناڅاپي پېشوند سره مني، نو نوم له سری بیا جوړولو پرته بشپړ کاپي کړئ.

که پنځم ګام تاسو بند کړ، مخکې لدې چې څه بدل کړئ د endpoint د اړیکو لاګ راوړئ او د اجازې ننوتنې ولولئ. لاګ هغه موخه چې څېړل شوې او هغه قاعده چې سمه وه یا نه نوموي، او دا د څلورو طبقو پوښتنه یوې ځواب ته راټیټوي.