PostgreSQL هیڅکله نه پوهېږي چې یو کلاینت په VPN کې دی۔ دا له یو آدرس او د اعتبارنامو له یوې ټولګې څخه TCP اړیکه ترلاسه کوي او پرېکړه کوي چې څه وکړي۔ نو د لاسرسي تړل تونل ته د لارې د ټاکلو مانا دا ده چې درې بېلې پرېکړې سره سمې کړو، او بیا د انځور کې کش شوي آدرس پر ځای هغه یوازینی آدرس وګورو چې سرور یې واقعاً ویني۔

درې پرېکړې چې نه باید یوځای شي

چېرې چې سرور اورېږي یوه پرېکړه ده۔ کوم ټرافیک کولی شي هغه آدرس ته ورسیږي دوهمه ده چې د کوربه فایر وال او مخکې هرې شبکې پولې یې کوي۔ کومه ډیټابیس هویت کولی شي له کومې سرچینې تصدیق شي درېیمه ده چې په pg_hba.conf کې کیږي۔

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

سرور چېرې اورېږي

هغه آدرس ته وتړئ چې واقعاً ماشین ته ورکړ شوی، نه د انټرفیس نوم ته:

listen_addresses = '10.20.0.30'

ډیټابیس کولی شي د VPN ګېټوې شاته له خپل تونل انټرفیس پرته وي، او همدا لامل دی چې آدرس باید ونومول شي۔ دا تنظیم بدلول بشپړ بیا پیل غواړي؛ بیا لوستل بس نه دي۔

بیا پورټ، معمولاً 5432، په کوربه او د هغه مخکې هرې پولې کې فلټر کړئ۔ خصوصي آدرس ته تړل د عامې منعې ثبوت نه دی، ځکه د پورټ فارورډ یا کلاوډ آدرس نقشه کول لاهم کولی شي هغه خصوصي اورېدونکي ته پاکټونه ورسوي۔

هغه آدرس چې HBA واقعاً ویني

په لارښوونکي لاسرسي کې سرور د هر کلاینت داخلي تونل آدرس ویني۔ په سرچینه ژباړه کې هغه پر ځای د ګېټوې ژباړل شوی آدرس ویني، او هر کلاینت په همغه یوه ارزښت کې راټولېږي۔ د اجازې ورکولو لپاره د مخکښ ټاکلو دمخه سرچینه د سرور د خپلو اړیکو شاهدونو له لارې وګورئ۔

د هغه ځای لپاره چې لا دمخه TLS او SCRAM کاروي، په قصداً تنګ لاسرسي بېلګه داسې ښکاري:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

دا له یاد شوي حوض څخه د TLS له لارې یو رول او یو ډیټابیس ته اجازه ورکوي، بیا نور لرې TCP لاسرسی ردوي۔ دا د بشپړ HBA فایل بدیل نه دی: سیمه ییز اداره، تکرار او هر بل مجاز خدمت وساتئ، او تنګ قواعد د پراخو اجازو دمخه کېږدئ۔

کله چې ژباړه په کار وي، HBA نه شي کولی کلاینتونه د دوی د اصلي آدرسونو له مخې بېل کړي۔ د شبکې منل کلک وساتئ او ریښتیني ډیټابیس اعتبارنامې وغواړئ، او هیڅکله د trust تصدیق د یوه واقعي حساب سره مه بدلوئ۔

لومړنی سمون ګټي، پرته له بدیله

PostgreSQL فایل له پورته څخه ښکته لولي او لومړنی هغه ریکارډ کاروي چې له اړیکې سره سمون خوري۔ که د هغه ریکارډ تصدیق ناکام شي دوهمه هڅه نشته، نو پخوانې پراخه اجازه په چوپتیا سره وروستې منعه ماته کوي۔

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

HBA حواله هم ترتیب او هم د host او hostssl ریکارډونو توپیر بیانوي، کوم چې هغه وخت مهم دی چې د قاعدې هدف دا وي چې اړیکه باید کوډ شوې وي۔

بیا لوستل، بیا پیل او رد شوې پېښه

د HBA بدلونونه د بیا لوستلو سره پلي کیږي، او pg_hba_file_rules لید د تحلیل تېروتنو موندلو کې مرسته کوي۔ هغه لید د فایل اوسنی منځپانګه بیانوي، نه دا چې روان سرور هغه په بریالیتوب لوستلي، نو پاکه لیست د نویو قواعدو فعالېدو ثبوت نه دی۔

د اورېدونکي بدلونونه خپل بیا پیل ته اړتیا لري، او کله چې بدلون بې اغیزه ښکاره شي دوه عملیې ګډېږي۔

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

اړوندې مقالې