ولې ستاسو URL ته په 80 یا 443 پورټ کې داخله ته اړتیا ده، نه 45000

په براوزر کې د کوربه نوم ولیکئ او سکیم د منزل پورټ ټاکي: http لپاره 80، https لپاره 443. په DNS ځواب کې هیڅ شی دا نه لغوه کوي، او په ستاسو ماشین کې هیڅ د لېږد قاعده نه شي کولی د چمتو کوونکي په څنډه کې اورېدونکی جوړ کړي. کله چې VPN چمتو کوونکی تاسو ته 45000 په څېر لوړ عامه پورټ درکړي، روښانه URL کار کوي او پاک یې نه. تشه د داخلې په نقطه کې ده، نه د اپلیکیشن په داخل کې.

د براوزر څخه تر پروسې پورې لاره یو ځل وګورئ، او درې خپرونې اختیارونه به داسې نه ښکاري چې په اسرار پټ وي.

وګورئ غوښتنه واقعاً چېرته ځي

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

دا رد کول په څنډه کې پېښیږي، نو ځکه ستاسو د اپلیکیشن لاګونه هیڅ نه ښیي. د لاګونو نه شتون د دې ثبوت دی چې بسته چېرته ودرېده، نه د دې ثبوت چې اپلیکیشن خراب دی.

ولې یوه محلي قاعده نشي کولی څنډه سمه کړي

د اپلیکیشن په کوربه کې لېږد یا DNAT قاعده هغو بستو ته اثر کوي چې دمخه رسېدلي دي. هغه بستې چې د چمتو کوونکي په 80 پورټ ته لېږل کیږي، هیڅکله نه رسیږي، نو قاعده هیڅکله نه ارزول کیږي. دا په ټوله ستونزه کې تر ټولو عامه ضایع شوې ساعت دی.

DNS هم نه شي کولی پورټ وړي. د HTTP مشخصات د سکیم اصلي ارزښتونه تعریفوي، او A یا AAAA ریکارډ پته بیرته راوړي پداسې حال کې چې CNAME بله نوم بیرته راوړي. براوزر بیا هم د سکیم پورټ سره یوځای کوي، نو یوازې په URL کې روښانه پورټ منزل بدلوي.

لومړی اختیار: روښانه پورټ وساتئ

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

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

دویم اختیار: په اصلي پورټ کې ریښتینې داخله ترلاسه کړئ

ځینې چمتو کوونکي او کوربه توب ترتیبات 80 او 443 په ګډ یا ځانګړي پتې د مستند خدمت په توګه لېږدوي. د دې پرځای چې فرض کړئ عامه وتنه پته د خپلې خوښې راتلونکي پورټونه معنی لري، وپوښتئ چې واقعاً څه شامل دي. ځانګړې وتلې پته د راتلونکي لېږد په اړه هیڅ نه وایي.

مالکیت او شتون په لیکلي ډول تایید کړئ، په دې کې چې کله تونل بل پتې سره بیا ونښلي د داخلې سره څه کېږي. هغه داخله چې د تونل سره ګرځي هغه خنډونه پیدا کوي چې د DNS ناکامۍ په څېر ښکاري.

دریم اختیار: په مخ کې یو فرنټ اینډ وټاکئ

په رسېدونکې پته کې یو د شا پروکسي کولی شي په 443 اورېدل او TLS پای ته رسول او له VPN له لارې بیک اینډ ته جلا اړیکه پرانیزي. لیدونکي د فرنټ اینډ نوم او اصلي پورټ ویني، پداسې حال کې چې فرنټ اینډ ستاسو په استازیتوب د بیک اینډ لوړ پورټ سره خبرې کوي. دا کار کوي ځکه چې د داخلې نقطې سره جګړې پرځای معماري بدلوي. بیا بیک اینډ ته په عامه انټرنیټ کې هیڅ راتلونکی پورټ ته اړتیا نه وي.

دا بدلوي هم چې تاسو څه چلوئ. فرنټ اینډ د عامه TLS، د لاسرسي پالیسي، لاګونو او شتون مالکیت لري، او باید د بیک اینډ انتخاب په نیت شوې خدمت پورې محدود کړي. که د فرنټ اینډ څخه بیک اینډ ته ټوپ HTTPS وکاروي، په هغه ټوپ کې د سند تصدیق وساتئ.

یو اصل وساتئ

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

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