د ساکټ پيئر یا لېږل شوی هډر: کومې پتې ته باور وکړو؟

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

له هرې پرتلې مخکې لاره بیان کړئ:

Client -> approved reverse proxy -> application origin

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

د پتې دوه ډوله شواهد

ساکټ پيئر د یو TCP اړیکې په اړه حقیقت دی: یو څه له هغې پتې څخه لاس ورکول بشپړ کړل۔ دا اړینه نه ده چې هغه انسان، وسیله یا حساب وي چې تاسو ته مهم دی، ځکه چې VPN یا د Tor وتل کولی شي په قانوني توګه هغه سرچینه وي چې یو خدمت یې مشاهده کوي۔ بیا هم دا یوازینۍ پته ده چې کوربه پخپله تایید کړې، او د هغې ټول ارزښت همداغی دی۔

د لېږلو ساحه د یوې زنځیر په اړه میټاډاټا ده۔ X-Forwarded-For، X-Real-IP او معیاري ساحه Forwarded هر هغه کلاینټ لیکلی شي چې هغه پای ټکي ته ورسیږي چې دوی بیرته غږوي، نو د دوی باور په بشپړه توګه په دې پورې تړلی دی چې چا ته د دوی د ټاکلو اجازه وه۔

دواړه په غوښتنې شرایطو کې تر جلا نومونو لاندې وساتئ۔ هغه اپلیکېشن چې پيئر د هډر سره بیا لیکي، وروسته د باور تېروتنې بیا رغولو وړتیا له لاسه ورکوي، او دا هغه دقیقه ده چې تاسو ورته اړتیا لرئ۔

هډر هیڅکله د اړیکې لاره نه بدلوي

د لېږلو ساحې کې پته لیکل د سرور ته رسېدونکې TCP اړیکې سرچینه نه بدلوي، او په لاره کې هېچېرې روټینګ نه بدلوي۔ عادي VPN روټینګ یا سرچینه NAT ترافیک پرته له هېڅ HTTP هډر رسولو ته رسوي۔ همدارنګه، د تګ راتګ دروازه د TLS پای ټکي ترتیب نه بدلولو سره په سمه توګه ساتل شوې HTTPS تبادله بیا نه لیکي۔

مخالف تېروتنه هم دومره عامه ده: HTTPS کلاینټ لخوا ورکړل شوی د لېږلو هډر رښتینی نه کوي۔ دا د درواغجن ادعا لیږد په سمه توګه د رښتیني په څېر ساتي۔

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

هغه پروکسي ونوموئ چې ادعا کولی شي

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

د NGINX اصلي IP ماډول جلاوالی په روښانه توګه ښیي۔ set_real_ip_from هغه لېږونکي نوموي چې ادعا یې حسابېږي، او real_ip_header وایي چې کومه ساحه یې وړي; لومړی باور کوي، دویم یوازې وایي چې چېرته وګورئ۔

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

یوازې د هډر د غوره کولو لارښوونه پخپله لا هم هېڅ نه ثابتوي چې ارزښت چا لېږلی دی۔

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

څو ګامه زنځیرونه په سختۍ سره مدیریت کړئ

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

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

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

دواړه مشاهدې په لاګ کې وساتئ

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

په یاد ولرئ چې دا جوړه څه معنی لري۔ هډر هغه شرایط زیاتوي چې هغه برخه یې برابروي چې تاسو د باور لپاره غوره کړې ده; پيئر یوازینۍ هغه پته پاتې کېږي چې ستاسو کوربه واقعاً لیدلې ده۔ دواړه د فردي هویت ثبوت نه دی، او هغه ډیزاین چې هر یو یې د ثبوت په توګه وګڼي به د یو چا په اړه غلط وي۔