ځایي ډېټابیس کلاینټ او شخصي RDS: ولې اړیکه وخت تېروي

د یو پراختیاکوونکي لپ ټاپ د شخصي RDS پای نقطې سره د نښلېدو پر مهال وخت تېروي، په داسې حال کې چې هماغه اعتبارنامه له باسټین هوسټ څخه کار کوي۔ هېڅ شی نه دی لوېدلی۔ د هغه لپ ټاپ او ډېټابیس ترمنځ لاره د درېیو شیانو یو ته اړه ده: هغه نوم چې حل کېږي، هغه لاره چې ترافیک وړي، یا د امنیتي ګروپ هغه قاعده چې هغه سرچینه اجازه کوي چې ډېټابیس یې واقعاً ویني۔ له نورو دوو بدلون مخکې ومومئ کومه ورکه ده۔

ناکامي په سمه طبقه ولولئ

وخت تېرېدل یوه تېروتنه نه ده۔ هغه نوم چې نه حل کېږي، له دې مخکې ناکامېږي چې کڅوړه ماشین پرېږدي۔ بې لارې پته کڅوړې تورې سورې ته لېږي۔ فلټر شوې پورټ هغه انتظار جوړوي چې په بشپړ ډول د غلط هوسټ په څېر ښکاري۔ ګامونه په ترتیب سره ترسره کړئ او په لومړي ناکام ګام ودرېږئ۔

dig +short db.internal.example
nc -vz db.internal.example 5432

که نوم عمومي پته راوګرځوي، یا هېڅ نه راوګرځوي، تونل لا تر اوسه ستونزه نه ده۔

که نوم حل شي او د پورټ ازموینه وځنډېږي، هغه پته چې تاسو حل کړې له هغې پتې سره پرتله کړئ چې ډېټابیس یې راپور ورکوي۔ مدیریت شوې پای نقطه کېدای شي VPC دننه شخصي پتې ته حل شي او له هغې بهر هېڅ ګټور ته نه، او له زوړ لټون څخه کاپي شوې پته به هغه هوسټ ته اشاره وکړي چې نور ځواب نه ورکوي۔

تونل له لارې جلا کړئ

د کلاینټ VPN نښلول هر شخصي حد په اتوماتيک ډول نه لارښوونه کوي۔ پروفایل هغه لارې وړي چې خدمت یې ټېل وهل کوي، او کلاینټ ممکن یوازې ځینې یې نصب کړي۔ وګورئ کلاینټ واقعاً کوم حدود اضافه کړل او د ډېټابیس پته د هغوی په یوه کې راځي که نه۔

ip route get 10.20.40.15
ip addr show tun0

هغه لاره چې د تونل انټرفیس ته اشاره کوي اړینه ده، خو بس نه ده، ځکه بل اړخ لا هم باید ترافیک ومني۔

د وېشل شوي تونل پروفایلونه د دې نیمګړي ناکامۍ معمول سرچینه ده۔ دوی هغه اپلیکېشن لپاره کار کوي چې پروفایل ورته جوړ شوی او د ډېټابیس حد له تونل بهر پرېږدي، چې هماغه وخت تېرېدل رامنځته کوي چې یو فایر وال به یې رامنځته کړی وي۔

امنیتي ګروپ له ریښتینې سرچینې سره سم کړئ

د RDS امنیتي ګروپ سرچینو ته اجازه ورکوي، نه خلکو ته۔ د معمارۍ له مخې سرچینه کېدای شي د VPN کلاینټونو حوض، د باسټین شخصي پته، یا هغه NAT پته وي چې ترافیک ورته ژباړل کېږي۔ قاعده او د کڅوړې ریښتینې سرچینه یوځای ولولئ۔

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

د یو لپ ټاپ کورنۍ پتې لپاره قاعده د لاسرسي ډیزاین نه، بلکې د ساتنې ستونزه ده۔

کله چې په لاره کې کلاینټ VPN یا NAT ګېټوې وي، ډېټابیس ممکن د پراختیاکوونکي د تونل پتې پر ځای د ژباړونکي پته وویني۔ له همدې امله له کار کوونکي باسټین ترتیب څخه کاپي شوې قاعده د لپ ټاپ لپاره ناکامېدای شي: دواړه لارې له بېلابېلو سرچینو راځي، که څه هم دواړه داخلي ښکاري۔

پراخې لارې ته تنګه لاره غوره کړئ

کله چې یو پراختیاکوونکی یو ډېټابیس ته اړ وي، د ناستې پر بنسټ لېږد اکثراً د بشپړ شبکه تونل په پرتله ارزانه وي۔ ځایي کلاینټ لېږل شوې پورټ سره نښلېږي، او لرې برخه د ډېټابیس اړیکه له شبکې دننه جوړوي۔

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

په هغه ډیزاین کې TLS تصدیق بشپړ وساتئ۔ کلاینټ باید لا هم د سرور سند د هغه نوم په وړاندې تایید کړي چې تمه یې لري؛ ځایي لېږل شوې پورټ د تصدیق بندولو لامل نه دی، او بندول یې هماغه هویت ستونزه پټوي چې د نیولو ارزښت لري۔

د بشپړ تونل او تنګ لېږد ترمنځ انتخاب د امنیت نندارې نه، بلکې د حد په اړه پرېکړه ده۔

په شا کې د تکرار وړ لاره پرېږدئ

د حل شوې پتې پر ځای د پای نقطې نوم، هغه سرچینه حد چې امنیتي ګروپ یې اجازه ورکوي، او هغه ډېټابیس رول چې پراختیاکوونکی یې کاروي مستند کړئ۔ دا درې حقایق د راتلونکو ناکامیو ډېری برخه پرته له تلیفونه توضیح کوي۔ د کلاینټ د پروفایل نسخه هم اضافه کړئ، ځکه د پروفایل بدلون کېدای شي هغه لاره لرې کړي چې زوړ یې وړله۔

بیا منفي حالت یو ځل ازموئ: له تایید شوې سرچینې بهر کلاینټ باید لا هم رد شي۔

شخصي ډېټابیس چې یوازې هغه کس لپاره کار کوي چې جوړ کړی یې دی، شخصي لاسرسی نه دی؛ دا یو ناسمستند شوی استثنا ده چې د بیا کشف کېدو په تمه ده۔ لاره ولیکئ، او بل پراختیاکوونکی به د معما پر ځای طریقه میراث واخلي۔