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

درې شرطونه يې فيصله کوي

د شبکې د نقشې نه، د اپليکېشن له اړتيا څخه پيل وکړئ۔ که اجازه يا پلټنه د يوې کليانټ پتې پورې تړلې وي، نو هغه ساتل يوه کاري اړتيا ده او ژباړل يې يو شاتګ دی۔ که اپليکېشن يوازې دا پوهېږي چې ټرافيک د لېرې لاسرسي لارې راغلی، نو ژباړل شوې پته بسنه کوي او د چلولو لپاره ډېره ارزانه ده۔

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

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

لار د جعل اجازه نه ده

د بېرته راتلو لارې زياتول ستاسو فرعي شبکې ته وايي چې ځوابونه چېرته وړل شي۔ دا چوکاټ ته نه وايي چې هغه پاکټونه لېږدونکی انسټنټ اجازه لري چې هغه له بهرنۍ سرچينې سره ولېږي۔ په AWS کې اړوند کنټرول د سرچينې او منزل څېړنه ده، او دا د هر انسټنټ لپاره ښکاري:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

دا يوازې هغه انسټنټ لپاره بند کړئ چې مستنده کار يې لېږدول دي، او د بل هيڅ شي لپاره نه۔ هر اپليکېشن VM چې څېړنه پرانيستې ساتي، هغه يو ماشين کم دی چې د پور شوې سرچينې سره د ټرافيک لېږلو لپاره کارول کېدی شي۔ که ستاسو پلېټفارم AWS نه وي، نو د دې پر ځای چې فکر وکړئ چلند به ولېږدېږي، د جعل ضد يا اجازه شوې پتې سيټنګونه ولټوئ۔

ژر پاکټ نيول له کنسول لوستلو څخه ژر پوښتنه فيصله کوي۔ که ځوابونه ووځي او کليانټ يې هيڅکله نه ويني، نو اپليکېشن نه ناکاميږي، چوکاټ جعلي سرچينه غورځوي۔

ژباړه څه اخلي او څه لګښت کوي

په دروازه کې سرچينه بيا ليکل د بېرته راتلو لارې ستونزه له منځه وړي۔ اپليکېشن يوه پته ويني چې ورته رسېدل يې پخوا نه وي زده، او کليانټ مختاړی بايد هيڅکله د ابر په لارښوونې جدول کې را نه شي۔ په Linux کې قانون يوه کرښه دی، او تر ټولو تنګه نسخه يې ليکل ارزښت لري:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

وګورئ اپليکېشن اوس څه ثبتوي: د هر کارونکي لپاره 10.40.3.10، په هر نښلن کې، تل۔ پر هغې ارزښت جوړ شوی هر پته اجازه لېست اوس ټول لېرې لاسرسي نفوس ته لاسرسی ورکوي، او د هرې پېښې بياکتنه بايد دروازې ته بېرته لاړه شي چې ځواب ووايي دا څوک ؤ۔

حل د ژباړې پرېښودل نه دی، بلکې دا منل چې پته هويت دی، نور بايد پرې نه شو۔ د کليانټ هويت په تصديق شوې سيمه کې وړئ، په دروازه کې يې د ژباړل شوې ټوپل سره ثبت کړئ، او اپليکېشن ته اجازه ورکړئ چې پر هغې ونيول شي۔ د نښلولو کلي پرته، ژباړه يوه شبکه يې ستونزه دايمي عدلي ستونزه بدلوي۔

رېلې يو بل انټرفېس دی

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

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

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

رېلې هغه هم بدلوي چې تاسو يې اخلئ۔ تاسو د اپليکېشن کچې هويت او د هغه د ثبت لپاره طبيعي ځای ترلاسه کوئ؛ تاسو عموميت پرېږدئ، ځکه چې هر نوی پروتوکول خپل پروکسي ملاتړ ته اړتيا لري۔ د HTTP خدمتونو لپاره دا تبادله معمولا ښه ده، او د هر هغه څه لپاره چې HTTP نه دی معمولا په بشپړ ډول نه وي۔

ولیکئ چې هر کنډوالی څه ويني

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

BoundarySource the next hop seesWhat is actually proven
Client to gateway172.20.8.14A certificate or credential was presented
Gateway to app subnet, preserved172.20.8.14The same session, if the return route exists
Gateway to app subnet, translated10.40.3.10Only that traffic came through the gateway
Proxy to backend10.40.3.10 plus a headerThe proxy asserted an identity it authenticated

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

اړوندې مقالې