HAProxy 302 یوې خصوصي اپ ته: دویم ټوپ څوک پرانیزي؟

یو څوک یو عام HAProxy هوسټ د داخلي اپلیکیشن پر لور ګرځوي او پوښتنه کوي چې براوزر ولې نشي تعقیب کولی. پراکسي د خپل VPN له لارې اپ ته رسېږي، بیاځلېدنه د Location سرلیک بېرته راګرځوي، او براوزر بیا هغه پته هڅوي چې یوازې د تونل دننه شتون لري. له بېرنه پاڼه یوازې ځړېدلې پاتې کېږي. پریکړه دا ده چې کوم لوری دویمه اړیکه پرانیزي، او همدا بیاځلېدنه له backend څخه بېلوي.

دوه لارې چې په ترتیباتو کې یو شان ښکاري

بیاځلېدنه تبادله د ځواب سره پای ته رسوي. کلاینټ Location لولي او له هغه ځایه نوی غوښتنه پیلوي چې دی پکې دی، یعنې له هغه شبکه چې تاسو هېڅکله کنټرول نه کړه. پراکسي نوره برخه نه لري. هر څه چې راوروسته وي د کلاینټ خپل DNS، لارې او باور پورې تړلي دي، نو پایله د دې له مخې بدلېږي چې کاروونکي براوزر چېرته پرانیستی:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

د پراکسي backend دویم پړاو د سرور په لوري ساتي. پراکسي هغه د هغې لارې له مخې پرانیزي چې لا یې لري، او کلاینټ د یو عام نوم سره خبرې ته دوام ورکوي. که تونل ولویږي، کلاینټ د هغه URL پرځای تېروتنه ترلاسه کوي چې نشي تعقیبولی. همدا توپیر نیمګړتیا د تشخیص وړ ګرځوي، ځکه تېروتنه هغه ځای ښکاري چې لاګونه دي:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

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

براوزر څه ته اړتیا لري او د سرور VPN هغه ته څه نه ورکوي

د براوزر خپله غوښتنه څلور شیانو ته اړتیا لري چې کېدای شي یې نه لري: د خصوصي نوم لپاره DNS ځواب، هغه پتې ته لار، د اورېدونکي خدمت ته رسېدو اجازه، او د هغه سند باور چې هغه خدمت وړاندې کوي. د پراکسي هوسټ څلور واړه د خپل تونل له لارې لري. له دې هېڅ یو هم هغه کلاینټ ته نه ځي چې هېڅکله په هغه تونل کې نه و، ځکه تونل د هوسټ ځانګړنه ده، نه د URL.

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

کله چې یوازې پراکسي اپ ته رسېدلی شي

د بیاځلېدنې عمل لرې کړئ او هغه غوښتنې backend ته ولېږئ چې خصوصي پتې ته اشاره کوي. Frontend خپل عام نوم ساتي، او backend پریکړه کوي چې غوښتنه واقعاً چېرته ځي. د کلاینټ په لار کې هېڅ نه بدلېږي، ځکه پراکسي د منزل تشریح کول بندوي او پخپله منزل کېږي. هغه اپلیکیشن چې په قصدي ډول د داخلي پورټ 8080 اورېدنه کوي، د هغې لپاره د سرور بلاک لنډ دی:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

دا بلاک د پراکسي د لارښوونې جدول په اړه د بیان په توګه ولولئ: 10.40.0.20 باید له خود پراکسي هوسټ څخه د لاسرسي وړ وي، چې دلته د ډیفالټ لارې پرځای د VPN انټرفیس له لارې معنی لري. check کلیمه یوازې هغه څه بیانوي چې هغه لاره کوي، او د روغتیا لاره باید په اپ کې وي، که نه هر څېړنه سرور بند نښه کوي. بریالۍ څېړنه د کلاینټ په اړه هېڅ نه ثابتوي او د هغې تګلارې ځای نه نیسي چې پریکړه کوي څوک backend کارولی شي.

دا ټوټه بشپړ frontend نه ده. اورېدونکی، تصدیق، اجازه شوي هوسټ او لارې ټاکنه، او هغه قاعده چې پریکړه کوي څوک په بشپړ ډول اپ ته رسېدلی شي وساتئ. backend پروتوکول هم سم کړئ، ځکه HTTPS backend د سند تصدیق او د سرور هویت ترتیباتو ته اړتیا لري، او د هغې څېړنې پرېښودل خصوصي اړیکه نه-تصدیق-شوې کوي.

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

د اپ خپلې بیاځلېدنې لا هم دننه خوا ته اشاره کوي

لومړۍ غوښتنه لېږل د یوځای کېدو یوازې نیمه برخه ده. اپلیکیشن کېدای شي مطلق بیاځلېدنې، سخت کوډ شوي د سرچینې URLونه، یا هغه کوکیز چې د داخلي پېژندل شوي نوم پورې محدود دي خپاره کړي، او هر یو یې براوزر هغې پتې ته بېرته لېږي چې نشي رسېدلی. داخلي نوم ته اشاره کوونکی Location سرلیک د اصلي ستونزې سره ورته ښکاري، له همدې کبله په غلط ډول د پراکسي نیمګړتیا په توګه تشخیص کېږي.

د اپ مستند بهرنی URL او د هغې پراکسي انتخابونه وټاکئ، بیا Host سرلیک د مجازي هوسټ او د سند تمې سره سم کړئ. داخلي نوم پورې محدود کوکی د عام نوم له لارې بېرته نه راځي، او ورپسې د ننوتلو لوپ د تصدیق باګ په توګه لوستل کېږي. لومړی بهرنی URL بدل کړئ، له پاک براوزر پروفایل څخه بیا وآزمایئ، او تمه وکړئ چې نیمګړي لېږدول شوي ترتیبات بریالی ننوتل او سمدلاسه مړه کېدونکې ناسته جوړه کړي.

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

پریکړه وکړئ چې واقعاً کوم ډیزاین لرئ

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

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

د معکوس پراکسي خپرول بېله لاسرسي پریکړه ده، نه د پراکسي خپل VPN هر هغه چا ته روڼ غځېدل چې د هغې عام URL پورته کولی شي. په ډیاګرام کې دواړه یو شان ښکاري، او په دې کې توپیر لري چې چاته د ننوتلو اجازه ده. هغه پوښتنه د ځای پرځای کولو وروسته پریکړه کول هماغه لار ده چې داخلي اپلیکیشن ناڅاپه عام شي.

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