داخلي ALB، عامه DNS نوم: ایا واقعاً لوڅ دی؟

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

لومړی ګام: سکیم ولولئ، IP نه

د سکیم ساحه د بار وېشونکي خپله اعلامیه د خپلې پولې په اړه ده. aws elbv2 describe-load-balancers --names app-internal یو Scheme د internal یا internet-facing ارزښت سره بیرته راولي، او همدارنګه د IPv4 یا دوه ګوني سټیک لپاره د پتې ډول. انټرنیټ ته مخامخ بار وېشونکی لا هم کولی شي خصوصي هدفونو ته وړاندې کړي، نو د خصوصي بیکنډ پتو لیدل د مخکنۍ برخې په اړه هېڅ نه ثابتوي.

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

دویم ګام: وګورئ نوم څه ته حل کیږي

له VPC بهر څخه dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com سره پوښتنه وکړئ او یادښت وکړئ چې ځوابونه په 10.0.0.0/8، 172.16.0.0/12 یا 192.168.0.0/16 کې دي. له عامه ریسولور څخه خصوصي ځواب د داخلي بار وېشونکي نوم لپاره تمه کېدونکې چلند دی؛ دا ثبوت نه دی چې پته له انټرنیټ څخه د لارښوونې وړ ده.

همدا نوم له VPC دننه حل کړئ او پرتله یې کړئ. که دوه ځوابونه توپیر ولري، تاسو د split-horizon نومونه ګورئ، او هغه توپیر د ډیزاین تفصیل دی، نه تېښته.

دریم ګام: هغه لارې لیست کړئ چې هلته رسیدلی شي

خصوصي پته له هر هغه ځایه د لاسرسي وړ ده چېرته چې لاره او امنیتي قاعده شته. هغه په قصد سره لیست کړئ: د سایټ تر سایټ VPN، کلایټ VPN، VPC peering، د ټرانسټ ګیټوې نښلونې، Direct Connect او په VPC کې هر پراکسي یا باسټین. یو له هغو څخه پلان شوې لاره ده، او پاتې نور هغه دي چې بریدګر به یې پلټي.

بیا په هرې لارې کنټرولونه وګورئ: په بار وېشونکي امنیت ګروپونه، په سبنیټونو شبکه یي ACL او هغه لارښوونه چې لاره رامنځته کوي. د لوڅ داخلي خدمت ډېری راپور شوي قضیې دلته حل کیږي، یا نااشنا peering و، یا لاره پلان شوې وه او اپلیکیشن تصدیق نه درلود.

څلورم ګام: اورېدونکی او اپلیکیشن جلا جلا وګورئ

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

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

په یاد ولرئ چې کنټرولونه د ډول له مخې توپیر لري. د اپلیکیشن طبقې فایر والونه د یوې بار وېشونکي کورنۍ سره نښلي او نه بلې، نو د برابرۍ انګیرنې پرځای تایید کړئ چې ستاسو مخې ته د سکیم او ډول لپاره واقعاً څه شته.

پنځم ګام: پریکړه وکړئ چې ایا نوم پخپله مهم دی

عامه حل کېدل کولی شي د خدمت نوم، سیمه او د پتو حد ښکاره کړي. دې ته د تګلارې ځواب لرونکې د معلوماتو ښکاره کولو پوښتنې په توګه وګورئ، نه اتوماتیکې پیښې ته: حساس سوداګریز اصطلاحات د سرچینو له نومونو بهر وساتئ، او که نومونو تګلاره ستاسو له خوښې ډېر څه ښکاره کوي، د خطر په ثبت کې ښکاره کېدل ولیکئ.

که سازمان غواړي خصوصي نومونو تجربه، یو خصوصي هوسټ شوی زون کولی شي داسې عرف وړاندې کړي چې یوازې په تړلو VPC کې حل شي. دا هغه نوم بدلوي چې کاروونکي یې ګوري؛ د عرضه کوونکي جوړ شوی نوم یې نه پټوي او هیڅ شبکه یي لاره نه لري کوي.

هڅه مه کوئ پتې پن کړئ ترڅو ځواب پټ کړئ. د بار وېشونکي پتې بدلیږي، پن کول د TLS تصدیق عادتونه ماتوي، او هغه کنټرول چې واقعاً ورته اړتیا لرئ دا دی چې څوک اړیکه جوړولی شي او اپلیکیشن له دوی څخه څه غواړي. څلور حقایق وګورئ، ولیکئ، او پوښتنه نور مبهمه نه وي.