ولې Port-Share ټول ویبسایټ لیدونکي د localhost په څېر ښکاره کوي

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

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

د لاګ کرښه نه، دواړه اړیکې تعقیب کړئ

Port-Share په یو TCP اورېدونکي کې دوه پروتوکولونه ملټي پلېکس کوي۔ OpenVPN د راتلونکې اړیکې لومړني بایټونه ګوري، کله چې د خپل پروتوکول په څېر ښکاره شي هغه ساتي، او پاتې نور ټول دویم منزل ته سپاري۔ هغه منزل معمولا په همدې هوسټ کې ویب سرور وي، نو د ویب سرور منل شوي ساکټ ملګری د OpenVPN بهیر وي۔

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

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

د ترانسپورت لیږد د سرلیک انجیکشن نه دی

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

اصلي پته دوه میکانیزمونه وړلی شي، او دواړه په دواړو پایونو کې موافقت ته اړتیا لري۔ PROXY پروتوکول د اړیکې په پیل کې کوچنی سرلیک زیاتوي، او بیک اینډ باید د هغه د تمې لپاره تنظیم شوی وي؛ هغه بیک اینډ چې تمه یې نه لري هغه بایټونه د غوښتنې پیل ګڼي او په ګډوډ ډول ناکامېږي۔ د X-Forwarded-For په څېر باوري پروکسي سرلیکونه هغه وخت کار کوي چې د HTTP پوه پروکسي یې ټاکي او بیک اینډ ته ویل کیږي چې کوم ملګري یې ادعا کولی شي۔

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

اختیاري د سرچینې نقشه اچولو فولډر

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

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

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

پرېکړه وکړئ چې کومه برخه د پتې تضمین کوي

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

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

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

قاعده وآزمویئ، نه پاڼه

هغه پاڼه چې بارېږي ثابتوي چې د لیږد لار کار کوي او د نسبت په اړه هیڅ نه وایي۔ د پتې کاروونکی وآزمویئ: د لاسرسي قاعده، د کچې محدودیت، د پلټنې ننوتنه، جغرافیویه پلټنه۔

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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