Apache AllowCONNECT اور HTTPS منزل کی پورٹس

آپ کی Apache پراکسی پورٹ 3128 پر سنتی ہے۔ کلائنٹ اس تک کامیابی سے پہنچتا ہے، مگر پورٹ 8443 پر HTTPS سروس ناکام ہو جاتی ہے۔ پراکسی کی سننے والی پورٹ بدلنے سے اس مخصوص فرق کا حل ملنے کا امکان کم ہے۔

کلائنٹ پہلے پراکسی لسنر سے جڑتا ہے۔ اس کی CONNECT درخواست پھر الگ منزل ہوسٹ اور پورٹ بتاتی ہے۔ Apache پہلے کنکشن کو قبول کر سکتی ہے اور دوسری کارروائی کو مسترد کر سکتی ہے۔

AllowCONNECT کو منزل کی پالیسی کے طور پر پڑھیں

Apache 2.4 کے لیے، mod_proxy_connect آنے والی CONNECT درخواستوں کو سنبھالتا ہے۔ اس کی AllowCONNECT ہدایت ان درخواستوں کے لیے دستیاب منزل کی پورٹس کو کنٹرول کرتی ہے۔ دستاویزی ڈیفالٹ 443 اور 563 ہے۔

AllowCONNECT 443 8443

یہ مثال ان دو منزل کی پورٹس کو منتخب کرتی ہے۔ یہ ڈیفالٹ انتخاب کی جگہ لیتی ہے؛ یہ 8443 شامل نہیں کرتی جبکہ ہر ڈیفالٹ پورٹ خاموشی سے برقرار رہے۔ ہدایت کو متعلقہ سرور یا ورچوئل ہوسٹ کنفیگریشن میں استعمال کریں۔

پراکسی کے کلائنٹ اجازت کے قواعد برقرار رکھیں۔ اجازت یافتہ منزل کی پورٹ اس بارے میں کچھ نہیں کہتی کہ کون سا کلائنٹ سروس استعمال کر سکتا ہے، اور جب منزل ہوسٹ کی پابندی درکار ہو تو یہ اس کا متبادل نہیں۔

ریورس پراکسی کی مثال ایک مختلف سوال کا جواب دیتی ہے

Apache اور HTTPS کی تلاش کے نتائج اکثر ایک عوامی ویب سائٹ دکھاتے ہیں جو مقررہ بیک اینڈ کی طرف فارورڈ کرتی ہے۔ یہ ترتیب وہ طریقہ نہیں جس سے براؤزر آگے کی پراکسی سے منتخب ویب سائٹ تک CONNECT ٹنل کھلوانے کی درخواست کرتا ہے۔ اس کی روٹنگ ہدایات نقل کرنے سے اصل پراکسی مسئلہ جوں کا توں رہ سکتا ہے۔

ناکامی کی تشخیص کرتے وقت، وہ لسنر جو کلائنٹ نے حاصل کیا، مطلوبہ CONNECT اتھارٹی اور پراکسی کا جواب ریکارڈ کریں۔ اگر CONNECT کامیاب ہو اور بعد میں TLS ناکام ہو، تو منزل کی پورٹ کی اجازت اپنا حصہ ادا کر چکی ہے۔ آگے بڑھیں TLS ناکامی کے ساتھ، AllowCONNECT کو بار بار وسیع کرنے کے بجائے۔